Two types of software engineers

My experience agrees wholly. And I would add that the type 3 is the most arrogant.

I would say type 3s are correct A the whole system is going to be replaced with software - so you might as well get on with it.

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

I find that our entire industry is encouraging and rewarding type-3 behavior. While tech is definitely a requirement in any business, the tech should always be directed at helping accomplish the business' real goals which is ultimately to make money. Any tech that is above that or deviates from that goal is superfluous and a waste of money/resources/time/brainpower.

The issue I find is that the last decade of free VC money and "growth & engagement" means that there were a lot of companies that were given free money regardless of their profitability or even basic sanity-check of the proposed business models, instead rewarding them based on hype or some unspecified potential to turn some vague idea of "growth" into profit (hint: if your "growth" is based on giving away free stuff, those users will leave as soon as you attempt to monetize them), or "engagement" (engagement is a very uncertain thing to monetize in a world already saturated with advertising).

As a result this has funded entire careers based on what is effectively mental masturbation as opposed to actual tangible improvements in the software's ability to drive actual business value (in many cases it is negative value if you account for the salaries spent on it), only made possible because the free money sidestepped normal market dynamics that would usually encourage businesses to reduce overheads and focus their efforts on profit-generating operations (or go out of business).

My personal experience with technology is that the collective effort spent over the last decade over things that are considered "modern" didn't actually improve the customer experience in the vast majority of cases. Ordering food for example is still ultimately browsing a list of items and submitting a form of what you want, yet nowadays despite orders of magnitude greater bandwidth and processing power, I had to sit through seconds of stuttering while megabytes of JS load, execute and make dozens of subsequent requests to get data that the backend could've embedded in the initial server-side-rendered HTML. Same with Microsoft boasting about how their new Teams taking only 9s to load while Skype from 2009 delivering the same functionality faster on much more constrained hardware.

Type 3 engineers invented chatGPT with the end goal of moving closer to actualizing the reality of Making software the solution to any problem.

In one sense they are myopic. In another sense they are thinking further than anyone else.

I love that you found/acknowledged Type 3. Type 3 is a super easy trap to fall into, especially when you don't understand the problem space.

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.

When I first read the post, I thought the two types sounded very much like two levels of experience in being a Software Engineer. Your identification of the third type strengthens my interpretation of the article in this way.

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.

Hmmm, might be "do the wrong things well", but probably... lumpenprogrammers.

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-...

How do you offload to silicon periodically creating a new private key to sign your future releases, but keep it far away from your builds until you actually will use it, but put its public key on the builds.

I'd say that if you haven't realized that as a doftware engineer, you are essentially enriching the capital wielding class and are essentially just their means to being able to wash their hands of the masses, you're probably either asleep at the wheel, see yourself as a temporarily inconvenienced billionaire, or really have no choice but to further that aim to achieve whatever your own goals are.

The push for AI isn't even trying to reach further than can be grasped; it's the ultimate lottery ticket to the well-to-do.

As an engineering manager, I cannot imagine assuming that people would read something.

Engineering managers think horizontally in an organization, with enough depth in intra-team individuals and inter-team dependencies. There's a lot of similarities to software engineering: understand the product, know enough depth for what you're building, and understand dependencies on the edges.

Core pieces of these for an EM are fundamentals of human behavior, motivation, and process. There are global-ish truths about humans and global-ish truths about complex human hierarchy. For the former: individuals are more likely to get defensive when confronted in public.

For the latter: the same way there is a compounded risk of latency and failure with multiple network hops, there is a compounded risk of mis-alignment with multiple human hops.

I recently worked at a larger company (Stripe) where I was 5 hops from the CEO. Coming from startups, the information loss/skew between the CEO and my team was incredible. I found myself very much aligned with the CEO, which I could confirm by Slacking them. But by the time it trickled down to our team the incentives, motivations, and direction were mildly fucked. Navigating that is part of the craft, which we can feel any kind of way about but doesn't feel entirely avoidable.

"[X] will read [Y]" is a human fallacy, not simply a manager one. See: "just read the docs", "did you read the article you're commenting on", "the code is self-documenting", etc.

> I would say that the person who says "we'll just document the process and people will follow it" is not a software engineer but a "manager"

In general this kind of attempt to automate humans is what kills companies as they get bigger.

More rules and policies, written assuming the humans involved are all idiots and need to not think for themselves.

And then instead of doing the hard work to standardize the systems, just offload all the quirky little differences that have accumulated over a decade onto the humans to try to keep straight, accumulating in a bunch of incredibly poorly written and maintained runbooks or whatever.

I've had this realization recently that software engineers are making far more (multiple orders of magnitude more) "business decisions" for the company than middle managers and MBA types. SWEs are essentially coming up with and codifying the logic that defines how a corporation operates on a very precise level. They're like "officers" more than commodity workers.

