Universal Software Engineer: fact or myth?

Universal Software Engineer: fact or myth?

This blog post is all about: that Ninja doesn't differ from Rockstar, why Fullstack != Versatile, is switching tech stacks a failure, what does the tech swap's success depend on, why bother re-specializing if job market is a paradise for any tech, how learning Elixir changed my C#-fu.

When browsing programming job offers you're getting attacked by very different position descriptions:

  • nouns that depict position vary: Engineer, Software Engineer, Programmer, Developer, Ninja, Rockstar, ... :)
  • seniority adjectives vary: junior, mid, regular, aspiring, senior, lead, leader, principal, ...
  • the only part that remains the same (& always appears) is the name of the technology

Apparently it's not possible to unequivocally frame the position without naming explicitly the technology used - Java, .NET, Salesforce, Python, ... Hmm - true or false?

Let's assume I've worked in a team on a Java app with a bunch of awesome Java developers & we did rock the house. Can we now go somewhere else and deliver wonders in Kotlin? Probably. What about C#? C++? Golang? Elixir?

How versatile is Software Engineering? Is good Java Software Engineer indeed a good Software Engineer? Or only a good Java Software Engineer? C# Software Engineer? C++ Software Engineer?

Answering these questions is the point of this blog post.

It's called "Fullstack", dummy ...

No, it isn't.

Fullstack is someone able to cover development across different types of applications (e.g. Front-End + Back-End + some Infra) in their app type-specific stacks, preferably covering 100% end-to-end scenario(s) - to be able to independently create a full spike of functionality w/o relying on anyone else's work.

To simplify the whole case let's limit our considerations to switching between the tech stack while staying within the same kind of applications (to build). So we're not going to mix Front-End with Back-End or Data Science with Cloud Infra as Code. It's only about swapping languages / whole tech stacks to develop equivalent stuff.

Let's rephrase a question then:

Will a Software Engineer who builds particular kind of apps (e.g. web ones) in language K on platform L do equally well in M on N? How much of her/his prior experience is re-applicable? How much time it will take her/him to switch? What's the chance this transition will fail?

Is it possible that being familiar with the specific technology means much less than general software engineering expertise, knowledge & common sense?

And why the hell not?!

Of course it's possible. But the fact that it's possible doesn't mean that:

  • you can force transition (from one tech to another) upon people
  • it will succeed each time
  • its effects are guaranteed or even predictable
  • it doesn't vary between teams & environments

It takes a special kind of ppl ...

Hell, making such a transition is NOT an easy decision to make. You've dedicated your career (so far) to something (e.g. Java) and now you're about to split your focus or abandon your former specialty.

Doesn't it mean that picking your former path was a failure? That you've wasted time? Wouldn't you like to spend the time you'll need for learning on e.g. gaining even more Java expertise?

Based on my past experience - very few decide to hedge their career that way. Of course people keep checking tutorials & learn basics of other stuff just for sheer fun, but making a serious commitment & going all out is not that frequent. It requires A LOT of passion, engineer's curiosity, ambition & dedication. I tend to call it a Professional Hunger - insatiable drive to broaden the spectrum of your tools, so you're ready for all the challenges - whenever & wherever they are coming.

The chance of success ...

... varies heavily.

It basically depends on:

  • your general engineering maturity - e.g. if you move between paradigms, you'll fail if your work-style is based upon patterns, instead of principles
  • environmental support - are you a lone wolf or do you have companions on this trip, support of someone more experienced - preferably someone who've made a similar journey already
  • specifics of app built - how deeply you need to dive into language/stack specifics to achieve the goal - to get the grasp of what I mean, compare systems programming VS web e-commerce VS computer games programming VS CMS-based infosites ...
  • how idiomatically opinionated are the stacks (the one you're moving from & the one you're moving to) - some concepts are hardly matchable ("translate-able") & what is more: some may resonate with you (your preferences) & some will not; but OTOH moving from one object-oriented strongly & statically typed language to another object-oriented strongly & statically typed language ain't such a big deal ...
  • objective level of required technical prowess - e.g. there are Himalayas of the difference between the team that's using "tutorialesque" Elixir and one that harvests fully from low-level OTP capabilities - using the very same Elixir, but in a far more advanced way

Does it (even) make sense?

Why not to stick to whatever you're good in? The job market favors (future) employees - it's hard to find a programming language that does not appear in the job ads & the salaries between the tech stacks do not vary that much.

So why bother?

My perception here is very simple: at this point of my career 90% of Software Engineering related jobs (on my level of expertise) are not appealing at all. Because of various non-tech reasons: people, environment, scale, money, level of challenge, ethics, future perspectives, constraints, ...

That's why I really, really, really, really don't want tech to be another constraint when I find a role/position that really fits me. In other words:

If you find a perfect team, awesome boss, innovative product with an inspiring roadmap, secure financial situation, ... but they put the code in Ruby, won't you consider jumping on Ruby bandwagon while being a Pythonist?

Few final words ...

Re-specializing into a different stack ain't trivial:

  • it can take from two weeks (in a very optimistic scenario under favoring circumstances) to months of bloody struggle (possibly ending with an utter failure)
  • it requires a very mature ego - because in fact (at least temporarily) you're moving from being Senior in X to being a Junior in Y - some do not take it lightly ...

... but (IMHO) in the end it definitely pays off to be an E-shaped individual. It's not only about having more aces in your deck - personally I think that developing skills in non-.NET languages like Scala, Erlang, Rust or Elixir have actually made me more skillful in C# & F# - I find it much easier to identify strong aspects of these languages (by comparison) & turn them into my advantage.

Sebastian Gebski

About Sebastian Gebski

Geek, agilista, blogger, codefella, serial reader. In the daylight - I lead software delivery. #lean #dotnet #webdev #elixir. I speak here for myself only.

Comments