Everyone is posting tips for startups, tips for entrepreneurs, tips for your business, tips for how to sell your company, tips for how to wake up in the morning.
Hosting meetups, conventions, non-conventions, garage meetings, beer meetings.
Talking and talking and talking.
Writing "The best advice I've got so far is" articles.
Posting and reposting.
I read a lot of these. Some of them are very nicely written, some of them are obvious and corny.
Seems like a lot of these people forget they were also a bit lucky to get where they are.
My thought - Reading is great, just don't forget to believe in yourself as well.
Don't try to be what you're not. If you're not the no. 1 type, don't force yourself to be the CEO.
If you're not the sales person, don't try to behave like one - Try to sell things the way YOU would, and convince people your way.
And if it doesn't work - Find someone for your team who can do that. In a well balanced team, members complete each other, not just complement themselves.
Tuesday, August 27, 2013
Wednesday, August 21, 2013
There's no such thing as a lucky strike.
A while ago, I was managing a large beta project for a large enterprise company. While preparing a thorough integration test plan, I've began to see my document page count rise and rise.
Consulting with my boss about the possibility to repeat this plan week after week with QA (As most of it was GUI, automation wasn't that possible back then), she told me a very smart thing:
- "If it wasn't tested, assume it's not working".
Simply put, whenever posting code to a production environment, even the slightest of changes, test it. See it with your own eyes.
Especially if we're talking about a startup environment, where everything should be as quick and there's no QA - Be extra careful. If you've posted your code without testing and it worked once, you're lucky.
But luck won't hold up forever, and your users will suffer.
Take a couple more minutes and a deep breath and test it.
Most cases, you'll be glad you did.
Consulting with my boss about the possibility to repeat this plan week after week with QA (As most of it was GUI, automation wasn't that possible back then), she told me a very smart thing:
- "If it wasn't tested, assume it's not working".
Simply put, whenever posting code to a production environment, even the slightest of changes, test it. See it with your own eyes.
Especially if we're talking about a startup environment, where everything should be as quick and there's no QA - Be extra careful. If you've posted your code without testing and it worked once, you're lucky.
But luck won't hold up forever, and your users will suffer.
Take a couple more minutes and a deep breath and test it.
Most cases, you'll be glad you did.
Wednesday, August 7, 2013
Performance - Where it counts.
A good report does magic with large data.
It is supposed to take millions of records, and summarise them into a visual entity that transforms into something meaningful for the user.
Recently, in one of my sessions, a client wanted me to focus on improving performance for a specific report in his system.
Report was taking 5 minutes to generate, clogged the system's database, and was comprised of one of the largest SQL statements I've seen in my life.
Instead of starting to spend hours and hours trying to optimise and dig deep, something that would cost my client a lot of money, I asked him a simple question:
- Who produces this report, and how often does it happen?
Turns out it was a weekly (Even monthly in some customers) report, printed and handed out to a manager.
Assigning a periodic process running on a backup database, and automatically sending the result via mail to the manager saved a lot of money and headache to my client.
Performance is important, but you should always focus on improving it where it makes a real difference.
It is supposed to take millions of records, and summarise them into a visual entity that transforms into something meaningful for the user.
Recently, in one of my sessions, a client wanted me to focus on improving performance for a specific report in his system.
Report was taking 5 minutes to generate, clogged the system's database, and was comprised of one of the largest SQL statements I've seen in my life.
Instead of starting to spend hours and hours trying to optimise and dig deep, something that would cost my client a lot of money, I asked him a simple question:
- Who produces this report, and how often does it happen?
Turns out it was a weekly (Even monthly in some customers) report, printed and handed out to a manager.
Assigning a periodic process running on a backup database, and automatically sending the result via mail to the manager saved a lot of money and headache to my client.
Performance is important, but you should always focus on improving it where it makes a real difference.
 |
| Do it where it counts! |
Subscribe to:
Posts (Atom)