History tends to repeat itself. It is a simple fact to embrace, especially in IT. Principles defined 70 years ago and nearly forgotten 40 years ago are trending again. Yes, I am talking about functional programming, for example. All modern programming languages support it. For some of them, it was a pure revolution (say hello to Java streams!). But how many millennials are aware of Lisp and the original concepts of functional programming dating back to the 1950s? The same applies to co-routines. The idea was defined by Donald Knuth and Melvin Conway in 1958. However, many people think it is a cool feature that single-threaded JavaScript interpreters came up with.
Unfortunately, history repeats itself in regard to people skills too. In the dawn of IT, being a programmer implied that one was pretty intelligent and had a master’s degree with a lot (and I mean really a lot) of math and physics and knew about electrical engineering (because those big mainframes needed a lot of hardware care). That is why many of the definitions of the algorithms, data structures and principles we use today date back to the 1950s and 1960s when the foundations of computer science and software engineering were laid.
There is a legend about IBM and how they hired programmers in those days. The question was quite simple: “You have eight people voting yes or no. How many different results can you get?” The immediate answer should be 256. One option is for the candidate to use combinatorics (variations in this case) and calculate 2 to the power of 8. Another option is that the candidate knows about a byte data type and remembers its size and the range of numbers it can handle (eight bits—one/zero). The trick with the question was, it was a you-fail-only-once question. That means that if a candidate answered incorrectly, she or he would not be able to apply for a job at IBM again. As I said, it is a legend, but quite inspiring and exciting. Try asking the average fresh graduate these days about the solution to 8 to the power of 3 without letting her or him use a calculator (should be part of one of our interview tests). The outcome? Usually, a total disaster.
What I want to say is that in the pioneering days of IT, there were different hardware, programming languages, dialects, lack of tooling and other things that made the tasks nearly impossible to overcome, but the programmers managed to handle it. The reason was they applied their intelligence and knowledge of computer science and software engineering principles to produce results whatever the challenge was. They were versatile, capable; they understood things.
Over the years, we have invented specialisations. I assume the only reason was that the candidates had stopped understanding what it means to be a software engineer but knew the names of a few programming languages they could identify with. Hence, the whole world began to advertise for Java, .Net, JavaScript, C++ and Python developers and other stuff. At some point, we logically discovered that it might not have been a good idea at all. Technologies, frameworks and platforms come and go; it is called evolution. However, letting developers come and go is not wise in the long run because the company loses domain knowledge and continuity. Another point is that knowing a programming language is only one piece of a systems complexity puzzle, and that is not enough.
And so, a full-stack developer was born. A person who solves your problems from top to bottom or vice versa. What a great idea! The good thing is, it only took about ten years to realise that something had inevitably gone wrong, and the full-stack approach is now officially dead (we have stack 2020 now).
There is no “one stack to rule them all”, and that’s it. As an answer, IT implemented T-shaped developers. Being agile means having cross-functional teams, and such a team cannot go on with only pure specialists or generalists, right? So we need a mixture of pure specialisations that go hand in hand with general capabilities.
However, there is a huge BUT! T-shaped means only one specialisation. Is that enough? Of course not! Let’s introduce Pi-shaped developers, and now we have two domains. Still not enough? Let’s use other letters too. M-shaped, E-shaped and finally, my personal favourite, comb-shaped people (you can read about the alternatives here) will solve all our problems.
You know what? It will never happen. Believe me that when Alistair Cockburn, Martin Fowler, Jeff Sutherland and other best-in-the-world engineers signed the Agile Manifesto, they imagined agile teams full of engineers with the same skills they had. The essential words are emphasised intentionally. The plain truth is (and also the reason why so many agile teams fail) there are not enough people with the same skillset and capabilities available. That was true in the 1950s, it is true now and it will most probably also be accurate in the 2050s. It does not matter if the demand is high. The supply part keeps following basic statistics and normal distribution, plain and simple.
Let’s go back to our roots and accept the fact that there is only one group of people able to solve the challenges we face in our field. Imagine we forget about full-stack developers, .Net Core experts with EF Core knowledge and T-shaped front-end enthusiasts using Angular 10+ for a while. Imagine we start seeking engineers with a respectable software engineering and computer science education again (and yes, there is quite a big difference between a 5-year master’s degree in programming and a 2-week online course). They would know Java and .Net, they would be willing to set up your CI/CD and they would understand what await/async means and why eventual consistency might not be the result you want after migrating to microservice architecture. They would also excel in one or a few areas; they would be pure specialists because they love it. And when a new technology or framework comes, they would learn it fast, because they could build on their existing education, knowledge and intelligence. Full-stack, T-shaped, M-shaped, comb-shaped—who should you hire? Please, forget about it. Start hiring smart software engineers, and you are done. In the end, if your HR needs it, they can embrace any such a shape for you.
Author: Michal Petřík
Head of Software Development