A few weeks ago, Stephen Anderson wrote a piece entitled “29 Things I, as a designer, wish more tech startups knew.” It is a bold contribution to a greater discussion of building better startups.
I’m David Pierce, one of the developers at Startup Weekend, and I love studying developer teams in young companies and seeing what we can learn about building better companies. Like Stephen, I’ve taken my own experiences and conversations with other developers and listed a few thoughts on what entrepreneurs should know about developers as they look to create successful companies together.
- Know how developers work: There are some common elements of a work environment that make developers feel productive. Unfortunately, ignorance here can leave sour relationships between entrepreneurs and their developer teams. Get to know your developer and how they like to work just as you would with another employee on a small team. If you work to make sure you are speaking the same language, the developer-entrepreneur relationship can be a glorious thing! The next few points are some clarifications about how a lot of developers think and work that should be helpful.
- We like specifics: I get that startups are agile and flexible. In fact, developers have been talking about being agile as a development methodology for a long time. And yet, a developer will often push for specifics at the beginning of a project. Confusion here might paint developers as inflexible creatures. The reality is, developers know what they’re up against; computers are actually not that intelligent and it is up to the programmer to tell it *exactly* what to do. This means your requests should be well-defined so the developer can translate it into something the computer understands.
- Good code takes time: Even experienced developers encounter problems that they have never seen before and often have to research or invent new ways to solve. Try doing an Internet search for “code estimation techniques” and you’ll see that this is a pretty complicated field. Think back to the last time you heard someone say “Hey, I need you to build me a such-and-such widget. It should only take a couple hours.” The developer might be very impressed with how quickly they’ve surpassed the estimation skills of all professional programmers, but it’s more likely that that person will become slightly less popular among the development team.
- “Just code it right the first time” rarely exists: Design and architecture is hard when you don’t know everything about a problem at the beginning of a project. Programming, like startups, is a process of building, testing, learning, and refining, and every version of a piece of software has room for improvement. A good developer will know the right questions to ask about a problem, so be sure to provide as much information as you can.
- Lines of code per hour is not a real metric of success: Historically, non-developers have had a hard time figuring out how to measure developer success. I haven’t heard of this happening in a long time, but developers are sometimes evaluated by the amount of code they write. More code isn’t necessarily better code. You will need to spend more time learning how to evaluate your developers.
- Productivity doesn’t always happen between 9 and 5: Developers can have a reputation for always coming in late and for staying up in the late hours of the night to code. This time frame is special because it tends to be free of distractions and meetings. Developers have an easier time hitting a stride and producing quality software. Moreover, there are lots of great stories about developers that come up with great solutions while cutting the grass or taking a shower. Given the opportunity, your developers will know how find the right environment to produce their best work
- Have some basic technical literacy: My college finance professor wisely told me I should know how to read a balance sheet even if I never planned on becoming a CFO or an accountant. It is important for developers to understand the basic terminology about the business domain in which their company operates. The same holds true for entrepreneurs. Make the effort to learn something about your technology stack. Not only does this show your developers you care about what they’re doing, it also means you can spend less time in meetings going over definitions and more time keeping the meeting short, tight, and effective.
- Understand technical debt: The simplest way to approach technical debt is to understand that poor technical decisions always have a cost. Spending a little more time today to make the right technical decision will save your developers a significant amount of time paying back that technical debt later. One of the biggest contributors to technical debt that I see is sacrificing quality for velocity. Your developers want to ship code as fast as you do; trust me, it is a good feeling seeing your code go out into the wild. Still, if your developers are sensing the quality of the product slipping and are asking to slow down, it is likely because they see technical debt and bugs creeping into the system. Technical debt can be hard to see when your company is brand new since the scale is small enough for the debt to be painless. Just know you could be accumulating debts and you will have to pay it off later.
- Understand the business value of refactoring and documentation: Next to testing, refactoring code is one of the most important things your developers will do that you will likely never see. Developers need time to go back and re-organize the code they wrote. They’ve often learned more about the problem by the time the first iteration of a product goes out, and may have also left TODOs and “clean this code up later” notes throughout the codebase. If you are asking your developers for a high velocity, you should reward them with at least a week to go back and tighten up the system.
- Trust Your Developers: If you do have developers in your new startup, learn to trust them as a resource for counsel and advice. You likely hired them because they are smart and have more technical expertise. It is still surprisingly common that entrepreneurs will approach a developer with a pre-planned solution to solve the problem. It is entirely likely your developer has ideas for an alternate solution and might even know a better way to solve a problem.
Be careful to avoid making your development team feel like “code monkeys.” After all, they’re as invested in the success of your startup as you are. More often than not, your developers spent a lot of time and education honing their craft and learning how to solve problems with logic and passion. Try empowering your developers to be a part of your business and leverage the skills they bring.
I’m sure I could spend so much more time writing about building a good developer team. The craft of modern programming has only existed within the span of one human lifetime. Whether in a large corporation or a tiny startup, there is still so much to learn.
I’d recommend reading through Coders at Work if you’re interested in learning more about the history of the profession of programming and the history behind the professionals learning how to define their field.
Follow David on Twitter @TheDahv