Developers in large projects with a complex organizational structure (many roles, management layers) have rather specialized jobs. They work on a single application / component with maybe few 100K lines of code and most of the time deliver a component based on provided specs. Developer is usually involved in some testing and requirements gathering, but it is limited. Even coding part is often specialized. A CPP developer only writes CPP code. Infrastructure configuration is done by a specific person, database also, etc.

In other words, a highly specialized work. From a local point of view this feels very efficient. The developer’s thinking: I spend my time most efficiently when I write code.

Let’s look now at a manager’s perspective. Complex product development groups with many specialized roles and a lot of organizational complexity and especially with a long feedback loop (time to build, deliver, inspect and adapt the product) are usually failed projects. Management is in strong need of doing something about it, so they bring agile people in house in order to improve things.

One of the common messages (for example in Scrum and LeSS) is that we should have very few roles. This implies (or is even explicitly mentioned) a shift away from specialist roles. Multi-skilled people are welcomed. Learning is welcomed. Unlearning outdated practices is welcomed. The term representing this approach is “lean thinking”. It didn’t originate from agile movement, but from people like Taiichi Ohno and Richard Hackman; as alternative to Taylorism. The agile movement has built further upon this. A consequence of having real teams. Teams that deliver to real customer.

Let’s get back to our developer. She has worked for quite a few years with code, and we developers know that writing code is a very satisfying activity on its own. Especially when compared to all those inefficiencies. Writing code feels way more productive than sitting in pointless meetings.

Suddenly, there is this agile coach / trainer who says we should be T-shaped (learn more skills). Developers should do more. Not only code but test, do requirements engineering, build up infra, etc. Also sit in meetings; many of them, every 2 weeks, some every day, albeit for 15 minutes.

As you can imagine, this is quite a change. It doesn’t look attractive. It is inefficient. One developer wrote a blogpost expressing this aversion: https://artur-martsinkovskyi.github.io//2019/i-dont-want-to-be-fullstack/

It looks like a developer in this Scrum/Agile context needs to be capable of everything. A frequent remark: “I cannot possibly learn everything and be able to do everything. I’m a Ruby developer and want to do Ruby”.

No, multi-skilled does NOT mean jack of all trades. And no, front-end Ruby developer is neither a role nor a profession. It is just a small part of our work as software-based product developers. And this is our profession: software-based product developers. Though some programming languages do require more attention and time than others, none of the commonly used languages is so complex to require people to solely focus on writing code in that specific syntax.

Also, the history of software-based product development has messed this up a lot. For too long, developers have been given impression that writing code is relevant. Somehow valuable on its own. Code production is still seen as a goal. There is still an army of developers which thinks that preventing bugs is impossible so why bother; but making and solving bugs is somehow developer’s job. One of the most damaging effects is general acceptance of issues. Almost every product development group has also one or multiple fancy issue tracking tools. Issue tracking tools with large list of issues have become so normal that developers are astonished and find it absurd it is possible to work without an issue tracking tool since there should be so few issues. Fixing own mistakes has become so normal that most see solving bugs as productive time spending. I even had a group of developers in my training who see debugger as one of their main tools. After suggesting that better practices can dramatically reduce usage of a debugger, the remarks were: “In my reality this is impossible” Or “utopia”, etc.

I recognize that such explanation in a training only doesn’t work; although I have encountered exceptions. Some devs coming to me months later to tell they tried and embraced new practices, and it improved their work.

Since a training is not enough, one must show / demonstrate by pairing. We call this usually technical coaching or just being a ScrumMaster. Actually, it doesn’t matter how we call such person as long as there is someone who is able to teach hands-on.

Merely telling those devs to read books is not likely to bring much change. It is kind of like meditation. So many people have read or heard so much about it, but so few practice meditation regularly. In order to practice properly, one needs hands-on coaching.

So, a developer in future is not a jack of all trades, but is also not a specialist anymore. A developer in future will shift focus from implementing a solution towards solving a problem for users / customer. The future has come a long time ago.