How To Win Developers and Influence Code Quality

Lots of marketing students and sales professionals each year are required to read the book How To Win Friends And Influence People and for good reason: the book stands alone as one of the greatest books on sales ever. I decided to co-opt the title of that great book for this entry, because I want to talk about how to sell your company to developers – particularly, how to get the best developers to do the best work and make your company, well, the best at whatever it is that you do.

Developers are not interchangeable.
If there’s one thing that’s absolutely frustrating about human resources types, it’s their insistence that problems can be solved by adding more people. To be fair, their role is to provide the human capital needed to get the job done; however, at the end of the day developers cannot be changed out like spare parts in an engine.

Software development is an art, and like any art, the artist is the most crucial component determining the outcome of the artwork. Lose a good developer and your masterpieces (your products) will suffer for it; you cannot simply replace excellent talent with anyone like you can replace someone who fries hamburgers at McDonald’s.

The Mythical Man-Month touches on this with a considerable degree of competency. Because the job of developing software requires considerable thought, it’s not something that can be done by X Developer or Y Developer, but must be done by specialized individuals who are right for the particular job.

Use the best tools, whether or not they’re free.
When asking companies questions from the Joel Test, I used to ask his question about whether or not the company uses the best tools money can buy. Then came a creative answer from one company, which was “we try, but we’ve found that some of the best tools are free.” This company had made a concerted effort to find the best tools for the job: they were willing to pay for the best tools if they cost money, and used the free ones, if they were the best. This is an excellent policy.

Nothing frustrates developers more than using substandard tools. A free bug tracker isn’t useful if it’s not user friendly or easy to comprehend. An open source Subversion browser isn’t worthwhile if it doesn’t do what the team needs. Conversely, paid applications are not better simply because they cost something; there are plenty of development tools that are free and are better than the paid ones (lots of people argue over Netbeans versus Zend Studio, for example).

Companies should be willing to spend in the areas where it matters: technology, software, and “toys” – systems that impress their employment candidates and developers. They should save resources when it’s appropriate to do so, and spend when the situation calls for it. As Joel Spolsky points out, a cool computer system can woo a developer even if you don’t pay the highest salary.

Nothing can make up for bad managers.
The nature of software development, particularly the fact that it’s closer to an art than a science, makes it a very difficult area to manage. It’s not well understood by other departments, and developers tend to keep to themselves. Thus, managers of developers are often unsure about how to manage development teams, and other departments tend to blame the developers (because humans place the blame on that which they do not understand).

These types of situations are common, and are toxic to development teams. No amount of cool toys, amazing salaries, great perks and flexibility will make up for a crappy management situation. Developers tend to be a smart bunch, and often they know the values of their skills. Developers are also often introverts, and would rather simply move on than fix whatever is wrong.

The difficulty in managing a development team is matched only by the amazing productivity one gets from a gelled, fully functional development team. It is worth it, and companies that grasp this will be successful.

Technical people should be led by technical managers.
There’s a famous saying that “those who can, do; those who cannot, manage.” This seems to be sadly true in the technical world, where technical leads are not experts in the fields they manage. This is deadly to a development team.

It’s true that development and management require different skill sets; developers like to have all the pieces and struggle without them, while managers typically have the role of finding all the pieces and assembling them together. However, there are those that are good at both; these are the excellent technical leads that should be moved up and given management duties. They are capable of handling both roles.

As Cal Evans says, “If you have never been a software developer, you have no business managing software developers.”

Identifying a developer’s skills and placing that developer properly is crucial.
The corporate world has seemingly decided: there is a career path for each and every worker, no matter who they are, and following that career path is crucial. Employees that don’t follow it are somehow “less-than” and often sent packing. Developers are thus expected to “grow” in their career, ultimately moving into management.

40 years after Dr. Laurence J. Peter and Raymond Hull published The Peter Principle, we still struggle against this idea that every job has a career track, as though employees can somehow be made better, and taught new skills.

The truth is that sometimes people are good at what they’re good at; nothing more. This is not a vice! Some developers are experts at development. Promoting them into management, with its different skill set and requirements, will only alienate the developer and foster his incompetence. This is a lose-lose for the developer and the company.

Each employee has an area of competence, and good managers seek to find this and exploit it. This isn’t some crazy idea that I thought up; it’s the product of interviews with 80,000 managers by the Gallup poling organization, and turned into a book called First, Break All The Rules by Marcus Buckingham and Curt Coffman. They would say that some developers will always be software developers and this is ok! If development makes someone happy, there’s no reason why they can’t be an expert in it, and be the best developer in the company, even if they never move above that position.

Summary

Obtaining and retaining the best talent is difficult, time-consuming, and worthwhile. Happy developers write great code, because they have the tools, the stimulation, and the desire to excel and do their best.

There are lots of great works on how to manage employees and get great results. For some reading, I suggest The Mythical Man-Month, Peopleware (check your local library, as this is hard to find), Joel On Software, and First, Break All The Rules.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Thales Jacobi (@thales_jacobi) wrote at 1/6/2010 10:41 am:

As always your articles are inspired and unbeatable. Thanks for the great content.

Jon wrote at 1/7/2010 9:45 am:

What can I say, other than this is yet another post that shows your complete ignorance. Posts like these make novices cream in their pants because they are too naive to realize that either you posts are nothing but common sense, or it’s a post like this that you say your personal opinion is somehow the voice of reason. what a moron…

Thiago Belem (@tiutalk) wrote at 1/7/2010 11:55 am:

Great! Love this part:

“Software development is an art, and like any art, the artist is the most crucial component determining the outcome of the artwork. Lose a good developer and your masterpieces (your products) will suffer for it; you cannot simply replace excellent talent with anyone like you can replace someone who fries hamburgers at McDonald’s.”

Oliver (@1730) wrote at 1/7/2010 5:03 pm:

I think one part of your post is quite offensive, do you really think you could replace someone who “fries burgers” at McDonalds any day?
Every one is replacable, but it can never happen completely seemless, be it developer or be it any other role.

Copyright © 2023 by Brandon Savage. All rights reserved.