16 ms·

Two types of software engineers

203 points by hasheddan 4y ago

fefe23 4y ago
I relly like this insight. How do you think people fit in thee who want to build "self-healing" systems?
jvanderbot 4y ago
All software engineers can be categorized into one of two classes. Proof: Those who believe this statement and those who do not.
d23 4y ago
The worst part is when it’s a difficult thing to accomplish technically and you know it’s going to be a pain to wade through the people muck.
- that_guy_iain 4y ago
  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.
lifeisstillgood 4y ago
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" - someone who thinks they can offload their difficult bits to employees. The software engineer wants to offload their difficult parts to silicon. And would love the opportunity to code up a "process engine" that would ensure people can easily follow the process online. The takeaway for me is that managers who think they can offload to people have missed the tide - coders are the new managers because their workers are silicon, don't complain and so as they are told coders are the new managers because CPUs are the new workers.
- bombolo 4y ago
  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.
  - ttymck 4y ago
    Something like https://www.vaultproject.io/ https://www.vaultproject.io/ or similar?
    - bombolo 4y ago
      If you're content with using cloud storage as "secure"…
      - looperhacks 4y ago
        You can run vault on your own infra
        contingencies 4y ago
        Type 2
        bombolo 4y ago
        Still less secure than not have it online?
- salawat 4y ago
  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.
bigguycodes 4y ago
I find myself switching between the two types depending on how big the userbase is. If its an internal tool used by a single team consisting of 6 people, I'd fit right into type 1. OTOH, services with bigger userbases like a public facing web app definitely require the type 2 approach.
- sshine 4y ago
  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.
hsn915 4y ago
Type 1 is the most common type of programmer I've seen, and they are the reason everything is complex and fragile. Most programmnig jobs force you to spend most of your time editing config files and trying to figure out why when you tried to use the library to do X it doesn't work properly! And then it turns out that you "just" have to configure Y and Z in particular ways, and you also need to make sure K is setup correctly at time T.
- masfuerte 4y ago
  I thought everything is complex and fragile because the Type 2 people are shoring up towers of nonsense with ever more automated tooling.
  - hsn915 4y ago
    I'll give you an example. Here's the official Ubuntu documentation about how to install WordPress on your Ubuntu server. https://ubuntu.com/tutorials/install-and-configure-wordpress#2-install-dependencies https://ubuntu.com/tutorials/install-and-configure-wordpress... I want to focus on steps 2 through 6 They are all about configuring the system/envnironment. There are some tools that automate some of that. For example, you have to install about 10 packages. The installation of each package is mostly automated, except when it breaks for random reasons, but aside from that, even if it was perfect, you still have to know which packages to install and type out the commands to install them. Type 1 in the OP is the type that thinks this is very simple and is not a problem that needs solving. Step 4 in the guide has you edit config files in specific locations and execute some commands in a specific order. Again, each step, on its own, would sound "simple" to the type 1 programmer in the OP. Step 5 would have you configure a database. Again large parts of the process are automated .. but .. The whole process is complicated because at each step along the way someone thought the task is simple and their job is done and they just move ball down the field: it's not their responsibility anymore. A type 2 engineer in my book would try to design the system so that they _avoid_ the need for all this cruft.
    - bombolo 4y ago
LeonigMig 4y ago
more like two different ways of approaching a problem which crop up quite often designing socio-technical systems it does puzzle me how programmer culture is to over generalise as if its some epiphany or fundamental principle in fact this blog just diagnoses two common viewpoints or perspectives perhaps its just a style thing to get engagement with a blog
- misternugget 4y ago
  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.
