The average developer is now an integrator — and that’s a good thing
One of the answers I happen to give more often when somebody asks me “how do you evaluate a good programmer?” is “time”. Before you spit your meal: I’m not advocating quick&dirty solutions here at all. Let’s try to give a better definition of time, or a more detailed answer:
How much code do you have to write to accomplish your goal?
Arguably, this is where you save most of your time. Writing less code means not only being faster, but most of all having less code to maintain, which is (most of the time) less of a burden in terms of maintenance in the long term. Spending time in designing your software becomes an investment in which you need to figure out how to be as quick as possible in creating your solution.
This sentence, though, can have very different meanings. One of them could be being as good as possible with your programming language to squeeze every feature out of its standard library to make your code as essential as possible. A funny example is Elixir Golf, which is exactly as the title says: keep your keyboard hits down, and aim at that birdie.
A better answer, I think, is how one approaches the NIH problem. Let’s face it: inventing something new in software is getting harder by the day, and if you have a problem, it’s likely somebody else solved it for you first (and better, most of the times). Package managers for languages and frameworks are becoming the norm, as languages try to keep their standard library as essential as possible, and delegate to third parties extensions and features. And somebody’s gotta thank Open Source for that.
Is it good? Of course it is. If I had to build up a vertical today, the first thing I’d do is to make a shopping list of what I need. Do I need a ring buffer? Check. Do I need a date/time manipulation library? Check. And so it goes. I will probably pick the programming language or paradigm that better suits the kind of application I am developing and packs in stable enough components which fit my shopping list.
What’s left, then? At some point, I might end up realising my work as a programmer has become a work of technology integration, in which my job becomes squeezing every bit of the shopping list I made, and turn it into the actual solution that I needed to build.
At the end of the day, the question comes back: who’s faster? Probably who has a better and more comprehensive knowledge of the ecosystem rather than mere programming skills.
Of course, this is not always true. If I were forced to divide programmers in two groups, I’d much rather split them into “horizontal” and “vertical” rather than “frontend” and “backend”. People building vertical solutions are leveraging components built by horizontal — or technology — developers, and do a completely different job, requiring different skills and attitude.
As companies require massive amounts of solutions which have to be cheaper and faster than ever, I think it’s safe to assume the average developer is the “vertical” developer. And if you didn’t raise an eyebrow yet, you’ll probably agree with my conclusion: a good vertical developer is more of an integrator than a coder. And that’s a good thing.
Moving forward, I believe the requirement for more technology and more solutions will keep on increasing, marking an even bigger division between vertical and horizontal developers, which will use different tools for accomplishing different goals, but still serving one another.
What will they have in common, then? Well, if you ask me, they’ll both still end up asking themselves the same old question: Can I go faster?
