DEV Community

Cover image for Unpopular Opinion: It’s harder than ever to be a good software engineer
Juraj Malenica
Juraj Malenica

Posted on • Edited on

Unpopular Opinion: It’s harder than ever to be a good software engineer

Working in a startup environment for almost a decade has given me privileged access to a fast-paced culture of innovation, exploration, and a fail-fast approach. I followed the standard progression ladder: intern, junior, mid, senior, and eventually moved to the engineering management track. Over time, many people I grew with later moved on to work at other companies, becoming highly-respected contributors there. It would be fair to say they are good engineers.

Looking back at the journey of my peers, mentees, and my own, it seems harder than ever to be a good engineer.

Defining a good engineer

What does it mean to be an engineer? As software engineers, we are:

  • Responsible for translating complex problems into efficient and scalable solutions
  • Tasked with analyzing user requirements, designing software architecture, writing code, and testing and debugging software
  • Expected to stay on top of trends, seeking new business opportunities and ways to improve existing products

So no – engineering doesn’t equal programming. Sometimes, that is the smallest part. It definitely appears so as one acquires more experience, as shown in the figure below.

Source: Engineering Leadership Skill Set Overlaps

What does it mean to be a good engineer? Based on numerous interviews, and supporting my mentees’ progress, I noticed that people with different levels of expertise might give different answers.

Someone just starting out might think it’s the number of languages and frameworks a developer knows. A more experienced engineer might not even care about the language they’re using, instead emphasizing code quality - adhering to all coding principles and conducting QA, while moving swiftly.

Highly experienced engineers place an enormous focus on bringing value. Sometimes we’ll quickly write throw-away code that breaks all the rules to prove a hypothesis; sometimes we’ll spend days writing a couple of lines of mission-critical code. But most days, we are making architectural decisions, discussing mission-critical issues, improving processes, etc. Why? Because often, that brings the most value.

Although there are always exceptions to the rule, we can say that a good engineer is one that efficiently focuses their effort to bring maximum value in achieving a goal.

Growing markets and competition

The tech market is constantly evolving. We have all seen massive successes over the years: from WhatsApp to Uber, Airbnb, and TikTok. While these may be exceptions, such examples often set the north star for people – something they should strive for. This way of thinking puts extra pressure on engineers. They feel stress from inside, thinking they're doing something wrong, and from outside, with people comparing their company to many competitors.

Source: How Healthy is the Public Technology Market?

To succeed in such an environment, companies needed to “move fast and break things,” as the famous Facebook motto says. Today this is more obvious than ever – almost every company is becoming an “AI company.” Everyone is integrating ChatGPT, often for no real reason, without a strategy on how it will bring value.

By moving away from the core principle – how can we bring more value to our customers – and moving towards beating the competition on the hype train, we get engineers building functionalities that are doomed to fail.

World is a confusing place

What should an enthusiast such as myself do to become a better engineer? Apart from the obvious choice of perfecting coding skills by improving clean code and architecture philosophies, nowadays, there are lots of temptations lurking. Learning TypeScript and that one latest framework that changes everything, diving into the world of blockchain and crypto, experimenting with a myriad of AI products… Options are endless.

All javascript libraries

To be honest, after so many years in the industry, I still felt threatened by the new wave of change brought by ChatGPT, GitHub Copilot, and other emerging tech. My brain started imagining scenarios where I’m out of touch on so many things. Am I focusing on the right things to bring value? Am I using my maximum potential?

After some time, it became clear we’re in a hype. That too will pass, leaving only AI companies that are creating long-term value. The number of AI companies in the last 5 years has doubled in the US, with many startups just adding a feature on top of then newly-released GPT-3. They would later die with the release of ChatGPT or GPT-4, which could do the same thing, but better. But that doesn’t stop the hype army of Twitter and other platforms from proclaiming the new world order.

Even with so many years working in tech, I got sucked into the hype. Rookie mistake!

Programming languages and constant releases of new frameworks also add to the confusion. Tailwind, TypeScript, Haskell and Rust are all great; they each have an angle which gives them an advantage. However, people often mistake learning them for something that will give them an edge. It won’t, or at least, it shouldn’t. They are just tools which are nice to know but can’t replace experience. That is why we never put language/framework requirements in our job descriptions. I would be a fool to miss a talented engineer because they don’t know TypeScript, prompt engineering, or microservices.

