My take is software is a new form of literacy- not some neat technology like lasers or combustion engines. It's about human knowledge and human co-orindation - and we will all have to code just as we all have to be literate.
As such how many human systems today have not been fitted and overtaken completely by the written word? Some maybe but precious few
There's a lot of language in formal math and science that isn't talked about in a way that assumes everyone will learn it. If you don't know how to code you aren't illiterate.
-some guy who was wrong about cars in 1980 probably-
Latest instance: ChatGPT and the hype around it.
In one sense they are myopic. In another sense they are thinking further than anyone else.
Now, if you think machines are better off than the human race at a next evolutionary stage then... that's a totally different story. That might actually be true, and we might be the wrong species to continue on. In that case, software would be a solution.
But you cannot convince me that software for the sake of software is a solution to human problems.
No it will not solve all problems and AI will certainly solve many problems that were previously unsolvable.
At most people working on LLMs are gambling on the idea that AI can solve every problem solvable by something as intelligent as a human.
The economic side effect is a different story to the problem at hand.
I think the only way you can avoid that is by almost annoyingly probing to find the root of problem (because it is often some broken or stupid human process). Most of the time, it does not require more software to fix, and the problem is to do with process complexity. If you can simplify that, any software you write will be more minimal.
So yes, the problem as always is with people IMO and having to educate/convince them to change their ways (or at least, open their eyes to a different solution). I guess this makes me a Type 2 as described by the article (although it naturally oversimplifies each archetype).
What some people might not want to hear is that, yes, I think you unfortunately can only excel at problem solving as an engineer if you also are good at the "product" management part.
I have a way more controversial opinion in industry that is a bit spicy... I think if you aren't coding the solution to the problem, you shouldn't be allowed to define the solution or get anywhere near it. In other words, even to my favorite PMs I've worked with - I think your job exists because many engineers are anti-social and don't want to talk to people. For the ones that do collaborate well, a PM is unneeded on the team and would be a detriment. It's not a personal knock - I just believe that to be the truth. The original agile manifesto got it right and we have collectively fucked it up.
That said, good product management is still worth its weight in gold. Someone who is willing to put in the work in terms of analyzing user behavior, has good UX instincts and respect for engineering can add a lot of value and magnify the impact of the team. It’s rare, but definitely a force magnifier for the team.
I think you're on the right track here, but from the wrong direction. You pretty much stated it earlier:
> the only way you can avoid that is by almost annoyingly probing to find the root of problem
I approach this as: if someone brings a solution, mostly ignore it and start asking "why?" until you're back at a root answer like "so my business can make money". I can't even count the number if times someone has proposed a solution where I've done this and not only ended up with something simpler and faster to build, but a better or more complete solution.
This often comes in like "just build a button to export this data to csv", which if you probe is actually "..So I can get it into Excel easier" ... "So I can reformat it to bring to this other system". The result is something like "what if we push the data to their API, that we already have integrated with, once every hour?"
Sometimes it's software, sometimes it's not, mostly it ends up being a mix -- but importantly if you don't ask "why" enough, you'll solve the wrong or at best only an intermediate problem.
Type 3 - Junior Engineer - I write software.
Type 1 - Intermediate Engineer - I write software for people.
Type 2 - Senior Engineer - I write software robust to the idea that people make mistakes.
So, for some software "I write software" can be better than type 1 and type 2. What if that were the case for the majority of software that would make money?
However, I propose that this doesn't matter, since another type of engineer is higher than these 3 types.
Type 4 - Principal Engineer - I write software and I have Virtue: I get to speak words; maybe you can speak too but I won't listen, but I'll make sure you don't think negatively (enough) of me to try to reduce my Virtue. For example, I'll spend time carefully listening and explain truthfully how things are complicated until our time to chat is up.
The truth is that there are big differences in techie types. The hardware people are radically different from the software people, and on the software side alone, there are at least three subspecies of programmers, two of which we are interested in here.
Forget about the first subspecies, the lumpenprogrammers, who typically spend their careers maintaining mainframe computer code at insurance companies. Lumpenprogrammers don’t even like to program but have discovered that by the simple technique of leaving out the comments—clues, labels, and directions written in English—they are supposed to sprinkle in among their lines of computer code, their programs are rendered undecipherable by others, guaranteeing them a lifetime of dull employment.
The two programmer subspecies that are worthy of note are the hippies and the nerds. Nearly all great programmers are one type or the other. Hippy programmers have long hair and deliberately, even pridefully, ignore the seasons in their choice of clothing. They wear shorts and sandals in the winter and T-shirts all the time. Nerds are neat little anal-retentive men with penchants for short-sleeved shirts and pocket protectors. Nerds carry calculators; hippies borrow calculators. Nerds use decongestant nasal sprays; hippies snort cocaine. Nerds typically know forty-six different ways to make love but don’t know any women.
Hippies know women.
In the actual doing of that voodoo that they do so well, there’s a major difference, too, in the way that hippies and nerds write computer programs. Hippies tend to do the right things poorly; nerds tend to do the wrong things well. Hippie programmers are very good at getting a sense of the correct shape of a problem and how to solve it, but when it comes to the actual code writing, they can get sloppy and make major errors through pure boredom. For hippie programmers, the problem is solved when they’ve figured out how to solve it rather than later, when the work is finished and the problem no longer exists. Hippies live in a world of ideas. In contrast, the nerds are so tightly focused on the niggly details of making a program feature work efficiently that they can completely fail to notice major flaws in the overall concept of the project.
Conventional wisdom says that asking hippies and nerds to work together might lead to doing the wrong things poorly, but that’s not so. With the hippies dreaming and the nerds coding, a good combination of the two can help keep a software development project both on course and on schedule. The real problem is finding such superprogrammers in the first place. Often they hide.
- Robert X Cringely, Accidental Empires
https://www.cringely.com/2013/02/10/accidental-empires-part-...
In my experience there are far, far more Type 3s: Software engineers that completely ignore the system that the software is a part of, and myopically assume that the only solution to any problem is more software.