jensneuse 4y ago
I'm type 3. When presented with a problem, I will not stop with W-questions until I think I found the root cause. I find it super interesting to understand the behavior of others. That's often a great way to find new business opportunities. Example: My company (https://WunderGraph.com https://WunderGraph.com) has a discord server with roughly 700 users. It's an absolute Goldmine to find new business. People being a problem, you ask for their use case and that way, you might learn where your company really creates value for someone else. I'd consider this "type 3" as the business engineer. Using software as a function to create business.
- remram 4y ago
  Seems completely orthogonal.
  - jensneuse 4y ago
    I see it differently. It's most of the time wrong to jump from problem to possible solutions, tech or people solutions. Without finding the root cause, any solution will just fix symptoms.
    - remram 4y ago
      The article is about how you perceive the problem, it's not about solutions at all. And your "root cause" is still a problem which you have to fix, it's not like your way of doing things allow you to not have to solve problems ever.
- IAmGraydon 4y ago
  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.
tulio_ribeiro 4y ago
I wonder if there is a way to bridge the gap between them and find a balance between simplicity and robustness. I think type 1 and type 2 are not mutually exclusive, though. Maybe they are more like tendencies or preferences that can vary depending on the context and the problem. Sometimes, it might be more appropriate to focus on the technical aspects and sometimes on the human ones.
jt2190 4y ago
Both Type 1 and Type 2 describe engineers who acknowledge that their software is part of a larger system run by humans for some purpose. Type 1 and Type 2 make a different decision about where to draw the boundary between the software and the people. 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.
- sdfghswe 4y ago
  My experience agrees wholly. And I would add that the type 3 is the most arrogant.
- lifeisstillgood 4y ago
  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
  - croo 4y ago
    From 20 years now on everyone will drive a car so everyone will be a car mechanic! -some guy who was wrong about cars in 1980 probably-
    - archgoon 4y ago
      [dead]
  - htag 4y ago
    I think the software as language/literacy metaphor is taken too far. A lot of this is because Chomsky was such an influential thinker, and people take it too far. 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.
ravenstine 4y ago
I assume that every problem is hard. There's been enough times I've worked on codebases where even changing a string was a headache, thus it's difficult for me to give an estimate that think will represent reality.
photochemsyn 4y ago
How about three types? 1) Engineers who work on the external-facing side of the interface (possibly involving using many interfaces to build something with a user-facing interface, e.g. many app writers) 2) Engineers who work on the internal, engineer-only side of the interface (maximizing performance, optimizing at a low level, e.g. library writers) 3) Engineers who design systems by building interfaces at the correct points in the overall design that separate (1) from (2) (network engineering might fit here).
mkl95 4y ago
I see this all the time in distributed systems. More often than not some oh-so-simple guy will "lead", leading to a system full of potholes due to concurrency shortcomings etc.
phillipcarter 4y ago
> Here's the kicker though: it's the opposite! It's not cynicism, type 2 engineering is embracing the fact that we build with and for people and taking on an even bigger challenge of doing work despite the chaos this produces. YMMV, but I've run into plenty of Type 2 engineers who absolutely use it as an excuse to not do something or draw out what is often just a 15 minute conversation and a 15 minute coding session. It sucks to work with them.
- lpapez 4y ago
  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.
- cratermoon 4y ago
  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?
  - phillipcarter 4y ago
    > Is it because they bring up things you hadn't considered Nope. Almost every time it's just a lack of drive to actually go and have that conversation. And almost every time, the conversation for a thing that's "complex" is short, there's no blockers, and the thing isn't actually that complex.
  - Phelinofist 4y ago
    IMHO you don't have to consider everything. Not every potential case warrants additional complexity or maintenance effort. Not doing something and offloading it to the user is valid.
- popularonion 4y ago
  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".
