Developers considered harmful?
In the vein of Dijkstra's Go To Statement Considered Harmful, I'd like to rough out a new idea: "Developers considered harmful".
Less experience, more risk
Vancouver now has major offices for Microsoft, Mozilla, Slack, Kickstarter and HootSuite -- not to mention the hundreds of other companies going digital, digital agencies, and startups. And most everyone is competing for developers in the same local talent pool.
Post-secondary has gotten better at providing students with fundamentals relevant to modern web development, but still the supply does not meet the demand, and those entering the workforce are still quite inexperienced when considering the massive context of web development in 2017.
In this desperate climate, it makes sense that the figurative bar to pass when applying for a job is lowering. Getting hired as a junior, intermediate, and even senior developer is becoming easier. And as jobs in other industries are drying up, individuals who previously might not have had interest in programming are finding themselves warming to the stability and salary of a career in software development.
Under such conditions, many developers are entering the workforce increasingly inexperienced, and finding themselves on projects with a lack of guidance and mentorship, especially if experienced seniors are already scarce.
A motivated junior developer can absolutely get a feature completed. But without the visibility that comes with experience, a lack of foresight and abstractions can result in technical debt and diminishing returns. And that's the best case scenario. A more likely scenario is that 70% of software projects fail.
A nurturing approach to your new developers
When hiring developers and staffing your teams, be realistic. If you haven't already, give up on the idea of a 10x unicorn. If such a mythological beast exists, they are most likely working elsewhere :)
The likely scenario is that depending on the effectiveness of your hiring process, you are probably hiring local developers with skills that range between 0x - 2x. And don't kid yourself: negative developers are also a possibility!
In this new climate, the purpose of a technical interview should be to identify candidates who have strong fundamentals and a desire to learn. Fundamental knowledge and a good attitude is more than enough to build a high-performing team. It's enough to immediately demonstrate value to your stakeholders; it's enough to train up; it's enough to achieve successful and maintainable software.
Identify where your developers are coming from and what their motivations are. Once this is understood, appropriate pairing and mentoring allows for a speedy development of skills, and in a climate where seniors are increasingly rare, training up is a solid strategy.
Types and opportunities
Here are a few made-up programmer segments that left alone, could harm chances of shipping products -- but with proper guidance, could become indispensable to your team.
1) The "bootcamp survivor"
Countless "bootcamp" schools have opened during the last decade, promising to turn anyone who can pay for a few months of training into an "job-ready" developer. Individuals I've seen come from bootcamps in the Vancouver area don't necessarily have the fundamentals of a traditional junior; more an "appretice", perhaps. My take is that they may have come around to the fact that "Digital" is where jobs are -- but it's also possible that they are still in a "trying it out" phase, and that software development is not necessarily where they really want to be.
I'd recommend assigning small features and pair programming with intermediates on bugfixes, while ramping them up in domain knowledge through books and article recommendations. If they are productive and seem to enjoy the work, I'd continue to encourage the development of their fundamentals until they are in line with the rest of the team. And if their heart isn't in it, they are perfectly positioned to be introduced to content strategy, QA, devops, editing, wireframing -- all valuable positions that benefit from a background in programming.
With no oversight, a newly-branded "web developer" is quite a risk. With the best of intentions, they might rush towards any problem and bash away at it until it resembles the desired outcome. The ensuing code will likely require refactors and bugfixes, stalling development.
On the other hand, a less confident developer might not feel the agency to contribute, and be to timid to ask for help. It's a shame to see nice people quit due to this type of neglect, when a half-hour of mentorship every week could have been enough to get them on the right path.
2) The "cowboy hacker"
There is a certain breed of "self-taught" programmer who has been able to solidify a career through hacks, scripts, and tricks. No use for linters, a minimal understanding of architecture and software development patterns, and a quick-draw on copy-paste from stack overflow, these developers likely pride themselves on quick results and responsiveness -- which can indeed be a huge asset.
But cowboys can be quite dangerous to a project as they might have the confidence to commit code, but perhaps not the experience to understand the fallout of a constant hack-and-slash approach. In a long-running and changing software development project, maintainability can be key for ongoing development and increasing stackholder value.
Consider the orientation towards software. Not everyone is passionate about maintainable code. It doesn't offer the highs and lows of hacking hotfixes in a production environment... But what about using those skills to raise the bar on product performance and security?
Monitoring logs for threats, identifying security gaps, applying bugfixes and patches, penetration testing, and presenting and educating team members can be quite exciting, too. Security is a fascinating field, and developers dedicated to these concerns can be well-worthwhile to the whole team.
The "comp-sci prodigy"
Many computer science programs don't even really get into software development. Students might opt-in to a particular specialty in their last year, so it's entirely possible that a extremely talented programmer might not have a smidgeon of context when it comes to joining a software development team.
A hiring manager might think an impressive candidate is a good fit for a much-needed lead or senior role. But without software development experience, they are unable to distinguish between problems that can be easily solved with a pre-existing product or service, problems that don't need solving, and problems that require only a "good enough" solution. Instead, "rolling your own" becomes the go-to, with over-engineered abstractions that require more training, testing, and debugging -- and things slow to a halt when requirements change.
No matter the talent level, make sure technical designs are vetted by experienced team members or a technical lead in order to prevent going down unnessary roads. Provide training on agile software development methodologies and lean principles. Introduce the concept of "minimum viability". "You Ain't Gonna Need It" can be a most valuable lesson to the projects bottom line.
The saved resources and be allocated towards comprehensive solutions to well-defined business domain problems and contributions back to open-source technologies.
From each according to his ability...
I propose a nurturing strategy towards new hires. Developers aren't all the same, and might have drastically different skill sets -- especially at the lower ranks -- so it can be a little naive to think they're all interchangeable.
A valuable characteristic for your team leads is have an aptitude for identifying the strengths and weaknesses of new hires, and put them in the environments in which they will thrive.