What they don’t teach in coding school
The business world is suffering from a shortage of real, commercial-grade software developers. Which is a serious problem, because the world now runs on software, and today’s cloud-empowered customers have come to expect the very highest standards in intuitive application navigation and functionality.
While you can’t skimp on the development of your applications if you expect to be competitive, the talent pool is providing you with a less-than-optimum set of options. The demand for experienced developers is strong, and so there’s an influx of people joining the fray by learning the business with skills training programs and online coding instruction. You may wish you could hire a full-blown developer, but you will end up hiring a coder.
What’s the difference, and how can you help manage and train the coder so he/she learns to think more like a developer?
From coder to developer
Coders learn to write code. This seems obvious, but let me drill down a little. They learn how to make software do certain things, using certain tools in a certain way. In and of itself, there is nothing wrong with this.
What is missing – and what they don’t cover in the coding instruction courses – is the larger context. How does this function fit into the bigger picture? What are the business goals that must be met? How does this thing work with these other things?
Most importantly, what about the human elements? How must you work with others – who are working on the other pieces of this system – so that when all the components come together, it works as a whole? What is the experience and outcome that the user wants – and expects to have?
It turns out that the people part of development is where coders often stumble. Coders usually learn in solitary, not in groups. They are not given assignments as team members, but as solo workers. So they emerge from their coding instruction courses without a clear concept of team collaboration.
Coders are not exposed to the user as the code is being taught and written. They spend their time working with the code. Code behaves as one would hope, as long as the code is written logically and accurately, and within the functional boundaries of the language or tools being used. Code is predictable. Even when something goes wrong, code can be analyzed, in a linear fashion, until the problem is found.
Users – humans – on the other hand, are not so logical or predictable. They are full of agendas, surprises, and unexpected needs. They are driven by their own priorities, and their priorities have nothing to do with the coder’s priorities. Their expectations are completely separate from the limitations of a given programming language. As many software entrepreneurs have painfully discovered, just because it can be created doesn’t mean it will be successful.
Coders mature into developers only after they have learned to be as adept with the human and process sides of development as they are the code and languages they write and manipulate. We know this from the moment we bring a new coder on board. We factor these realities into the way we manage these new hires.
The real-world training begins at the start, with mentoring and targeted education, passing wisdom from the full-fledged developers who have learned these lessons.
For more information on selecting and working with developers for your upcoming app project, please download a guide for CEOs about creating great software from Applied Visions today.