What developers want: A #CloudMinds huddle recap
If a romantic comedy were produced solely for the developer community’s entertainment, a fitting title might be, “What Developers Want.” Simply put … it’s complicated. While there are some things that all developers want — the ability to work faster, more consistently and to write beautiful code, to name a few — every developer has different needs, and therefore different desires.
The topic of what developer want was presented to a group of #CloudMinds during a recent huddle discussion during Index — San Francisco. Sticking with the romcom theme, on one side you’d have the developer, and on the other, the programming model. There’s the classic meet-cute: a developer falls for a programming model that their organization thrusts upon them, or the developer chooses it because he or she finds great value in the programming model’s use.
A number of factors may work against the couple to keep them apart. In the end though, the question remains the same: Will they or won’t they find true love (or, perhaps more fittingly, true innovation), and how will they overcome the obstacles in their way?
During the huddle, several takeaways emerged, along with some lingering questions. Here are a few of them:
1. What developers want is not always what they need. What developers need is not always what they say they want.
Developers have never been able to do so much, so quickly. The pace of innovation has never been greater, and these are obviously good things. With this ability, however, comes added complexity. Developers have no shortage of tools, literally at their fingertips, to do their jobs. Choosing the right tool is not always obvious. There’s tribalism, brand loyalty, and a basic, human sense of self that is often at stake.
Also, with so many teams and individuals tasked with solving unique problems, standardization and long-range vision can often fly out the window in favor of moving quickly. Developers want to write
There is no one way to engage a set of developers. Because there are so many different workloads being approached in so many different ways, there’s not one answer. There won’t be one programming language to rule them all; there won’t be one approach to development to rule them all. Finding balance between what they want and what they need will never be an easy task, but that certainly doesn’t mean we stop trying.
2. Listen! Vendors and service providers can benefit from listening more to developers.
Vendors and developer service providers are often accused of putting tools into market that don’t adequately address developers’ needs. This could be solved with less telling developers what they should want, and listening to their pain points and building services that address those in innovative ways.
So, how can vendors effectively understand the needs of the majority and work from there?
3. Developers want help.
With any profession, we look for things to make our jobs easier. Developers are no exception. They want their code to work, plain and simple. They want to deliver quality code quickly that ultimately addresses the often-complex problems their trying to solve. But how? The journey to achieve this is going to differ for every developer, every problem, every company. There will never be a one-size-fits-all solution.
So, what are the mechanisms that can help each individual developer better solve the problems they seek to solve on a daily basis? And how can we help developers build in flexible way that serves the organization’s needs today and in the future? Are there things we can standardize that would make developers’ lives easier?
4. Improved training and skill development could help.
There’s often a gap that exists between traditional training and the practical, real-world experience. Whether training happens through instructor-led training, mentorship, internal advocacy, peer programming or other some combination thereof, we can do more to bridge the gap between the training and hands-on coding. There’s no standardized approach to developer training because every team and ever developer will have different needs.
Given these circumstances, how do we empower developers to build their skills over time?
5. Developers need line of sight into the roadblocks that they cannot foresee.
Entire organizations can help developers take a more holistic view when it comes to the implications of picking a particular tool. Before picking a particular tool, the entire team should ask: Are you reinventing the wheel? Are you adding more problems and unnecessary complexity to your system? Are these decisions really going to solve the problem you’re trying to solve? Would an existing tool better suit the purpose?
In this case (spoiler alert!), we’re left with a cliffhanger. The discussion is to be continued in a blockbuster sequel. I encourage you to leave your thoughts and further the discussion in the comments.