CSMastermind 4y ago
Is there a "law" (razor in the philosophical sense) that states until proven otherwise you should assume all dichotomies are false? What the author gets at though I do think is important. 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. Even if the tradeoff is that overall, an organization is less productive but more consistent that's a very attractive proposition to these engineers. Anything that makes other people behave predictably is welcome. Of course humans are, at best, faulty in their rule adherence (there's a subreddit called "malicious compliance" for a reason). So engineers who assume that everyone will just follow the rules end up surprised when someone breaks them. Part of being a "hacker", at least in my definition, is being able to diagnose the actual dynamics of a system whether technical or social. That doesn't mean I submit to the view that you should go around paranoid forsaking the tool of bureaucracy entirely. Nor do I think there's any social status conferred by openly breaking rules (a mistake that I see a lot of young hackers make). As XKCD (https://xkcd.com/1494/ https://xkcd.com/1494/) might say, "That cool hack you just thought of is called fraud and we already know about it." Rather I'd suggest that if you feel inclined to write formal rules or policies for the behavior of humans you should instead write guidelines, define principals, and create incentives. Focus your time on aligning everyone on the goal not the process to achieve it. Accept the things you can't control.
- misternugget 4y ago
  > 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!
- svilen_dobrev 4y ago
  > and create incentives this... is 99% of times missing. Even the "We'll fire them" mentioned elsewhere in some comment, does not always work.
- daniel_reetz 4y ago
fozzbezzem 4y ago
Funny, this is exactly how conversations go between me and my lead where my lead is the type 1.
deleted 4y ago
[deleted]
rgoulter 4y ago
If you come up with a way of describing two things, I'd encourage better names than "thing 1" and "thing 2". "false positive" and "false negative" are easier to understand than "type 1 error" and "type 2 error".
LastTrain 4y ago
Many or most of us are both types - because sometimes the first approach is warranted, and other times the second approach is. I would warn against pigeonholing people - for a time worn view on this google the “the bozo bit”.
- crdrost 4y ago
  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”.
- rebeccaskinner 4y ago
  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.
  - SoftTalker 4y ago
    I think it's also a matter of experience. You learn the hard way that people don't follow instructions, don't read their email, and often try to use the software in ways you never imagined. I was much more of a type 1 engineer when I was young. I read my email, I read instructions... doesn't everyone?
- adamors 4y ago
  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
sublinear 4y ago
> type 2 knows that at the heart of all of their engineering work (and problems) are people This is only true for justifying the "work" and some of the high level definitions of the "problems". The same challenges exist on personal projects where the justification is arbitrary and can be nudged to get optimally simple problems (well made products) to fall out of it instead of ugly tangled knots (poorly made products).
andix 4y ago
I put developers in those two groups: A solves easy problems with complex solutions. B solves even complicated problems with simple solutions.
giantg2 4y ago
The hardest problem is non-technical - convincing people of something. Whether that's a design, technical strategy, sales, or budget.
throw310822 4y ago
Slight criticism: from the given examples, seems obvious that type 2 already knows the solution proposed by type 1 (apparently it was a very easy one), and also does one step further, asks how it impacts the users. So what this types theory really says is that there are devs who cannot think about their solutions in context, and devs who can. And then, in this case: it's really a continuum, and obviously it's not two types but just worse and better developers.
29athrowaway 4y ago
To me, the main difference are the ones that ask why, the ones that don't.
svat 4y ago
All disagreements are about "weights", and it's instructive to ponder what this one is about. IMO giving people a process/documentation does help to some extent, so the dichotomy the author presents here is between those who think doing so mostly solves the problem, and those who think most of the way is still left to go: so this one is I guess about the weight one attaches to the question of how much the non-technical solution solves the problem / how much you can rely on people to do what you'd like them to do, etc. And while experience may often involve lowering that weight over time, it's also important not to get too cynical (set weight to 0), and continue to attempt to estimate the parameter accurately: maybe the "ask people to do X" solution will give you a 30% probability they'll do X in any particular instance -- then ask how ok that is, etc.
great_psy 4y ago
I assume the further away your system is from non technical customers, the more type 1 you can be. I assume nvidia video card designers can be type 1, because other technical people will be interacting with their system. And if those people don’t do read the docs, and interact exactly how they should, it just won’t work. Now if you work at adobe and are designing the video editing software that deep down actually uses those video cards, well you need to be type 2. The success of your product is more dependent on how well “the software does what the user intended” where intended might be a very subjective thing, likely based on other features that other similar software has, not related to anything technical.
deleted 4y ago
[deleted]
tpoacher 4y ago
The problem isn't that the two types exist. The problem is that each type thinks they are the solution, and the other type is the problem.
cratermoon 4y ago
These categories are useful enough to apply not to just engineers, but also to engineering managers. You would perhaps think that part of going into management is being more understanding of people and the problems that occur when a "simple" engineering solutions meets human nature. And yet, I've worked with managers drawn from engineers who still operate as if the people working for them are simple machines. All they have to do is read the requirements, give accurate estimates, follow the process, use the tools, and TADA out comes working software that meets user needs.
deleted 4y ago
[deleted]
cj 4y ago
Type 1: people who live in code Type 2: people who live in code and understand the needs and dynamics of the larger business
sopooneo 4y ago
Early in my career I was working on a strictly internal business process tool. I'd cut my teeth playing with public, free web tools, so had my head around the idea that I would have to entice adoption. In a meeting with one of the executives, I was fretting over whether some feature was user friendly enough, and I asked, "but what if they don't use this part?". He looked at me baffled, then responded, "then we'll fire them." And as brutal as it sounds, he was right in that case, at that company. There were rigidly defined process rules for the front line workers, and as long as instructions were clear, people followed them. So I think there's a balance to be reached here, and I've had to come to peace with the idea that sometimes the answer is to hire an army of temps for a week to do some slogging task, rather than automate it. Sometimes.
- that_guy_iain 4y ago
  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.
- alwaysbeconsing 4y ago
  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.
issa 4y ago
I think most engineers need to be both. In most situations at least, you are deciding on engineering time vs non-engineering time. Meaning, if I can build something in a day that "gets the job done" with some usage constraints, or I can spend a week to build something that removes all constraints, then I need to calculate the trade-off. Could something more useful be built with that extra time? At least in start-up world, I find myself calculating that trade-off a lot.
phforms 4y ago
As much as I agree how important it is to design software with a type 2 mindset, I believe that there is also the trap of not taking any risks because you constantly fear it would not serve your users well enough, they would never use it, it would be too complicated for them, etc. We have to know our target audience well and always question our assumptions about them, because sometimes it may be surprising to see what users are willing to learn if they feel it is worth the effort. And sometimes it may be worth losing a part of that audience while the ones that stay will be much more convinced about what the product can give them back.
Nimitz14 4y ago
This website causes my mobile Firefox to hang and effectively crash.
kodah 4y ago
Not to undermine the post, but this to me seems like, "mature software engineer" versus "non-mature software engineer" with the caveat that not all engineers make it to maturity.
dep_b 4y ago
When building small scale one off applications for small businesses I’m type 1, building a mobile application for the masses turns me into type 2. Mobile users should be approached as retards.
smoyer 4y ago
I wish they'd had degrees (or even classes) in HCI when I was in school. HCI and UX in software have less to me rethinking a lot of my hardware engineering too.
- neon_electro 4y ago
  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)