My advice is - don’t get caught up in new trends and hypes to the point where you lose focus on bringing value.

Fast pace and high expectations

When seeking new challenges, it can be difficult to strive for positive stress, while avoiding negative stress. Positive stress is one where we perceive a stressful situation as an opportunity leading to a good outcome, while negative stress is one that can have detrimental physical and mental health effects, as seen in the image below. Continuously delivering results on a tight schedule is stressful, and building features for the wrong reasons sways towards the latter.

Positive stress vs. negative stress

Both as a mentor and as a hard worker, I’ve seen stress lead to burnouts. Without exception, having someone go through burnout results in less output than reducing workload, taking a break, and optimizing for the long term. That's why we always try to make raising red flags as straightforward as possible, with periodic team updates, one-on-ones, and a nurturing culture.

Still, things will go wrong. When they do, we cut scope, involve people who can help, or communicate with our clients to postpone a launch.

Pressure is higher than ever, coming both from within and without. Stay focused and surround yourself with a supportive team optimizing long-term.

How can we do better?

We all have our down moments – feeling like inadequate engineers, mentors, or colleagues. Things will never be perfect or easy, and they shouldn’t. Without making mistakes and hard times, we don’t learn. But there are some things I find can increase efficiency.

Levels of influence

Individually, stay true to what is really important. Technologies will come and go, but the value you bring to the world is what counts. It’s hard to fake hard work and experience.

As a company, start with why when making decisions. This is the best way to deliver functionalities that will bring value. Also, make sure the employees know that why. In my experience, they will make better decisions, give valuable feedback and be happier.

Culturally, establish processes that will support the employees, optimizing long-term. Together with your colleagues establish a culture of trust, support and caring. That way, you will all get the best of one another.

Top comments (28)

Collapse
 
miketalbot profile image
Mike Talbot ⭐ • Edited

For me, as developers here in a virtual community or in our work teams, we must stand together, shoulder to shoulder against the world. We must accept that things change because we are change agents. We must accept that we are imperfect because we strive for perfection. When the room catches fire we run for an exit rather than analyze the flames.

We may hate the situation we find ourselves in, but we can't change that - what we can change is the future. We learned something and perfected it for 20 years, then it became obsolete, our tears give us no momentum, so we must accept and move on.

I love AI, but it renders useless 10% of my skills. I love it because it's 2000% faster than me at that 10%.

Collapse
 
jurajmalenica profile image
Juraj Malenica

I love your point of view. Change is important - it allows us to learn. And having a trustworthy team means a lot

Collapse
 
pjburnhill profile image
pjburnhill • Edited

Great article, well put.

I would add that the whole premise of 'adding value' is also valid for our life, as a whole.

At least myself, I tend to either procrastinate or fixate on that 'one thing' which will solve all my problems, rather than settle on the solution which actually gives best value and move on to the next thing, even if it's not the most elegant or hyper-optimised.

Much like the sentence I just wrote..

Collapse
 
jurajmalenica profile image
Juraj Malenica

I completely agree :)

Collapse
 
tac1000 profile image
Tac

Unpopular opinion?
I think 95% of Devs feel overwhelmed and huge majority just don't assume the current state of software.
How long can you go everyday without finding a crash or a bug in something you use? If you pay attention carefully, it will drive you nuts.

Performance wise, things are getting worse too. Not only bad choices of stack, but also bad code practice and leftover code everywhere.

Collapse
 
jurajmalenica profile image
Juraj Malenica

I'm glad we agree. This is still an unpopular opinion because people will focus on things like - Copilot writes your code, you have great code editors, etc. But they are missing the point :)

Collapse
 
tac1000 profile image
Tac

Exactly.
Imho, we created such complex environment with difficulties all around, and there is a toxic culture of looking smart.
I think Casey Muratori has been making great arguments against the faith of adopting patterns and systems that you do not comprehend.
I strongly recommend Jonathan's Blow speech named "Preventing the collapse of civilization" at DevGamm. Pretty dramatic title, but I think it makes sense in the context of the presentation.

Thread Thread
 
jurajmalenica profile image
Juraj Malenica

Just watched Preventing the collapse of civilization - excellent talk! Thanks for recommending

Thread Thread
 
