Submitted
By Dave Sweeton
Go to any technical user group meeting and you are likely to find many job announcements, but few developers looking for work. Something has shifted in the supply and demand equation, and it’s developers who are now in the driver’s seat. They are able to change jobs more easily than at any time since before the last recession, and they frequently field multiple offers while doing so.
So what can you as an employer or manager do to recruit and retain good developers? There are a number of things. While it may not be possible to do all of them, it certainly would be possible to select a handful of them to institute as quickly as possible.
Technology Issues
Developers are keenly aware of how fast technology is shifting. They know if they don’t keep up, they become dinosaurs. You don’t want them to feel like they have to go elsewhere or risk becoming unemployable. Furthermore, being stuck on old technology or a mess of a codebase is boring and frustrating.A few considerations can help address technology concerns for developers, including work on legacy projects, new technologies/libraries, refactoring, challenges, productivity, training, and automation.
One issue is legacy projects. Legacy codebases are a fact of life, but be aware that dated technology gets more expensive to support. Working only on out-of-date platforms is bad for the current programmer and can be a stumbling block for hiring new programmers. Trying to find a candidate to take on VB6, MFC, or classic ASP is a real challenge. Even ASP.Net WebForms is considered too out-of-date to touch by some candidates. For projects that are under active development, try to migrate and improve your technology stack to avoid getting trapped.
Also, allow your team to use new technologies or libraries on existing projects, but only where it’s appropriate and justified. You want to avoid having a kitchen sink of technologies or having libraries that are only around to justify a programmer’s whim. Maybe try prototyping with a library before using it in the production code base, or just plain giving your programmers time allotted for investigation and “play.” The skills they gain while investigating will likely lead to improvements in your projects.
Allow your developers time to refactor and pay down technical debt. Working in a codebase that grows worse with no end in sight is demoralizing. If you give your developers the time they need to produce quality code, everyone benefits. Make refactoring a task called out clearly in your project plans and don’t allow it to be so low priority that it never gets done.
Provide fun projects with new and interesting challenges. Every project has some boring and menial aspects, but there has to be a balance of tasks where there’s interesting work to be done. Every developer’s definition of “interesting” varies of course, so ask!
Invest in your developers and support them in getting training or attending conferences.
Make sure you provide a fast enough computer and whatever productivity software they want. Investing in both of those pays dividends for the company and the developer.
If your project has boring tasks, encourage your team to find automated solutions. The most common examples would be automating builds, releases, or deployments. This requires a time investment, but it’s another one that is win-win.
If your team has a preference for a particular flavor of source control or issue tracker, and that choice meets your requirements, let them use what they want.
Culture Issues
Developers suffer from being misunderstood. Very few outside of the software development team understand what is involved in writing quality code. A feature may seem like it should take ten minutes to implement, when it’s actually a solid week’s worth of work. If developers are constantly being beat up, they grow weary. Some friction, some misunderstanding, some pressure—these are fine once in a while.
But a culture where that’s the norm will surely drive developers away. A few things to consider include schedules, estimates, development time, interruptions, and overtime.
Have realistic schedules that are driven by the amount of work that needs to be done, not a calendar date that was chosen arbitrarily. If you do have a calendar deadline, cut the feature list down to something that is achievable by that date.
Use estimates correctly. Don’t ask your developers for ballparks and then treat them like estimates. Don’t use estimates as a whip to punish your developers. Instead, figure out why the estimates were wrong and work with the developers to improve them in the future.
Make sure your developers have lots of development time. Developers seem to be particularly sensitive to time “wasted” by inefficient or unnecessary meetings.
Support your developers in having blocks of time they can work without interruption, like ignoring emails and phone calls, or posting a sign/status that says “busy, no interruptions please.” No interruptions means no interruptions—unless the building is actually on fire. Perhaps establish fixed time blocks where you can’t schedule meetings, like no meetings before noon, or no meetings on Fridays.
Limit the amount of overtime developers are required to work. Some developers welcome overtime but if overtime is required as the norm, it’s usually a management failure.
Integration Issues
On top of being misunderstood by the non-technical stakeholders, developers are often treated like pariahs—never permitted to mingle with the very people they are writing code for. Your developers need to be integrated into the larger ecosystem, interacting with end users, clients, customers, and stakeholders.
They need to hear firsthand about how their work is going to be used. They need to hear about frustrations, irritations, hopes, and dreams concerning their products. Filtering information to them is not the right action to take. And if you’re worried about it, developers can be coaxed into communicating less technically so that these interactions are fruitful. There a few things you can do to help developers get the feedback needed.
Have developers participate in requirements gathering and design tasks. If they hear the requirements from the horse’s mouth, they will have a better idea of the real needs.
When direct interaction is not possible, give them good requirements. Nothing is more frustrating than developing something and having it rejected because of unstated or wrong requirements.
Provide room for innovation and creativity. Being treated like an interchangeable “code-monkey” and told exactly what to do won’t work for many developers.
Make certain developers hear about any kudos from your users. Specific praise from end users can really increase job satisfaction.
Stand Out From the Crowd
There are a handful of things that developers really appreciate. If you can offer them, you should.
Provide a good work space and environment. For some developers this means quiet and private. For others a noisy bullpen may be ideal. If you can support both personality types, you’ll be ahead of the game. Bullpen plus quiet rooms is one approach. Quiet workspaces plus great collaboration rooms is another. Either way, they will need a proper desk and chair with good ergonomics.
Allow for flexible work time. And consider offering remote/telecommute work. Everyone from every industry appreciates flexible work schedules, but some developers don’t hit their most productive mental state until well after 5p.m. Working remotely—occasionally or in large part—can be a huge productivity and happiness boost for some developers. Others will go crazy with the isolation or waste their time on distractions.
Lastly, but not least, pay well! Developers care about all aspects of the job, but pay is still as big an issue for us as anyone. Make sure you are paying salaries that are on par with similar jobs in your area. Your developers, with their knowledge of your business and codebase, should be worth more to you than hiring—and training—a new person with equivalent skills.
Happy Developers
Hopefully from this long list of suggestions you will find a few that you can immediately implement to the benefit of your team. If you want to retain your best talent, making improvements on their behalf is a great way to show your concern and care.SW
Dave Sweeton is the chief technologist at Stout Systems, an expert level software, Web, and embedded systems development consulting and staffing services company based in Ann Arbor, MI. Sweeton began his career as a software developer in the mid-90s. Currently he is responsible for numerous installations at major corporations throughout the U.S.
Apr2016, Software Magazine
