Preferences

Conversely, it may create jobs. Why? Because the more elephants you have in your parade, the more jobs there are for folks to walk behind them with a broom and bucket. For decades we've seen tools that "let users write their own software" and every one of them has driven up the demand for people to clean it up, make it scale, make it secure, or otherwise clean up the mess.

scuff3d
CAD, Matlab, and Altium made electrical and mechanical engineers more valuable, not less.

The work got easier, so what we do got more complex.

seventytwo
They’re all just tools. Use the tools or become obsolete.
catlifeonmars
Kind of a false dichotomy. A great example is debuggers vs print statements. Some people get by just fine with print statements, others lean heavily on debuggers. Another example is IDE vs plain vIM.

Becoming obsolete is a fear of people who are not willing or able to learn arbitrary problem domains in a short amount of time. In that case learning to use a particular tool will only get you so far. The real skill is being able to learn quickly (enthusiasm helps).

numpad0
So, "useless or dangerous tools" is not a self contradictory sentence.

Gas powered pogo sticks, shoe fitting X-ray, Radium flavored chocolates, Apollo LLTV, table saws, Flex Seal for joining two halves of boats together, exorbitantly parallelized x86 CPU, rackable Mac Pro with M1 SoC, image generation AI, etc.

Tools can be useless, or be even dangerous.

scuff3d
AI tools fall onto the category of just in time learning. No, even semi-competent, software engineer is going to become obsolete because they don't know the newest and most hyped AI tool. And anyone stupid enough to hire on that basis isn't worth working for.

How processors work, cache and memory work, how the browser works, data structure and algorithms, even design patterns are all important foundationaly knowledge. How to tell an AI to shit out some code or answer a question definitely isn't.

camillomiller
This has been a stable source of business for a while in my niche.
sodality2
Also true! But that world is one where the vast majority of time is spent cleaning up slop code, so if there's a general shift towards that, I think that still changes the job in a significant way. (I don't have extensive history in the industry yet so I may be wrong here)
MarkusQ OP
<tired old fart voice>

It's all cleaning up slop code. Always has been.

</tired old fart voice>

More optimistically, you can think of "user created code" as an attempt at a design document of sorts; they were trying to tell you (and the computer) what they wanted in "your language". And that dialog is the important thing.

ryandrake
Seriously. Unless you're one of the vanishingly rare few working with true Greenfield projects that start with an empty text file, you're basically cleaning up other developer's legacy slop.
I mean even when I'm working on my own projects I'm cleaning up whatever code I wrote when I didn't yet know as much about the shape of the problem.
danielscrubs
We still don’t know what good code is. It is all contextual, and we can never decide what that context should be. We are influenced by what is hip today. Right now is static typing using Rust, tomorrow it might be energy usage with assembly, after that it might be Python for productiveness, after that C# for maintenance.

We can never decide, we just like learning, and there is little real, impactful research into programming as a business.

In two decades we will still collectively say ”we are learning so much”, ignoring that fact.

This item has no comments currently.