dsaga profile image
Dusan Petkovic

Sounds interesting, will have to save it and watch later :D

Collapse
 
supermari0s profile image
Μάριος

This article resonates with me as a software engineer who is constantly trying to improve my skills and deliver value. I agree that it is hard to keep up with the changing trends and technologies, and that we should focus on the why rather than the what...

Collapse
 
latobibor profile image
András Tóth

Excellent article! It is very important to start talking with each other. I would add a couple of things, many of which are coming from other people, some of which are mine.

  • Obsession over productivity: I laughed out bitterly when I heard the notion of "industrial revolution was so transformative because it found a better way to organize people, not because everyone was told to find their own ways to improve their productivity". I think one of the hardest part of being an engineer in the tech industry is constant gaslighting over hyperproductivity, magic and holy frameworks and approaches that can't be challenged. People rather do 120 DB roundtrips in 120 separate queries through an ORM than to write a raw query in a scenario that can be done with a couple of joins and/or a view.
  • Mathlighting: you can't criticise overcomplicated frameworks/languages because they are theoretically correct or avoid certain classes of errors by introducing the ages old class of error of not being able to work quickly and effectively in an environment you don't fully understand. Just take a look how much simpler is overmindjs over the anonymous function train-wreck of redux for instance. Action creators creating actions creating functions to call. Great frameworks simplify problems by bringing them closer how humans work. Bad frameworks make you look stupid.
  • The "I don't know what I want to build, but build it now!" attitude. This is bad management. We can't work effectively if our managers don't spend time on eliminating double-work, dubious requirements.
  • "Silent hiring" of team leads: please code a lot, but also manage people's salary expectations, resolve cultural conflicts between the Estonian frontend dude and the Pakistani backend engineer gal, review code, and also make decisions. But write code as well.
  • Too busy to gain depth because I have to learn fast: the people who use NoSQL for relational data, because they don't have time to learn SQL, because the next NoSQL db must be learned.
Collapse
 
ivantembe profile image
Ivan Tembe

Great article, thanks for sharing your thoughts and experience! 🔥
You have touched an issue that is unfortunately less prioritized, although very important to consider! As an new engineer most of the time we think we are the problem. One urgent thing to change (from a company’s perspective) in my opinion, should definitely be the “why” clear communication between the stakeholders and engineers, which indeed brings most of the frustration, burnouts, stress, …leading to unhappy engineers & low quality outcomes.

Collapse
 
bklau2006 profile image
BK Lau • Edited

Thanks for sharing your thoughts!
I can tell from just reading it that it squares with my very own experience and observations.
There is another aspect that I think culled many good engineers out of the market and industry altogether gradually over time.
It's employability longevity.
Most engineers face times when they are laid off from their employers or they need to seek to explore other opportunities elsewhere for various reasons. It could be skill enhancement or income boost that they need or a career move.
The following statements resonate with me:
"That is why we never put language/framework requirements in our job descriptions. I would be a fool to miss a talented engineer because they don’t know TypeScript, prompt engineering, or microservices."

Maybe I should add "We don't care if you can flip a binary tree unless your job is to design the most efficient algorithm library; otherwise, we think you can look up CLRS book"

Most tech interviews these days are just joy killers of the "whiteboard data structures and algo" hazing kind without regard to a professional engineer's experience or prep time. No wonder, to most employers there's a shortage of good engineers.
It's totally absurd. The recruiting process for software engineers is bad, very bad such that you feel like even if you have years of experience as if you had none.

My son asked me about the Computer Science program recently. I basically moved him out of considering a CS career unless his soul and heart are into it because of the increasingly untenable state the software industry is heading.

Collapse
 
dsaga profile image
Dusan Petkovic

Some of the points in this article stuck with me because they are things that I struggle with every day.. especially getting lost in trying to keep up with all of the new technologies and trends, sometimes it gets overwhelming.

I think we just need to break up of that mindset from time to time at least, by reminding ourself of what's truly important, while of course having a sustainable way of keeping up with the new things.

Collapse
 
otaviofcs profile image
Otávio Sampaio

Juraj, I totally agree on your point of view. Every good engineer should ask themselves if they are delivering value. Love your pyramid as well.

Collapse
 
rajaerobinson profile image
Rajae Robinson

Wow! This is an excellent article. Thanks for sharing your wisdom