Unlike a lot of the technical co-founder of startups, I did not grow up “hacking” for pleasure. I discovered software engineering much later when I had to pick a major in college. I was lucky enough to pick something I ended up liking, I picked software engineering, which allowed me to learn how to build stuff that people used; that’s how I like to call it. The emphasis on the “people used” part is actually important. I did not necerarly like building software for the sake of building software. I actually enjoyed the vision of the software being used by people. I think that’s why I was so lucky to end up in the startup world, even though I was train for a broader “Software engineering” industry.
I could only see my way in this industry if I could build stuff that would be used, by a lot of people. It did not need the sofltware I built to change people’s life, or the world, I just needed it to be used.
After college, I ended up being lucky enough to intern for YouSendIt.com, which was a typical fast growing startup in the Silicon Valley. I knew almost nothing, but as soon as I got my buggy software into people’s hand, something happened to me, and I really strived getting better at building software. Not getting better, for the sake of crafting beautifully engineered software, but getting better at delivering web applications that would be used by millions of people.
When a startup launches, the only focus that the product development team should have is how to get as many people as possible to use the application.
The type of engineers that makes a product development team succesful in the early days of a startup, is not an engineer who builds software as a craft. It is not an engineer who focuses on creating the most elegant software architecture. It is not an engineer who wants to use the latest technology, nor the best-most-obscure algorithm.
The type of engineers that makes a product development team succesful is the type that strives to ship software to get people to use it. His self-proclaimed success should correlate with the number of people who use the product he builds, and its growth.
Comes a time engineers need to use their craftmanship to build software, but it comes way later in the life of the company, when shipping codes involves enough engineers that non-crafted code could affect how the product is being used. As engineers we all have to keep in mind the reason why we are building software: for customers.