Programmer's startup truths

This is a guest post from Mika, a mobile developer coming from Oulu, and now working at Better Doctor in San Francisco.
In my infinite wisdom I have decided to write this blog post telling some cold truths about programmers’ life in startup companies. Don’t get me wrong, I love my job. You just need to be in a realistic mindset. I’m a bitter 28 year old engineer and will write as such (as I know nothing else). Hopefully everybody involved can forgive me, but the show must go on…
Be prepared to become expert in everything that was not supposed to be in your job description.
In both cases my own job description was simply “Mobile Developer”. WRONG. You will be at some point (usually sooner than later) asked to come out of your shell and do coding jobs outside your comfort zone. For me these have been taking care of some of the server coding work to learning javascript. Startups in my experience have good people in them, but there is always too few. Even the ones that do really well can’t keep up because of the sudden growth. It’s really everyones benefit if you can fix things yourself. It also gives you something to add to your resume.
You need to harass the people that know things.
Getting back to the point of every startup has too few people. This also means that the guys who can actually get you started on your job are usually busy most of the time. It’s your responsibility to become a productive member of the engineering team as soon as possible, and this sometimes means that someone has to sacrifice time to get you started. It might be annonying for the both parties, but this absolutely has to be done.
Documentation doesn’t exist and if it exists, it’s crap.
There, I said it. Startups need to grow past being a startup until they actually hire technical writers to deal with this. Until then, you need to get by. Most you might get is the automatically generated API documentation. Learn to live with it or volunteer to spent rest of eternity writing technical documentation which will be useless when the next release hits.
Most of what you write is shit.
Too few people, not much time until next release, need to get things working somehow. Sounds familiar? Good. Truth is: YOU WILL WRITE BAD CODE. I would be gazillionaire if I had a dollar for everytime we released something and couple of days later discover that “oh my god, i have created a monster”. Embrace refactoring of your code when you can and don’t let the dragon living in your codebase eat you. When you know something is bad, just mark it properly for the next unfortunate soul to find… and for the love of all that is unholy, try to learn from your mistakes.
Good design is the one that actually gets implemented without engineering team blowing their brains out.
The design is not perfect and will never be perfect. In a startup you need a design you can deliver rather quickly. Marketing team needs something to sell and investors need to see that you actually make progress. You don’t get to spent months on end figuring out one that covers all the possible cases in past, now and future. If it works, it’s good. If you deliver it on time, it excellent. Don’t be discouraged by the minor details, the stuff is going to get rewritten in the future.
At this point you’re probably already writing a hatemail to me about how in your company nothing of sort happens. Seriously, this is only my opinion on the subject. There are many different kind of startups and maybe, just maybe you manage to get into one that is magical fantasy lands where pigs fly and everybody has happy-fun-time. If you don’t, deal with it by embracing the chaos.

Author of this post