📌Info
This is an English version. The Ukrainian counterpart is here or in Telegram.
A traditional Software Developer/Engineer career path looks like this:
🎓Trainee
→ 👶 Junior
→ 🛼 Mid
→ 🤘 Senior
→ 👔 TechLead/Architect or turn to Manager’s path
(the grade names might vary)
The first 2 arrows seem to be pretty straightforward: learn more ⚙️-technologies, work your skills out and here you are.
However, the further one climbs this ladder, the less ⚙️-ish it becomes. The tasks involve business and management way more than the technology. Of course, the technology in and of itself remains — but as a tool for something bigger.
⚙️ Technology as a tool
In most cases there are many ways to achieve the technical goal. But which way is the best?
The Junior and Mid developers gonna start a holly war on X vs. Y. Some of more experienced folks roll their eyes with somberly tired expression and their catch phrase: it depends.
It depends on too much of non-⚙️ aspects.
- Can we afford X (both, financially and time-wise)?
- Do we have enough trained folks for X?
- How does it comply with our plans for the next
5 years2 quarters? - Will we be able to support this next year?
Therefore, the decisions made here might looks pretty, hmm, suboptimal from purely technical point of view. But here is the deal: if the company fails on these decisions, the price might be overwhelmingly high (losing competition advantage, losing market share and/or niche, lay-offs,…) No pressure at all, Mr./M(r)s. TechLead 🤭.
⚠️Warning
Ironically, but from developer’s point of view it isn’t so bad.
The developer benefits from having an extra skill even unrelated one in the CV — which they most likely will update if company loses the track.
A life story
The company collaborates with university students: they make their graduation projects on company basis. This is mutually beneficial: the students gain experience; the company gets some work done. Not even talking here about financial interest.
The students tend to pick pretty random technologies for their projects. Why? — mostly out of interest/courage. Or because they’ve read some article recently. Or they like the logo and the community.
❗ An important note here, their technologies ain’t bad in any way! On a scale of a graduation project it’s hard to pick really improper stack (unless intentionally).
The students succeed in creating a project with that stack. The graduation goes well, the caps fly in the air.
Success?
Yes, but with a spoonful of tar. Imagine being an engineer in that company that let it out of hands for some time. That person has to bundle the whole freaking zoo of different versions, stacks and approaches into the 10-years old codebase which supports a couple of thousand devices of a dozen of types/versions all over the world.
👥 People over technology
The more experienced a developer grows, the larger the tasks become. At some point the magnitude of the task exceeds the capabilities of a single person. Which means, an extra pair of hands gets involved. This opens a Pandora’s box, as from now on the Senior developer is
- Infecting people with new ideas/visions. Discussing, argumenting, agreeing.
- Distributing (maybe even assigning – ?) tasks.
- Planning the delivery as if it’s not the one man’s job — which it isn’t!
I remember someone said at this point:
Writing the code is the easiest
and the most interesting
thing to do in the IT.
Can’t agree more.
🤝 Team over a person
After 3rd time of rejecting the merge request due to severe architectural violations, you’ll probably start thinking on how to prevent this from happening in the future.
And here we start with training and coaching the team. This isn’t that easy as it seems. Being a good doer hardly ever implies being a good teacher. Quite opposite, being passionate about doing, the professional might lack that subtle feeling of connection with the rest of the folks.
We actually love this: being immersed in the flow and so on. But there is the price attached: ignoring the outer world ⇒ getting inevitably away from the world.
How many times did you think
“I’d better do it myself; that’s gonna be faster than explaining it.”
See, that’s what I’m talking about. And now it’s the duty. At some point the fostering the cumulative skills of the whole team becomes more important than leveling up own skills. Despite of the individual growth is faster and probably more fun, the team can gain more in long run.
Once someone asked me about the language and tool I’m using at work. I answered: TypeScript and WebStorm “Markdown and Confluence”. This was the moment I realized the Rubicon has been crossed.