ilumanty 4y ago
It feels like Type 1 is the “yes” type, and Type 2 is the “yes, but” or “no” type. Saying “yes” is easy, everything else not so much. Personally, Type 2 resonates with me, but I can see how this can be generally conflated with pessimism.
drewcoo 4y ago
There are two types of software engineers . . . those who wrestle the world into neat, tight dichotomies and those who realize that's not how things work.
liquidise 4y ago
I've written about a similar topic in the past, referring to the Types 1 and 2 as "brave" and "careful" developers. The titles are less important than the impact each brings. The "we'll just do X" developer tends to think about codebases as they do the customer. "We'll just refactor <huge system>" or "we can just include <major new subsystem>". Type 2 devs, in contrast, are far more careful in their approach to the codebase itself. The two balance each other out in the right ratios. Left to their own devices, Type 1 will bring innovative changes to a system while Type 2 naturally improve the stability of the system. I just think you want 3-4 Type 2's for each Type 1 you have on a team.
rawgabbit 4y ago
What the author is describing is known as "friction" or the "fog of war" has first expounded by Clausewitz. Everything is simple and straight-forward when you are dealing with your immediate team of a few people. The same task is extraordinarily difficult when you have to collaborate outside of your team, or have someone actively opposing you or trying to deceive you. You are also assuming the "people" will behave in a certain way. Your company can treat front line workers like robots and must follow a certain script. Or you company can treat front line workers like independent thinkers and empower them to make limited decisions. IMO. None of this really matters. What matters is correctly diagnosing the problem in the first place. And correctly diagnosing the capabilities of your tools and your employees. Once you have an accurate picture of the problem, the solution will come readily. The problem is no one wants to admit their short comings or limitations. They will always say they can do everything you ask of them. Then you tell them about the budget and limited time frame. And they still say they can do everything. What we need is productive candor.
the_cat_kittles 4y ago
type 1 thinking is just outsourcing the actual problem to other people
yafbum 4y ago
Both types are engaging in product definition work without a second thought to how to do it. Even the second type does it without asking themselves what users would actually enjoy or prefer (depending on what the product goals are), and sounds just being afraid of asking people anything. And many times, going on an actual fact finding mission can bring some light that pure engineer to engineer conversations will never uncover.
smsm42 4y ago
I'd call them "naive" and "experienced".
dgunay 4y ago
Type 1 is the right move in certain situations, but I've been forced to just let many preventable problems happen because a Type 1 person in power cannot be convinced to see the Type 2 take on something. It's pretty demoralizing.
ozim 4y ago
I say there are problems that cost more to fix in code and there are problems that are cheap to fix in code. There are problems not worth fixing with telling people - if they fall in such ways we get support ticket and someone will explain to the user what just happens. If this happens too often only then we know it is becoming worth fixing. So for me article is wrong because author assumes there should be answer or solution for each and every problem. So 1st type of dev might be right a lot of times because how often does it happen that people deploy at the specific time? If it never happens in reality you just waste time solving it. On the other hand if it happens you will have to solve it then you might need action plan for it but … most likely you can just let people make mistakes and fix them on the spot.
palata 4y ago
IMHO, the whole art of software engineering is to get it right on a case by case basis. There is no one rule for that. Sometimes it is fine to assume that the user will "do it right" (it is fine to assume that a military pilot learns how to fly the plane before taking off), sometimes it is not (it is not fine to assume that a customer using an ATM knows how to build a Linux kernel). The whole point of software engineering is to build an abstraction that makes sense for the targeted user. This requires experience (which is tricky considering that most developers have less than 5 years experience :-) ).
rkargon 4y ago
And Type 2 have GOT to GO! "Grand sprint opening, grand sprint closing!"
mock-possum 4y ago
type 1 brings customers in, type 2 ensures they stay with you.

