August 15, 2015

Developers Who Can Build Things from Scratch

There’s lots of different types of developers you’re going to need to work with over the span of your career in the software business, but the one I want to talk about today is the kind you need when you’re trying to build something new.

Finding a developer who can transform a set of ideas into something tangible is hard - they’re out there, but it takes more than just knowing how to code. I gave a talk about startup product development (slides) to some entrepreneurs on Friday and none of the folks in the audience had deep technical backgrounds (no engineers, in other words.)

All of them had ideas for products they wanted to validate and were looking for ways on how to find the right types of engineers to work with early on.

A developer who can take a blank sheet of paper and turn it into a functioning product, under their own direction, is a rare - they are in possession of hard technical skills, excellent at explaining technical concepts to non-technical team members, can work with abstract requirements, able to anticipate future changes and revisions on their own, and are able to adapt on-the-fly.

What follows is the advice I give to entrepreneurs with non-technical backgrounds on how to recognize these types of developers - I’m going to call them “from scratch” developers.

Not attached to a particular way of doing things

An engineer who can build products from scratch is one who’s not attached to a specific set of technologies or a specific way of building things. They’ll objectively choose the right tools for the job depending on what it is.

In other words, you’re not going to want any pet technologists or futurists from my “Taxonomy of Terrible Programmers.”

Those are red flags right off of the bat - any engineer who’s more focused to how they’re building the product than what they’re actually building lacks the maturity to do this job. They’d need to be managed by another engineer in order to provide the best ROI, so pass over these types for now.

Corollary: actively suggests using off-the-shelf software

A corollary to this property is if a developer actively suggests using pieces of off-the-shelf software, even if they have licensing costs associated with them, that’s often a good indicator of actual go-to-market experience and being able to focus on what’s important: delivering the product.

There’s a middle ground to this though - you have to make sure the developer isn’t overly dependent on a specific piece of infrastructure in order to do their job.

For instance, if I as a .NET developer wasn’t able to use Windows Azure because the product had a data sovereignty or compliance requirement that prevented me from being able to use Azure - I’d need to be able to adapt to a new hosting environment in order to be the right developer for the job. Which brings us to the next requirement…

Not derailed by new requirements or new things to learn

Building something from scratch is always going to involve new ways of doing things, because every product is different at some level. It also inherently involves learning and changing things on the fly - because you will always discover new requirements after you actually start getting into the meat of trying to implement a product. Anyone who tells you otherwise should read up on the Nirvana fallacy.

So any developer who can do the job must be able to learn new things on the fly. For instance, if you’re able to do some level of customer and product development in parallel (which you always should) and discover a new thing about your customers that needs to be factored into the product, what happens if your developer isn’t willing to learn whatever they need to learn to fulfill that requirement?

Turtle on its back

Happens more often than you’d think! The first sign that you’re dealing with a developer who’s intellectually rigid like this is when they start telling you that things are “impossible.” Nothing is ever really “impossible” - expensive, different, and challenging maybe. But rarely are things actually “impossible.”

A developer who can build something for scratch will figure it out - they might need some help picking from a number of different possible options that they discover, but ultimately they’re not going to get stopped by not knowing what to do initially.

Structured way of thinking, communicating, and asking

The most important trait of a “from scratch” developer is their ability to communicate and think in a structured manner.

The “from scratch” developer begins in an environment where they are the only engineer - the other stakeholders they’re working with typically don’t know what “technical debt” is; which technology stack is better for X; or even which parts of their software product are “expensive” to build. So it’s the responsibility of the “from scratch” developer to be able to communicate these issues clearly and concisely to those team members.

Here’s a list of things this developer needs to be able to both do and explain:

  1. Visualize and describe a product build cycle end to end;
  2. Identify the core features in that product and estimate the relative cost of each;
  3. Break up the development of the product into discrete milestones;
  4. Sequence those milestones into a schedule;
  5. Identify areas where features could be cut or altered to help ship faster; and
  6. Be able to provide a business justification for every technical decision.

This is actually a lot of stuff! But it’s important to do - if a developer can develop all of those distinctions and explain them effectively, then they’re capable of building this product without a lot of direction.

How developers become “from scratch” developers

I’m a big believer in nurture over nature - I’ve become proficient at building things from scratch as a result of years of repetition, beginning with developing baseball card trading sites when I was a fourth grader all the way up to the OSS projects I’ve founded to the startups I’ve founded.

If you’re a developer and read this list and feel like you can’t do this yet - don’t worry. It takes practice, effort, and a willingness to really learn from your mistakes. So give yourself permission to fail and start getting your hands dirty - building an OSS project or a product from scratch is one of the best professional growth exercises I can recommend. You’ll learn a lot, and not just the technical parts of it.

If you want to try your hand at open source software, make sure you read “How to Start Contributing to Open Source Software.”

Or if you want to try to ship a commercial product, then make sure you read “What It Takes to Actually Ship a Piece of Commercial Software.”

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..