Ask HN: Is it increasingly hard to be a good engineer? | Hacker News Reader

Ask HN: Is it increasingly hard to be a good engineer?

14 pointsmjuraj16 comments

1. With increasing number of languages, frameworks, libraries and verticals, it's overwhelming to keep up with best practices. 2. Developers need to do more than ever as everything is becoming digitalized. 3. There is a lot of hype to follow up because businesses now want AI, and before they wanted crypto and blockchain 4. Competition is huge, so the tempo is high.

Are these reasons valid, are there others as well, and is it harder to be a "good engineer"?

View on HN

In general, being a good engineer means being able to cut through the hype and just deliver real solutions that solve real problems.

So you don't need to keep up on everything to be a good engineer. On the contrary, the best engineers I know stick to one thing long enough to know it deeply, while keeping a light eye on what is new in order to understand when it is worth learning a new skill. It is OK not to do everything. And best practices are not as clear as that term makes it seem - "best" is subjective. Different projects have different needs, so it is good to know what worked for others, but you still need the deep knowledge to make your own decisions.

I don't think the work is any harder now than it was a couple decades ago. But there are a lot more distractions now, so being comfortable with prioritizing where you want to spend your energy is a bigger task that it used to be.

> the best engineers I know stick to one thing long enough to know it deeply

The age-old generalist vs specialist discussion is pretty interesting.

As a small anecdote, I'd say that the best engineer I know is very much a specialist. He can correctly set up loads of servers and infrastructure on all kinds of cloud services without much difficulty. But he's almost useless when it comes to building a good product on his own. Ask him to put together a simple contact form? Oh, he can probably eventually figure it out, but he'll cobble together some of the worst HTML/CSS with a crap UI you've ever seen.

Personally, I think that specialists can be incredibly talented and useful, but there's a reason that generalists rule the web. There's a thousand different ways to solve any problem online. Having a really broad base of knowledge of different aspects of technology gives you a lot more insight into the different ways to solve a problem that a specialist might not be able to see.

That said, it's usually a team that builds a product. A good team can have some expert specialists in key domains, and put good generalists in a position to build great products.

The standard response to this is that T-shaped skillsets are the correct answer. Keep your specialty, but have enough broad skills in addition to that specialty to be useful.

I think it's tougher because the standards for good software are significantly higher.

20+ years ago, if you had a website that let people make comments and upload a low-resolution image for others to see, that was seen as pretty freaking cool.

Today, you need to create software that does something like have a 3d VR interface to order pizza, provide real-time maps of where your pizza is at all times, have perfect AI customer service agents that will answer any question instantly, and get it to you in under 5 minutes to barely raise an eyebrow about your tech.

>Today, you need to create software that does something like have a 3d VR interface to order pizza, provide real-time maps of where your pizza is at all times, ...

It could've been so simple:

https://donhopkins.medium.com/the-story-of-sun-microsystems-...

I'd order pizza from that site

I don't think so generally. I've been doing this for a few decades, and it seems to me that overall it's no more difficult or easier than it ever has been. All of the points you make have always been the case, at least during my career. Engineers even older than me tell me the same was true before my career began as well.

In the zoomed-in view, there are some things which are definitely harder and others which are easier. But overall? I don't see a difficulty difference.

The way I see things, the bar is lower than ever to be a good engineer. You put in some minor level of effort and you're 80% above everyone else.

Now, if you scope it to the top 20% of engineers and ask the same question, I'll give you a much different answer:

After you became a decent generalist, I'd refer you to concepts like "invest in yourself, not your job"[1] and just-in-time learning[2].

1. https://critter.blog/2023/10/05/invest-in-yourself-not-in-yo...

2. https://critter.blog/2020/08/14/learning-a-technology-you-do... (coincidentally, by the same fellow as in link #1)

>Invest in yourself, not your job.

This quote echoes through my mind on a daily basis. I don’t know why it’s so hard to action. Maybe because at work it’s easier to get a “good job!” then doing something yourself and affirmations feel good.

It’s a default action of mine.

In my mind, if I don’t know what to work on at any given time, I default to working on self-improvement.

If I’m feeling overwhelmed or confused, I default to self-improvement. This could mean anything from going on a long walk or run, to reading a book, to sitting and reflecting in boredom. It could take 30 minutes or I could devote weeks or months, in some cases, to it.

How do you know what to improve? Meaning, there’s so many options! How do you choose?

Becoming a better and more experienced engineer means learning to better solve challenging problems yourself which implies moving past so much of this noise, especially frameworks.

But, the more independent and self-reliant you become over time, through solving tough problems, the less compatible you become to your peers. Keep in mind most developers only know what they have learned from assigned tasks in the office. Although you have become a much stronger and more capable developer you have simultaneously eroded your career mobility. So, bear this in mind.

What can be done with software is pretty immense now, but I think we tend to underestimate how much code being written in the industry is aimed at the maintenance of applications with only mild to moderate complexity.

If you're a decent generalist, maintenance of pretty much anything isn't that hard unless you're jumping into something low level like C++.

Architecture / building major applications from the ground up is harder, but this isn't that common of a task, and if you're building something mission critical and important, odds are you have a team. Or at least you should.

The #1 barrier in front of me for being a good engineer in my career has been my employer :)

They arrange things in such a way that all other options other than "shitty engineering" are thoroughly eliminated.

Many companies are not interested in good engineering. At least if they admitted it I'd be way less bitter about it. The insult to the injury is when they insist on pretending like they are into engineering.

I think it's more difficult because of #1. I would add that DevOps has mostly turned out as a way for companies to combine the jobs of two people into one, which creates enormous scope and only increases the context switching.

Not by any reasonable standard of "good", which is to say "marginally better than the median engineer".

Reply on news.ycombinator.com