203 points by hasheddan 4y ago

I relly like this insight. How do you think people fit in thee who want to build "self-healing" systems?

All software engineers can be categorized into one of two classes. Proof: Those who believe this statement and those who do not.

d23 4y ago

The worst part is when it’s a difficult thing to accomplish technically and you know it’s going to be a pain to wade through the people muck.

that_guy_iain 4y ago
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.

lifeisstillgood 4y ago

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" - someone who thinks they can offload their difficult bits to employees. The software engineer wants to offload their difficult parts to silicon. And would love the opportunity to code up a "process engine" that would ensure people can easily follow the process online. The takeaway for me is that managers who think they can offload to people have missed the tide - coders are the new managers because their workers are silicon, don't complain and so as they are told coders are the new managers because CPUs are the new workers.

bombolo 4y ago
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.
- ttymck 4y ago
  Something like https://www.vaultproject.io/ https://www.vaultproject.io/ or similar?
  - bombolo 4y ago
    If you're content with using cloud storage as "secure"…
    - looperhacks 4y ago
      You can run vault on your own infra
      - contingencies 4y ago
        Type 2
      - bombolo 4y ago
        Still less secure than not have it online?
salawat 4y ago
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.

bigguycodes 4y ago

I find myself switching between the two types depending on how big the userbase is. If its an internal tool used by a single team consisting of 6 people, I'd fit right into type 1. OTOH, services with bigger userbases like a public facing web app definitely require the type 2 approach.

sshine 4y ago
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.

hsn915 4y ago

Type 1 is the most common type of programmer I've seen, and they are the reason everything is complex and fragile. Most programmnig jobs force you to spend most of your time editing config files and trying to figure out why when you tried to use the library to do X it doesn't work properly! And then it turns out that you "just" have to configure Y and Z in particular ways, and you also need to make sure K is setup correctly at time T.

masfuerte 4y ago
I thought everything is complex and fragile because the Type 2 people are shoring up towers of nonsense with ever more automated tooling.
- hsn915 4y ago
  I'll give you an example. Here's the official Ubuntu documentation about how to install WordPress on your Ubuntu server. https://ubuntu.com/tutorials/install-and-configure-wordpress#2-install-dependencies https://ubuntu.com/tutorials/install-and-configure-wordpress... I want to focus on steps 2 through 6 They are all about configuring the system/envnironment. There are some tools that automate some of that. For example, you have to install about 10 packages. The installation of each package is mostly automated, except when it breaks for random reasons, but aside from that, even if it was perfect, you still have to know which packages to install and type out the commands to install them. Type 1 in the OP is the type that thinks this is very simple and is not a problem that needs solving. Step 4 in the guide has you edit config files in specific locations and execute some commands in a specific order. Again, each step, on its own, would sound "simple" to the type 1 programmer in the OP. Step 5 would have you configure a database. Again large parts of the process are automated .. but .. The whole process is complicated because at each step along the way someone thought the task is simple and their job is done and they just move ball down the field: it's not their responsibility anymore. A type 2 engineer in my book would try to design the system so that they _avoid_ the need for all this cruft.
  - bombolo 4y ago

LeonigMig 4y ago

more like two different ways of approaching a problem which crop up quite often designing socio-technical systems it does puzzle me how programmer culture is to over generalise as if its some epiphany or fundamental principle in fact this blog just diagnoses two common viewpoints or perspectives perhaps its just a style thing to get engagement with a blog

misternugget 4y ago
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.

jensneuse 4y ago

