6 ms·

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

• 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.
• Nextgrid 4y ago
  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.
  • cudgy 4y ago
    Bravo. You are a type 2 engineer and have obviously been paying attention.
  • 8uhaal 4y ago
    > I find that our entire industry is encouraging and rewarding type-3 behavior Latest instance: ChatGPT and the hype around it.
• Herval_freire 4y ago
  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.
  • lucasyvas 4y ago
    This one is tough because it means software people (that includes me) are arrogant enough that they think they can make a machine that can solve any human problem, when they often hate interacting with people. Giving us the keys to the future is a mistake and I don't think we are headed anywhere good for the human race. 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.
    • Herval_freire 4y ago
      >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.
• lucasyvas 4y ago
  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.
  • dasil003 4y ago
    I agree that software engineers need to understand the product and take more responsibility in its definition. I believe this has regressed compared to early professional programming norms as computers and especially smart phones have become staples in everyday life. I also think current ways of working have enabled bad product management. 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.
  • gregmac 4y ago
    > if you aren't coding the solution to the problem, you shouldn't be allowed to define the solution 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.
• coderjames 4y ago
  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.
  • hanhphuc 4y ago
    My experience suggests that building a software business often involves re-producing time-consuming things that others have built in a simpler way. Oftentimes, you do less thinking about the problem/solution than writing the code. 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.
• m463 4y ago
  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-8-chapter-2-the-tyranny-of-the-normal-distribution/ https://www.cringely.com/2013/02/10/accidental-empires-part-...