Remix.run Logo
the_real_cher 5 hours ago

Was it ever? It's always seemed weird to me that people even think 'software engineering' is a career.

It's a tool for knowledge work.

No carpenter is a specialist in drills.

It seems to me that the best way to navigate a long term career is to have another specialty and use software engineering as a tool within that specialty.

Aurornis 4 hours ago | parent | next [-]

It most certainly was a lifelong career.

I’m kind of confused how you might think it wasn’t. Going through a career as a software dev until retirement was very common.

Software engineers didn’t just disappear after age 40.

aleph_minus_one 4 hours ago | parent [-]

> Software engineers didn’t just disappear after age 40.

At the end of the 90th and beginning of the 00th ("dotcom bubble") it was a common saying that if as a programmer, when you are 30 or 40, you don't have a very successful company (and thus basically set for life), you basically failed in life; exactly because "everybody" knew that programming is a "young man's game" (i.e. you likely won't get a programming job anymore when you are, say, 35 or 40 years old).

So,

> Software engineers didn’t just disappear after age 40.

is rather a very recent phenomenon.

atmavatar 3 hours ago | parent | next [-]

Enter the carousel. This is the time of renewal.

selimthegrim 2 hours ago | parent [-]

I'm not sure anyone under 40 is getting that reference.

Aurornis an hour ago | parent | prev | next [-]

> At the end of the 90th and beginning of the 00th ("dotcom bubble") it was a common saying that if as a programmer, when you are 30 or 40, you don't have a very successful company (and thus basically set for life), you basically failed in life;

This wasn't common anywhere except for maybe the Silicon Valley bubble.

The rest of the US and even the world could see that not having a very successful company of your own is to equal to being a failure.

GrinningFool 4 hours ago | parent | prev [-]

> At the end of the 90th and beginning of the 00th ("dotcom bubble") it was a common saying that if as a programmer, when you are 30 or 40, you don't have a very successful company (and thus basically set for life), you basically failed in life; exactly because "everybody" knew that programming is a "young man's game"

That seemed commonly held among folks participating in the dot-com bubble. Plenty of people had been doing it for decades even as the bubble was growing.

> Software engineers didn’t just disappear after age 40.

>> is rather a very recent phenomenon.

Not really. It's not that they disappeared, it's that they're a small fraction of the overall SWE population as a side-effect of how much that population has grown.

strken 4 hours ago | parent | prev | next [-]

Software is wood, not drills, and if we somehow invented bacteria that gradually built an ugly but saleable house when fed on water and nutrients and nudged into shape, I bet carpenters (well, framers or whatever they're called in the US) would have an identity crisis too.

jdc0589 4 hours ago | parent | prev | next [-]

I kind of disagree. You are describing a kind person who is extremely valuable, a person who is proficient in SWE but also has domain specific skills in some niche.

That's great, but its nowhere near the norm, and people have been doing generalist software engineering for decades. There has been a sufficient amount of work for a long time to be performed by generalists that it has been a very reasonable career.

IMO AI is the first thing that has ever actually challenged that.

azath92 4 hours ago | parent | prev | next [-]

Id disagree with this analogy: "No carpenter is a specialist in drills." and i think its an interesting lens through which to look at the evolution of our tools.

I think there are trades where tool (or process if i may be allowed to extend the analogy) specialists exist and are highly valued. My dad is a plumber, so ill use that example but id trust similar is true for carpentry. there are specialists by task/output (new construction, repairs, boilers etc) but also tool specialist plumbers and companies for example drain clearing equipment or certain kinds of pipe for handling chemicals other than water are very specialised, and there are roles for them because the thing they enable, and the criticality of the task, and often the cost and complexity of using the tool are high enough to make specialisation valuable.

IMO software has, for the 10 years ive been working in it, been in an unusual position where the tools (languages, engineering practices, tech stacks) were super technical and involved, but also could be applied to a large number of problems. That is the perfect recipe for tool specialists: complex tool with high value and broad domain/problem space applicability.

Because of that tool specialisation, we've separated the application of the tool to a problem/domain from the tool use. reduction of complexity of applying these tools to many problems, means all domain specialists will use them, relying less on tool specialists.

imaging a mcguffin tool for attaching any two materials together, but which took a degree to figure out (loose hyperbole here), that sudenly you could use for 5 bucks and a quick glance at the first page of the manual. An industry that used to have lots of mcguffin engineers, would be mega disrupted, and you could argue that those tool specialists would have to identify more with what they were building than the mcguffin they were using.

randcraw an hour ago | parent [-]

Yeah, IEEE Spectrum has responded to the dissimilar roles in SW dev by ranking programming language popularity contextually, by separating the project domains and ranking the languages only within each domain. That's a lot more useful than allowing the single dominant project domain to silence the recessive ones, as TIOBE does.

chasd00 4 hours ago | parent | prev | next [-]

I tell my boys (both in HS now), the combination of a specialized skill/knowledge + competent computer programming is the sweet spot. For example, my oldest wants to go into Petroleum Engineering which is great but I told him to still learn software development and get comfortable solving problems with code. Having specialized Petroleum Engineering knowledge combined with being a competent software developer is a powerful combination.

randcraw an hour ago | parent [-]

Yeah, I've seen the same thing happen to data miners in the pharma industry. An increasing fraction of young biologists have skill in basic statistical DM as well as web search proficiency sufficient to gather DM code analysis examples, even without using AI. In the very near future I expect almost all R&D exploratory DM will be done by pharma domain experts (biologists and chemists) rather than served by DM experts (computer scientists or engineers).

jake-coworker 4 hours ago | parent | prev | next [-]

I think the logical next step is that "XYZ knowledge worker" will become a software engineer of sorts. Not literally writing code, but at minimum encoding processes/workflows into some language.

If you're a paralegal or an accountant who can't manage their workflows with AI, you're going to be way less productive than someone who can.

And if you're a paralegal or an accountant who can manage a lot of your workflows with AI, you don't need custom software (hence less dedicated software engineers).

delusional 4 hours ago | parent | prev | next [-]

> No carpenter is a specialist in drills.

There's no category difference between being an expert in carpentry vs masonry and being an expert in drills vs hammers. They are both just areas of expertise.

Going down the path of trying to define what is expert functions and what is "merely" a tool using anything but descriptive technique is nonsense.

Expert functions are just those areas where using a tool is sufficiently difficult to require expertise.

suddenlybananas 5 hours ago | parent | prev [-]

Software engineering isn't a tool, it's the task.