I'm type 3. When presented with a problem, I will not stop with W-questions until I think I found the root cause. I find it super interesting to understand the behavior of others. That's often a great way to find new business opportunities. Example: My company (https://WunderGraph.com https://WunderGraph.com) has a discord server with roughly 700 users. It's an absolute Goldmine to find new business. People being a problem, you ask for their use case and that way, you might learn where your company really creates value for someone else. I'd consider this "type 3" as the business engineer. Using software as a function to create business.

remram 4y ago
Seems completely orthogonal.
- jensneuse 4y ago
  I see it differently. It's most of the time wrong to jump from problem to possible solutions, tech or people solutions. Without finding the root cause, any solution will just fix symptoms.
  - remram 4y ago
    The article is about how you perceive the problem, it's not about solutions at all. And your "root cause" is still a problem which you have to fix, it's not like your way of doing things allow you to not have to solve problems ever.
IAmGraydon 4y ago
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.

tulio_ribeiro 4y ago

I wonder if there is a way to bridge the gap between them and find a balance between simplicity and robustness. I think type 1 and type 2 are not mutually exclusive, though. Maybe they are more like tendencies or preferences that can vary depending on the context and the problem. Sometimes, it might be more appropriate to focus on the technical aspects and sometimes on the human ones.

jt2190 4y ago

Both Type 1 and Type 2 describe engineers who acknowledge that their software is part of a larger system run by humans for some purpose. Type 1 and Type 2 make a different decision about where to draw the boundary between the software and the people. 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.

sdfghswe 4y ago
My experience agrees wholly. And I would add that the type 3 is the most arrogant.
lifeisstillgood 4y ago
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
- croo 4y ago
  From 20 years now on everyone will drive a car so everyone will be a car mechanic! -some guy who was wrong about cars in 1980 probably-
  - archgoon 4y ago
    [dead]
- htag 4y ago
  I think the software as language/literacy metaphor is taken too far. A lot of this is because Chomsky was such an influential thinker, and people take it too far. 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.

ravenstine 4y ago

I assume that every problem is hard. There's been enough times I've worked on codebases where even changing a string was a headache, thus it's difficult for me to give an estimate that think will represent reality.

photochemsyn 4y ago

How about three types? 1) Engineers who work on the external-facing side of the interface (possibly involving using many interfaces to build something with a user-facing interface, e.g. many app writers) 2) Engineers who work on the internal, engineer-only side of the interface (maximizing performance, optimizing at a low level, e.g. library writers) 3) Engineers who design systems by building interfaces at the correct points in the overall design that separate (1) from (2) (network engineering might fit here).

mkl95 4y ago

I see this all the time in distributed systems. More often than not some oh-so-simple guy will "lead", leading to a system full of potholes due to concurrency shortcomings etc.

phillipcarter 4y ago

> Here's the kicker though: it's the opposite! It's not cynicism, type 2 engineering is embracing the fact that we build with and for people and taking on an even bigger challenge of doing work despite the chaos this produces. YMMV, but I've run into plenty of Type 2 engineers who absolutely use it as an excuse to not do something or draw out what is often just a 15 minute conversation and a 15 minute coding session. It sucks to work with them.

lpapez 4y ago
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.
cratermoon 4y ago
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?
- phillipcarter 4y ago
  > Is it because they bring up things you hadn't considered Nope. Almost every time it's just a lack of drive to actually go and have that conversation. And almost every time, the conversation for a thing that's "complex" is short, there's no blockers, and the thing isn't actually that complex.
- Phelinofist 4y ago
  IMHO you don't have to consider everything. Not every potential case warrants additional complexity or maintenance effort. Not doing something and offloading it to the user is valid.
popularonion 4y ago
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".

CSMastermind 4y ago