Yeah I find myself switching between these two perspectives, so I don't think that one of them characterizes me directly. Actually, very often when building an MVP it makes a lot of sense to just say “let's allow people to do that to keep it simple and just assume that they either don't do it or that later they can explain why they felt the need to do it.” For instance if you can take inputs from one system and push outputs to another system, and those have overlaps, you might assume that your users never create cycles where your software starts pulling in the stuff that it pushed out, so you never check the sorts of loops to make sure that you're making progress, and maybe someday someone configures an infinite loop in it... In practice non-technical users at a small company don't trigger this and are surprised if you build things that read from Y and push back into X, “how is that even possible”.

I think a lot of people may be predisposed to one style or another depending on their personality or background but I agree that part of what makes experience so valuable in our field is being able to make good judgement about when to solve a problem with technology, with process, or not at all.

I actually think I’m too much of the first type and this article makes me realise I probably trust people too much to do the rightTM thing

I thought everything is complex and fragile because the Type 2 people are shoring up towers of nonsense with ever more automated tooling.

Developers should be forced to write more documentation. Because if you create easy to use software, not a lot of documentation is needed.

If you create difficult solutions, you need to create a lot of documentation. And there is nothing that people hate more, than writing documentation :).

My experience has been the same. Many (maybe not most for me) early programmers seem to think their job is to provide for the option of success. Full stop. "Well that would be on them," is often the retort when asked about possible user errors or failure to follow directions.

It can be a hard pill to swallow to realize that we may have reduce the best possible outcome of our work, in favor of the best likely outcome.

Fully agree and can relate to this one very much. As with all other things, the "optimum" is somewhere in the middle between Type 1 and Type 2 depending on the context, but both extremes are an equal PITA.

In what way do they draw it out? Is it because they bring up things you hadn't considered in your initial "just do X" solution?

Managers explicitly demand Type 1 thinking, because, you know, deadlines exist and stuff.

If the author just wants to stop at "Type 1 bad, Type 2 good", you could just as easily say "Type 1 cares about shipping and Type 2 doesn't".

Agree completely. A society that thinks about the welfare of children is great but you hate to be always on the receiving end of "will anyone think of the children??!". I don't know where I was going with that analogy

I think a good example of an example from the blog where simply "we don't do that is" the deployments. I've been at multiple companies where they had multiple rules about deployments and often one of those was we don't do deployments late Friday.The whole "what if they do" is solved by we fix the issue we cause and tell them not to do it again and if they do we remove their ability.

The "how do we ensure they read it" we make it a requirement and if they don't get rid of them.

The 2nd type isn't smarter and wiser as the author wants to protray. They're just someone constantly worried about what ifs. There are always what ifs. And often these what ifs are minor problems if they do happen.

While what the exec said is strictly true, I think you are still on the correct side of the equation. Just that the question shifts for a mandatory tool from enticement to "how do we make this helpful and useful or at least not horrifically painful to use?" Because humans are endlessly creative at exercising their choice even when it seems to have been taken away.

In the most extreme case they will leave the company and talk about how terrible the processes are. More likely they will be somewhere on the spectrum from doing the bare minimum to malicious compliance. Even for a rigorous and required process you still have to get some buy-in or you won't get the results you want from people.

> I've seen a lot of programmers fall into what I'd call the bureaucracy trap. Bureaucracy is often very attractive to a certain type of engineering because it's essentially programming the behavior of other humans.

That is very insightful and reading it now I wonder whether this isn’t the point I’ve been trying to make (author of post). Thank you!

> and create incentives

this... is 99% of times missing. Even the "We'll fire them" mentioned elsewhere in some comment, does not always work.

Not quite a law, but "false dilemma" starts to express what you're looking for. If someone says you can only choose between A and B, it's false. You can often choose neither or both.

I went to college 2009-2015 and I am utterly grateful for my HCI/UX courses (degree in Information Systems including a Business/Entrepreneurship Minor at Drexel University)

There is a spectrum.

You can have manual or half-automated processes when there are very few people. For me the threshold is 3 devs. Then you need to codify the processes.

Some people don’t bother setting up CI when they are the only developer. Others don’t ever leave the “I’m the only developer” mindset.

I think if you're wading through people muck you're probably doing something wrong. If your solving a problem for someone getting people to do something to solve their pain is generally easy.

Author here. Yeah, that’s fair, it is over-generalizing (and I even admit to that in the post).

I do think there might be some value (insight?) into trying to generalise things sometimes. In this case it’s me trying to split all software engineers along a single axis and seeing whether it fits. I don’t think it’s a neat split, but the more I think about it the more I think I could, if pressed, sort a lot of engineers into one of these two buckets. Not at all times, but sometimes.

Generally speaking: over-generalisation can be lazy and it was in this case — I write these posts very quickly, as a braindump, and you shouldn’t read too much into it, except that it might be food (snack?) for thought.

Seems completely orthogonal.

I'm pretty sure you're just describing type 2. At its basis, the article is just about some people being good at risk management and some having no concept of it. He connects this to dealing with humans, but that's just because humans are imperfect and illogical at times and thereby introduce behavioral risk. It's really just about learning to ask what could go wrong. You can then take that further by acting on the answer to that question and optimizing away that risk as much as possible.