Hacker News Reader

Comment by WJW | Hacker News Reader

The article also points out that programming, even more than other professions, suffers from a lack of available "old people in the trenches" who can pass on these ideas to newcomers. This is because:

- the field has been growing so much that at any point in time the majority of devs will be relatively new. A field that doubles every three years will never have more than 50% of people with more than 3 years of experience, obviously.

- I have no numbers to back this up, but intuitively it feels like more devs "drop out" of software development than in other professions. Many become managers, others take up various non-development projects or retire altogether. This makes it so that even less senior people are available.

View on HN

I think a big part of the "old people in the trenches" problem is that tech has historically had an "up or out" mentality. It seems like most of the older engineers I know either get pushed out or end up as principal engineers where they aren't routinely interacting with the younger people. I've encountered a few people who have managed to avoid this, but it's rare.

It doesn't help that our industry has been incredibly fast-moving compared to most industries, and our interview process is geared toward either being a fresh grad who's taken and algos class recently or knowing all the latest frameworks. Not a lot of places are interviewing on the sorts of experience you gain over a couple of decades in the industry -- which, to be fair, is often more intangible and harder to interview on.

> I know either get pushed out or end up as principal engineers where they aren't routinely interacting with the younger people.

It doesn’t really help that young people always feel like they know better either.

Even if there’s an experienced architect, it doesn’t help if they’re surrounded by 10 rookies. Nobody has the time to guide all of them.

In my experience rookies/interns/jr devs are a pleasure to work with: knowledge sponges. It's a small subset of ones becoming sr devs that can be difficult.

Yeah I also get this feeling that a lot of junior devs decide they don't really want to do it anymore. It's hard to get numbers on it because they will still have a related job title.

Almost 30 years ago I was a freshman cs student and a prof rolled out data that said by the time we were 30 years old, most if us would have already left the field. I can tell you that almost no one I graduated with is still working in tech, and not because we retired early off stock. It’s a challenging field for so many reasons.

Based on my own experience, I don't find it hard to believe that so many want out, but I do find it hard to believe that so many get out and so quickly. These days I find myself wishing I had gone the route of physician's assistant so I could do some tangible, socially-needed work that still pays the bills.

I've actually ended up in a tech job that hits those a bit, so I am doing a bit better these days at least.

It would be interesting to see how that compares with other professions. Do carpenters or dentists leave for other fields at the same rate? How about other types of engineers?

I can only speak of my experience having gone to school for Architecture. They told us that with each recession, the profession loses a generation of Architects. I was wrapping up grad school just before the Great Recession, and professors were surprised that a relatively greater percentage of graduates had stayed in the field due to continued economic prosperity since the mid 90s and the dot com boom hadn't impacted the Architecture field all that much.

Of course, once the Great Recession hit, myself and many others that I graduated with either left the profession for other employment or simply never found jobs to begin with (that was me). Luckily I was already programming in grad school, and what was something I was filling my time with while looking for an architecture job became a new profession and I never looked back. Given all the comparative benefits of Software Engineering over Architecture, it's been a good move for me.

Yeah, for the whole my career in tech, except the first year I had such feeling. Don't want to do it but couldn't leave this golden cage of enterprise bulshit development.

I think the problem is that Computer Engineering is still not an engrained concept in universities. Sure, there are courses where some concepts are taught, but it's difficult if not impossible to tailor your degree towards being a real engineer.

Side note; I suspect you mean software enginee? Computer engineering is absolutely a degree and concerns the engineering of a computer. Starts off like an EE, ends up taking classes like 'microprocessor design' in place of power systems and the like.

This is the thing. A degree is closed-ended. You build things that can be done within a deadline, and have been done within that deadline, by hundreds of groups before you. You study well known problems that are described in many ways in various sources.

When you work, you work on building things that don't have a specific end goal, without a specific deadline, where the success criteria are also not purely academic. To the extent your problem is technical, you may be exploring the cave for a heck of a long time with no light.

You end up fighting with organizational issues as well.

Thats not the only problem. In most engineering you build a mathematical model first, play with it until it's right, and only build the product when you're fairly sure it's going to work.

With a bridge, the model tells you about the forces in the structure, the component tolerances, and the likely behaviour under various stressful and extreme conditions.

Same with EE. Commercial board design uses schematic simulation, automated layout, and loading/transient emulation. You can't do modern commercial PC motherboard design without modelling software. (Well - you can. But it'll take far longer and be far less reliable.)

Software dev is more a case of nailing things together until they probably mostly sort-of work.

There's some guild lore - which changes fairly regularly - but no formal modelling. Realistically it's somewhat informed guesswork based on the current lore, mostly tested by trial and error.

That kind of engineering is surely done for "big" projects but I'm pretty sure my contractor didn't do any FEA modeling when he put up my shed. He knows from experience that normal wooden beams and some steel bolts will be fine.

I think part of the problem is that most of our "raw materials" like nginx and postgres are so robust that you can build really quite large projects without having to do any modeling or other big planning. Things that have millions of users can still be more-or-less slapped together from default parts.

Then how do civil engineers get their degrees?

At university, like everyone else? Sit there, study structures, materials, etc. Get a job, get a charter...

So why can't we have a computer engineering degree as you say?

It's the softness of software that makes it hard.

Building a bridge is something where external participants cannot really tell you much about what it should look like. They know you can't just double the number of lanes or add a train track as you're doing it.

With a software project, people can ask for all sorts of stuff, and because it's soft, some engineer will say "ok let me see if I can look at that for you".

Not only that, if you write your software so that it's rigid, that's bad code! You need it to be flexible so that you can cater for future concerns.

Softness also means you have to keep up with trends. You can write your next website with a newer, fancier js framework, and people can make these new frameworks are just sitting at home at their desk. They aren't mixing new concretes.

Mainly because, every bridge is more like every other bridge than not. Every skyscraper is more like others than not.

While there are some parts of new software that are more similar than not, and these are more 'engineering like'. The majority is not.

Evidenced by; if you did a 'diff' between plans of a bridge you would get a limited number of differences. When you do a diff between an os, browser, slack, the code that runs this site you get a lot more differences. You need to consider each and every detail. This is not 'big-picture'. Big pictures do not construct things.

Sure, there are lots of similar projects and maybe you can apply a more traditional engineering approach to those.

It is interesting to note, LLMS are bringing the similarities out. You can ask for something and it can code up something from something it has seen that is similar. But, as anyone who has used them, will know, it's only partially correct in its interpretation of that simimilarity.

Computer engineering degrees already exist, but they're much closer to the hardware.

Reply on news.ycombinator.com