Is there a "law" (razor in the philosophical sense) that states until proven otherwise you should assume all dichotomies are false? What the author gets at though I do think is important. 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. Even if the tradeoff is that overall, an organization is less productive but more consistent that's a very attractive proposition to these engineers. Anything that makes other people behave predictably is welcome. Of course humans are, at best, faulty in their rule adherence (there's a subreddit called "malicious compliance" for a reason). So engineers who assume that everyone will just follow the rules end up surprised when someone breaks them. Part of being a "hacker", at least in my definition, is being able to diagnose the actual dynamics of a system whether technical or social. That doesn't mean I submit to the view that you should go around paranoid forsaking the tool of bureaucracy entirely. Nor do I think there's any social status conferred by openly breaking rules (a mistake that I see a lot of young hackers make). As XKCD (https://xkcd.com/1494/ https://xkcd.com/1494/) might say, "That cool hack you just thought of is called fraud and we already know about it." Rather I'd suggest that if you feel inclined to write formal rules or policies for the behavior of humans you should instead write guidelines, define principals, and create incentives. Focus your time on aligning everyone on the goal not the process to achieve it. Accept the things you can't control.

misternugget 4y ago
> 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!
svilen_dobrev 4y ago
> and create incentives this... is 99% of times missing. Even the "We'll fire them" mentioned elsewhere in some comment, does not always work.
daniel_reetz 4y ago

fozzbezzem 4y ago

Funny, this is exactly how conversations go between me and my lead where my lead is the type 1.

deleted 4y ago

[deleted]

rgoulter 4y ago

If you come up with a way of describing two things, I'd encourage better names than "thing 1" and "thing 2". "false positive" and "false negative" are easier to understand than "type 1 error" and "type 2 error".

LastTrain 4y ago

Many or most of us are both types - because sometimes the first approach is warranted, and other times the second approach is. I would warn against pigeonholing people - for a time worn view on this google the “the bozo bit”.

crdrost 4y ago
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”.
rebeccaskinner 4y ago
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.
- SoftTalker 4y ago
  I think it's also a matter of experience. You learn the hard way that people don't follow instructions, don't read their email, and often try to use the software in ways you never imagined. I was much more of a type 1 engineer when I was young. I read my email, I read instructions... doesn't everyone?
adamors 4y ago
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

sublinear 4y ago

> type 2 knows that at the heart of all of their engineering work (and problems) are people This is only true for justifying the "work" and some of the high level definitions of the "problems". The same challenges exist on personal projects where the justification is arbitrary and can be nudged to get optimally simple problems (well made products) to fall out of it instead of ugly tangled knots (poorly made products).

andix 4y ago

I put developers in those two groups: A solves easy problems with complex solutions. B solves even complicated problems with simple solutions.

giantg2 4y ago

The hardest problem is non-technical - convincing people of something. Whether that's a design, technical strategy, sales, or budget.

throw310822 4y ago

Slight criticism: from the given examples, seems obvious that type 2 already knows the solution proposed by type 1 (apparently it was a very easy one), and also does one step further, asks how it impacts the users. So what this types theory really says is that there are devs who cannot think about their solutions in context, and devs who can. And then, in this case: it's really a continuum, and obviously it's not two types but just worse and better developers.

29athrowaway 4y ago

To me, the main difference are the ones that ask why, the ones that don't.

svat 4y ago

All disagreements are about "weights", and it's instructive to ponder what this one is about. IMO giving people a process/documentation does help to some extent, so the dichotomy the author presents here is between those who think doing so mostly solves the problem, and those who think most of the way is still left to go: so this one is I guess about the weight one attaches to the question of how much the non-technical solution solves the problem / how much you can rely on people to do what you'd like them to do, etc. And while experience may often involve lowering that weight over time, it's also important not to get too cynical (set weight to 0), and continue to attempt to estimate the parameter accurately: maybe the "ask people to do X" solution will give you a 30% probability they'll do X in any particular instance -- then ask how ok that is, etc.

great_psy 4y ago

I assume the further away your system is from non technical customers, the more type 1 you can be. I assume nvidia video card designers can be type 1, because other technical people will be interacting with their system. And if those people don’t do read the docs, and interact exactly how they should, it just won’t work. Now if you work at adobe and are designing the video editing software that deep down actually uses those video cards, well you need to be type 2. The success of your product is more dependent on how well “the software does what the user intended” where intended might be a very subjective thing, likely based on other features that other similar software has, not related to anything technical.

deleted 4y ago

[deleted]

tpoacher 4y ago

The problem isn't that the two types exist. The problem is that each type thinks they are the solution, and the other type is the problem.

cratermoon 4y ago

These categories are useful enough to apply not to just engineers, but also to engineering managers. You would perhaps think that part of going into management is being more understanding of people and the problems that occur when a "simple" engineering solutions meets human nature. And yet, I've worked with managers drawn from engineers who still operate as if the people working for them are simple machines. All they have to do is read the requirements, give accurate estimates, follow the process, use the tools, and TADA out comes working software that meets user needs.

deleted 4y ago

[deleted]

cj 4y ago

Type 1: people who live in code Type 2: people who live in code and understand the needs and dynamics of the larger business

sopooneo 4y ago

Early in my career I was working on a strictly internal business process tool. I'd cut my teeth playing with public, free web tools, so had my head around the idea that I would have to entice adoption. In a meeting with one of the executives, I was fretting over whether some feature was user friendly enough, and I asked, "but what if they don't use this part?". He looked at me baffled, then responded, "then we'll fire them." And as brutal as it sounds, he was right in that case, at that company. There were rigidly defined process rules for the front line workers, and as long as instructions were clear, people followed them. So I think there's a balance to be reached here, and I've had to come to peace with the idea that sometimes the answer is to hire an army of temps for a week to do some slogging task, rather than automate it. Sometimes.

that_guy_iain 4y ago
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.
alwaysbeconsing 4y ago
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.

issa 4y ago

I think most engineers need to be both. In most situations at least, you are deciding on engineering time vs non-engineering time. Meaning, if I can build something in a day that "gets the job done" with some usage constraints, or I can spend a week to build something that removes all constraints, then I need to calculate the trade-off. Could something more useful be built with that extra time? At least in start-up world, I find myself calculating that trade-off a lot.

phforms 4y ago

As much as I agree how important it is to design software with a type 2 mindset, I believe that there is also the trap of not taking any risks because you constantly fear it would not serve your users well enough, they would never use it, it would be too complicated for them, etc. We have to know our target audience well and always question our assumptions about them, because sometimes it may be surprising to see what users are willing to learn if they feel it is worth the effort. And sometimes it may be worth losing a part of that audience while the ones that stay will be much more convinced about what the product can give them back.

Nimitz14 4y ago

This website causes my mobile Firefox to hang and effectively crash.

kodah 4y ago

Not to undermine the post, but this to me seems like, "mature software engineer" versus "non-mature software engineer" with the caveat that not all engineers make it to maturity.

dep_b 4y ago

When building small scale one off applications for small businesses I’m type 1, building a mobile application for the masses turns me into type 2. Mobile users should be approached as retards.

smoyer 4y ago

I wish they'd had degrees (or even classes) in HCI when I was in school. HCI and UX in software have less to me rethinking a lot of my hardware engineering too.

neon_electro 4y ago
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)

