I received an email from a developer the other day who made this comment:
“Ran across your profile, a wealth of experience on tech and software startups. Was curious about one thing: you’ve built a few companies around software or web applications, but doesn’t look like you have any experience with coding yourself? How do you hire and manage or partner with developers when you aren’t able to evaluate their work directly? That ever cause any problems?”
Interesting question. I chuckled at the “but you don’t code” misinterpretation. I’ve been writing code since 1994 (LAMP stack from way back, perl/PHP/MySQL; lots of Javascript and Node stuff recently), but I’ll be the first to admit my personal skills are at the intermediate level for my core stack.
That said, I’ve managed developers and large-scale software projects and technical startups for many years and have some thoughts.
1. Coding for startups is not primarily about writing code.
It’s about solving problems with the resources you have available – the most important of which are time and the skills of the people to which you have access. I’ve worked absolute technical miracles with three-person teams and seen fifty-person projects die horrible deaths. My absolute favorite programmer to work with wrote “nonstandard” code from a CS perspective, but ALWAYS solved the problem on time and made users ecstatic. I’d work with her any time, any place. A good startup developer writes good code, yes, but does lots of other things too. (I hacked out the infographic here a while back to emphasize the differences).
2. Code for startups gets thrown away.
I’ve seen entire companies (including my own) fail because of premature investments in code elegance and scalability. By all means, one should take the time to code it “right,” as long as you hit the business milestones and requirements imposed on you. There’s a real art to that. If you’re successful there will be time to come back and fix things – if you’re not, all your elegance won’t matter.
3. If you want to be a computer scientist, don’t work for a startup.
I love a good code solution to a really hard problem – I’ve designed lots of them. But if you’re more interested in writing cool code or working with the latest and most awesome platform, it might be psychologically hard for you to put that aside and hack something dumb in order to make a customer happy.
Too often, engineers consider technical solutions in a vacuum (does this comply with standards? Does it use the classroom techniques I was taught? Can I think of a more elegant way to write something? Do the logic structures take all possible cases into account?) and those evaluation criteria take on emotional and often personal importance. A lot of that has to do with ego and self-image (“I went into engineering because I’m smart, and I need to show I’m better/smarter than the next guy”), how they have been evaluated in the past (“my CS professor would have failed me for writing code like this!”), not to mention competitive and interpersonal issues that have nothing to do with engineering per se (“If they had picked me for this project they wouldn’t have to deal with this nonsense” or “I’d be embarrassed to show this to another developer”).
All that is great, but none of it really matters in the startup world. And it creates drama and friction and waste that you just can’t afford.
4. Coding skills change.
I’d much rather have an intermediate programmer who can self-teach themselves quickly than a veteran senior programmer who refuses to adapt because they know the “right” way to do things. Moreover, nobody writes perfect code all the time, and sometimes you’re forced to kluge and hack to get the job done. Knowing how you *would* have done it (and how you’ll fix it or make it better the next time) counts more than getting it perfect.
5. Coding NEVER stands alone.
Developers not only need to think about front end/back end questions, but design and user experience, platform and performance, documentation, modularity, deadlines and ship dates … the list goes on and on. You have to work with a team (including lots of people less technically skilled than you), keep motivated, manage burnout, and ideally really love the product and the problem you’re solving. At startups, coders who can think like generalists make better coding decisions.
Given all that, evaluating code is only a tiny part of evaluating successful engineers for startups. Flexibility, problem-solving skills, a business/customer mindset, generalist thinking and team skills all count too.
I’m always interested in having this debate with folks who have managed or run startup engineering teams (real startups – not well-funded ones with money to burn 🙂 ) and generally find that they agree with me – although those with formal computer science training find deep psychological conflicts while doing so. What about you? Am I right?
Original publish date: February 15, 2015
