The crisis of a software engineer identity

I have been working as a software engineer for the past 10 years, and I absolutely love this profession. It is such an exciting field, as technology advances so fast, and there is always something new to learn.

But how do we keep up with the technology change, and what in the end of the day actually makes us a good engineer?

The developer “box”

In recent years I rarely see job posting for “software engineer”, I more often see: backend developer, frontend developer, fullstack developer (probably the closest to what a software engineer would do) — and then I wonder, when did we become so boxed? And is it possible to escape the box one is placed in?

I completely understand that every software engineer would have a preference or an orientation, it is impossible to know everything about everything, but when did we start thinking that it is wrong, that software engineers would actually like to engineer a product? Understand the process end to end, learn new things, and contribute on different aspects: not only the code but also the process?

Let me tell you a little story. I am a software engineer, when I started my career I was super excited about everything, and I quickly came to an understanding, that doing only one part of the code, without understand the product as a whole or the ability of debugging the next piece without asking my colleague for help, quickly became very shallow. Why should I bother my colleague if I can do this myself? My education does not state: I can only work on component A? My education says software engineering, and with a bit of help in the start, I can totally debug component B as well. The wish to know more was accepted with open arms, so as a young engineer I thought: GREAT! I am doing the right thing.

Later on, I wanted to know what is all the fuss around modern frontend development, you know all that React and Typescript stuff, and I got an opportunity to do just that. The even cooler part of learning a new language in that team was, that the backend was in my super fav language at the time: Java!

Spoiler alert: guess who did NOT have the chance to touch the Java code? Yes I tried, I tried so hard, that I would pick up any small task/bug I could. I would also debug end to end, and spend some time having everything running together.

I think it was around that time, when my identity crisis started sneaking in, in the moment when I was labeled as frontend developer and not a software engineer, I was suddenly in a box.

One must be thinking: great! There are plenty of frontend development jobs! I agree, but one of the most amazing parts about this field (for me), is how many new things there are to learn all the time, I want to grow and expand, be a better software engineer.

The way out of the “box”?

So, how does one come out of that box? By looking somewhere else. I did that, did not work, added 2 more years of React/Typescript, with some more Node backend — yey… (Not to worry it was not all bad, I learn a lot about working with the cloud, and coding products from scratch).
I have decided that I had enough, I am a software engineer neglecting my Java/.Net skills for a while — this had to stop.

At the time I landed a senior software engineer position working on .Net Core, hey, last time I worked with .Net there was no Core, so cool right??
They tested me on .Net, and were aware that I spent around 4 years doing Node and React. Let me tell you, I felt like I was a disappointment. Not because I did not learn fast, or because I could not contribute, or because I was slow, but because I was not given the chance or the time to excel, and this is where my identity crisis REALLY peaked.

I wanted to learn from people that were better than me in .Net Core, so I can skill up, cover for the time I lost, the same way as I can skill up people doing “frontend technologies”, what is so wrong with that? Probably to them, the fact that I did not spend all my 10 years in .Net was a problem, and suddenly I started feeling like I am a shit engineer.

At the time, I also started working with people that their main goal was to code, rather than create a product and contribute to the software development process — give me requirements, and I will give you code — probably full of bugs and no tests, but hey its code right?

Let me pause here and take another perspective into this story and talk about product and software development process.

The engineering approach

Engineers have different mindsets, hey were are all individuals and we are all different — totally fair!

I am one of those that does not take my contributions to a product by only writing code. My contributions go into the process as well:

• Understanding the product or some of the domain (to best my ability) ->
• By understanding that, I can understand what we are trying to solve ->
• By understanding that, I can actively contribute with questions, concerns, ideas maybe even facilitate the feature exploration phase with other team members ->
• By being active in the discussions, I understand the acceptance criteria, which means I write less bug prone code, and know where to also focus my unit tests ->
• I can work organized, because I have done some initial technical investigations, and I have an idea of what tasks need to be execute ->
• I also can get a feeling of how hard or easy it would be ->
• Ultimately, I can drive a feature to success by taking ownership and delivering it.

Did anyone notice that I did not mention in what kind of language I write? Being a software engineer, is also about problem solving, about involvement about engineering, it is not always just about the code.

So why does it feel like a weakness? I consider this a gift, it what makes my profession awesome!

But apparently we all need to be in a box: frontend, backend, devops you name it.

Don’t get me wrong, I understand that we cannot all do everything, and I do not expect everyone do everything, but why does it feel like the engineering skills are less important than language mastery?

Now what?

The absolutely best opportunities to learn and grow are on the job, and this is how I would encourage anyone to grow — Don’t stay in “the box” if you do not wish to…
So if I actively worked with Java before, why should I limit myself from applying for a senior engineer job in Java? Why should I always start in point 0? Does being outdated on something makes me a less good engineer? Does it erase all my years of experience? Are our engineering qualities only measured in years of experience in one specific language/stack, or how can we contribute to the software engineering process, by solving problems and building great products, while doing this as a team.