It’s mythbusting time at RocketBuild HQ, and today we’re taking on some myths about developers. We’re going to learn what makes them tick (and doesn’t), and why some people’s preconceived ideas about how developers work are holding their companies back from creating effective development teams or implementing successful digital projects.
In addition to having been a developer myself, I’ve helped create three development organizations — essentially from scratch — within three different companies: one creative agency, one Fortune 500, and one fresh-faced startup (hey, RocketBuild!). Each time I learned valuable lessons about what works and what doesn’t when it comes to building a dev team.
They hunt in packs
Watch out for the other two raptors…you didn’t even know were there.
Myth: Developers are loners and work best by themselves.
Reality: Most developers thrive on teams. Generally speaking, they like to collaborate to solve problems, review each other’s code, and have the opportunity to get alternate points of view on their work.
At our company, for example, it’s against policy to have only a single developer touch a project, no matter how small. The developers interact in a variety of ways. At minimum, every line of code needs to be reviewed by a developer other than the one who wrote it, so there will always be at least two involved with a project. This enables a certain level of work quality (and personal growth for each developer) that otherwise would not always be achieved.
The antipattern to this (a developer working alone, or nearly alone on a very small team with little interaction) often breeds shortcuts, messy work, and a lack of growth. We’ve seen time and again that most developers, working in isolation, stagnate and don’t operate at the same level as those in a team with peers to work with and learn from.
You need an experienced translator
Technically correct.
Myth: Any company can hire a developer and have them report directly to the marketing director/product manager/business unit exec who needs something built.
Reality: Every dev team needs a leader who is experienced at bridging the dev- and non-dev worlds. This person is a developer, an excellent communicator, and a multi-track thinker who can consider the business implications as well as the tech concerns when making a decision. They often speak to the world for the development team, and can translate requests and challenges made by “normal people” into things that are actionable by the dev team (jury still out as to whether “normal people” is a dig at developers or…everyone else).
These people are relatively rare. Not every developer is capable of managing those sorts of interactions, and some have no interest in it (they see such communication as inefficient and distracting them from performing their real job). If you take a developer who has no skill or interest in being that translator, and have them directly responsible to a stakeholder or manager who doesn’t understand what they do in great detail, you’re asking for trouble — communication problems, misalignment on scope, frustration and resentment. So basically the whole Anakin Skywalker/Obi-Wan Kenobi thing.
A blend of art and science (and economics)
Myth: Developers are process-driven, analytically-minded Vulcan robots who only make decisions based on hard data and only want to do things one way.
Reality: There’s an art to problem solving, and in today’s software-driven world of mobile apps, web apps, watch apps, SalesForce apps, and fridge apps, developers have to employ a lot of that problem-solving art mixed in with data-driven science. To have an effective dev team, you have to have an environment that supports this.
Making significant progress as a developer requires a high degree of critical and creative thinking. Much of our work involves the careful balance of standing on the shoulders of giants — leveraging code/tools that are already available — while simultaneously being able to identify the situations where something new has to be created, and figuring out how it should be crafted given the constraints (budgetary, technical, temporal) of the day.
Yeah, that looks solid.
Taking either of those strategies wholesale is not going to get you very far. Some people do “development” by cobbling together every solution entirely from snippets of code they found on StackExchange while Googling the problem they just ran into 5 minutes ago. If creating software was like building a house, this would be the equivalent of constructing your home out of whatever you find in the surplus bin/dumpster. Need a door? Grab that one on top. Sure, it might sort of work on its own, but when the whole house comes together this way you’re not going to want to live there.
On the other hand, if a developer builds (or is asked to build) literally everything from scratch, they’ll be incompatible with the economic system: no one will be able to afford to pay for their time, and as an added bonus the quality control will tank. It ultimately turns development into a form of performance art that culminates in the creation of a programming language that consists entirely of variations on “Ook.”
A program in the “Ook!” programming language that prints out the phrase “Hello World.” Yes, really.
Going back to the house-building analogy, it would be like going to a quarry and chiseling raw stone out of the ground for your bathroom tile, instead of just selecting the right kind of tile from a company that has perfected the craft of making tile. Doing it yourself from zero involves way more work, increases the chances of defects, and turns your $5,000 floor into a $150,000 floor when you account for time, tools, waste, and a divorce attorney.
A developer, like a home builder, can advise on what might be worth doing custom and what’s better to get off the shelf. But they can only advise on those considerations when a developer is included in the strategic discussions, instead of just being handed specs and told to go down in the dungeon and code. For that to happen, of course, you need to ensure you’ve addressed the “They hunt in packs” and “You need an experienced translator” parts (see above). This negotiation and creative problem solving is an art, and being equipped to embrace it is essential to the success of a dev team.
The more you know
So today, I hope we’ve shed some light on some core principles of having an effective development organization. In review:
- Developers, like many highly skilled professionals, work best in teams where they can test competing ideas and review each others’ work.
- Developers need an organizational structure that helps them be efficient by having a streamlined conduit between them and the rest of the world.
- Development is as much an art as a science, and it is beneficial to include developers in strategic discussions so they can help make better decisions.
As a developer, or manager of developers, what are your fundamental strategies for success? We’d love to hear from you on the Twitters, email, or book of faces.