ilumanty 4y ago

It feels like Type 1 is the “yes” type, and Type 2 is the “yes, but” or “no” type. Saying “yes” is easy, everything else not so much. Personally, Type 2 resonates with me, but I can see how this can be generally conflated with pessimism.

drewcoo 4y ago

There are two types of software engineers . . . those who wrestle the world into neat, tight dichotomies and those who realize that's not how things work.

liquidise 4y ago

I've written about a similar topic in the past, referring to the Types 1 and 2 as "brave" and "careful" developers. The titles are less important than the impact each brings. The "we'll just do X" developer tends to think about codebases as they do the customer. "We'll just refactor <huge system>" or "we can just include <major new subsystem>". Type 2 devs, in contrast, are far more careful in their approach to the codebase itself. The two balance each other out in the right ratios. Left to their own devices, Type 1 will bring innovative changes to a system while Type 2 naturally improve the stability of the system. I just think you want 3-4 Type 2's for each Type 1 you have on a team.

rawgabbit 4y ago

What the author is describing is known as "friction" or the "fog of war" has first expounded by Clausewitz. Everything is simple and straight-forward when you are dealing with your immediate team of a few people. The same task is extraordinarily difficult when you have to collaborate outside of your team, or have someone actively opposing you or trying to deceive you. You are also assuming the "people" will behave in a certain way. Your company can treat front line workers like robots and must follow a certain script. Or you company can treat front line workers like independent thinkers and empower them to make limited decisions. IMO. None of this really matters. What matters is correctly diagnosing the problem in the first place. And correctly diagnosing the capabilities of your tools and your employees. Once you have an accurate picture of the problem, the solution will come readily. The problem is no one wants to admit their short comings or limitations. They will always say they can do everything you ask of them. Then you tell them about the budget and limited time frame. And they still say they can do everything. What we need is productive candor.

the_cat_kittles 4y ago

type 1 thinking is just outsourcing the actual problem to other people

yafbum 4y ago

Both types are engaging in product definition work without a second thought to how to do it. Even the second type does it without asking themselves what users would actually enjoy or prefer (depending on what the product goals are), and sounds just being afraid of asking people anything. And many times, going on an actual fact finding mission can bring some light that pure engineer to engineer conversations will never uncover.

smsm42 4y ago

I'd call them "naive" and "experienced".

dgunay 4y ago

Type 1 is the right move in certain situations, but I've been forced to just let many preventable problems happen because a Type 1 person in power cannot be convinced to see the Type 2 take on something. It's pretty demoralizing.

ozim 4y ago

I say there are problems that cost more to fix in code and there are problems that are cheap to fix in code. There are problems not worth fixing with telling people - if they fall in such ways we get support ticket and someone will explain to the user what just happens. If this happens too often only then we know it is becoming worth fixing. So for me article is wrong because author assumes there should be answer or solution for each and every problem. So 1st type of dev might be right a lot of times because how often does it happen that people deploy at the specific time? If it never happens in reality you just waste time solving it. On the other hand if it happens you will have to solve it then you might need action plan for it but … most likely you can just let people make mistakes and fix them on the spot.

palata 4y ago

IMHO, the whole art of software engineering is to get it right on a case by case basis. There is no one rule for that. Sometimes it is fine to assume that the user will "do it right" (it is fine to assume that a military pilot learns how to fly the plane before taking off), sometimes it is not (it is not fine to assume that a customer using an ATM knows how to build a Linux kernel). The whole point of software engineering is to build an abstraction that makes sense for the targeted user. This requires experience (which is tricky considering that most developers have less than 5 years experience :-) ).

rkargon 4y ago

And Type 2 have GOT to GO! "Grand sprint opening, grand sprint closing!"

mock-possum 4y ago

type 1 brings customers in, type 2 ensures they stay with you.