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.
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.
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.
This is literally any worker? If you don't have a stake in the company, your bosses profit more from your work than they pay you for it, almost by definition.
Even if you do have a stake in the company, often the company controls the contract governing that stake, especially if you don't really own the stake you are promised (options).
Oh, then I guess you better vote in a government that doesn't maximize gains for the wealthy. But taxation doesn't go well with the libertarian types here on HN. A few of us are millionaires in the capital class, and the rest are 'temporarily depressed millionaires' thinking we're moments away from enacting our own get rich scheme.
The function that employment plays in society is that you can recruit people to work on your project without needing to fully convince them of its utility, by completely derisking their time investment. Metaverse? Solar-powered toothpaste dispenser? Broccoli and cheddar flavored ice cream? Rockets that fly to Mars? "Sure. Whatever you want, boss."
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.
> As an engineering manager, I cannot imagine assuming that people would read something.
Engineers read code when they have to work on it. If naming and structure are good, it will be self evident what that code does and why.
Unfortunately it takes a lot of time to learn how to code in such a way that the author and coworkers can come to that piece of code six months from now and understand what it does.
A corollary is that everything should be automated or made impossible to do, because even looking at the company's wiki is something that most people prefer not to do.
Unfortunately it's difficult to know which automatic process is doing something, given that that something is a known unknown.
I think that 999 of the thousand can be brought into the virtual realm - and that companies that do so will find their ability to measure and chnage the important non functional requirements will be an advantage.
Just some ideas:
- speed (obvious)
- capacity (that's fairly obvious too)
- reliability (MTBF, incident count)
- The Google Speed vs stability metric
- usability (starts out as a toughie but if you record users mouse / UI activity then it becomes measureable - and this is kind of the point - the more HCI is captured and available to the "virtual world" the more these problems are within reach. the more software eats, the more it can eat.
- scalability : scaling up or down? Measureable
> Engineers read code when they have to work on it. If naming and structure are good, it will be self evident what that code does and why.
In early greenfield software, sure, but given the test of time this assumption will always fail. The reason is that each team that works on a given software has an operating context that's often undocumented. They use lingo and rhetoric that likely aligns to that and is illuminating now but when that lingo isn't as common it'll likely die off. The very idea that words of a contextual language will be exactly relevant in the future is a short-sight in its own.
Writing a lot of docs has its own tradeoffs, but I do think it's worth pursuing principles of writing good notes. I'm oft fascinated by reading the comments on old code that remain durable.
And documenting the lingo, the concepts with which the software was designed is more important than some system diagram or call sequence charts or API stuff. (For the maintainers; API consumers obvi need something).
I think we are in agreement. As for the five or more hops issue, I think software is giving a generational opportunity to rework our organisations. I think every company has two organisations - the first is the one that does the real work (think the bit that records how much money each account has in a bank). That first part is becoming / has become totally automated - it is a "programmable company". The second part (tries) to chnage the first org. Direct it control it alter it whatever. That's the part that has project plans and managers.
The two organisations are merged and confused in most places - even the hierarchies probably should be seperate.
The point being that four of the hops you had weee probably not in the first org. The alignment was perfect for what stripe actually is / does. The politics lies in what it wants to become - and that is a function of whether te people in the second orgabisation will keep power in the new place.
Software means we can I think seperate the two orgs.
> The politics lies in what it wants to become - and that is a function of whether the people in the second organisation will keep power in the new place.
Yes, this feels partly correct. There is a meaningful part of all layers that skew towards self-interest. Every hop amplifies the skew and has fewer checks because it is less visible/accountable to the top level.
The local maximum for someone reporting to the CEO is much more closely aligned with the long-term best interest of the company than someone 3 or 4 hops away.
Something I learned was just how much success is dependent on one's manager. In early startups, executing on what's best for the long-term success of the company (including when that is short-term optimization) is a good career strategy. Maybe the best. In larger companies—or at least in this single anecdata point, though others have said similar things about other bigger companies—that's not so true.
> 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.
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.
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.
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.
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 :).
We're acting like the programmers want to create the complicated software, but really its the sales team showing up to project management saying "We signed a million dollar deal because our product does X"... then the PM panicking telling the programers that the application needs to do X by next week.
I’ve seen a lot of programmers/architects who created way to complicated solutions. Distributed microservice applications, nosql, and so on. New technologies that seem cool and useful, but make stuff much more complicated then it needs to be. Without real benefits.
„But we can scale from 500k to 50 million users now“, which usually doesn’t happen. But what does happen is, that the system gets too complicated and too hard to extend or fix bugs.
I struggle mightily with this in managing projects. My instinct is to use solid boring tech, and maximize chance of delivering on time. But I've found that:
1.) No one writes blog posts about using old boring stuff and meeting expectations. And such blog posts can contribute to recruiting and even, indirectly, sales, by helping your company get general press for being "on the cutting edge."
2.) You can potentially get better overall results even if the new tech has more gotchas and unknowns, because certain developers will knock themselves out to deliver on time and prove you were right in trusting them with the platform/language decisions. But you have to pick very wisely on this and keep in mind such devs may immediately lever their experience on the new tech to get a new job and leave you with a team of juniors that wander lost without their guru.
I think it’s still possible to use some modern aspects in combination with boring old tech.
One thing I found useful is: try to build something that is boring old tech, but the boring tech can be switched out easily. Like a monolith that can be also split up into micro services (via a build flag).
I don't think "solid boring", or even old, is necessarily bad for recruiting.
Typescript and Golang for example, are relatively new-ish but still solid and boring, and have significantly much less gotchas than older established tech like, say, Rails.
I don't do Java, but I see it getting a bit of a renaissance. Either because of new features or because people are moving to Kotlin (yep for backends), which is a different language but still has the "solid boring" feel to it.
It is tough to hire for devops, though. The currently experienced people want to work with more complex infrastructure. Maybe we need a few more years to see those people getting burned and deciding they don't want to life an exciting work-life anymore.
And there's a vast difference between building a system wuth allegedly scalable components, and actually scaling the system to run. It's way more than just using nosql.
I'm also one who uses boring old technology. Mostly relational databases and LTS operating systems. May not make for interesting blog posts but I'll take that over being called at 3:00AM because some microservice isn't working.
As much as I can sympathize with the fact that sales and PMs tend to invent weird stuff and have weird (and often impossible) deadlines, most of the time it is developers that overcomplicate software.
Also, unlike sales/PMs ideas (well, at least a few of them), those complications created by developers aren't really helping sell the software. Nobody is buying software simply because it has 50 microservices, all the design patterns and needs Kubernetes plus a few thousand-bucks per month of cloud to run.
I do disagree with this. It is ok I guess to make these convoluted, half-assed products if the cash flow is fine, but remember you will forever future pay a cost here for increased maintenance and for complicating the next feature.
The bigger issue in the sales/developers divide is that neither of them is tasked (assessed, paid for, whatever you want to call it) to 1) understand the actual problem/feature request (before even thinking about solutions), and 2) write end user documenration and/or try to explain to explain the solution to the end user.
If only sales and dev drive product direction, with neither of them having explicit focus on what the end user needs, you end up with overly complicated, half-assed products, that kind of work, but not really, and nobody wants to touch.
On the other hand, what matters is money in the bank, so doing stupid shit like this is fine if the cash flow looks good.
I've never seen a PM come to a dev meeting saying "Hey guys, our sales team decided to use the Kubernetes and an elastic search cluster because our clients told us unanimously that the thought of our product running on an advanced container orchestration monstrosity makes them feel really warm and fuzzy."
It's usually the developers telling the sales guy "Sorry man we can't deliver this feature on time because our Elastic Search cluster is on Fire All The Time and we need to fix it before we can start adding new features".
Love this, and agree 100%. The crazy thing is that I've seen such a situation of the video happen, but it was with a monolith.
"No, a junior can't add a filter to this column because the current system doesn't support filtering aggregates, so we have to partially rewrite it. No, we can't add this directly to the controller or model because there's no controllers or models anymore! Or more like: there's just one! Why? Because we wanted a future-proof system and decided to make a GraphQL simulacrum that allows adding new features without almost no cost! Sure, almost nobody understood it and sometimes it requires rewriting, but who wants to working on a fucking CRUD system?"
I’ve once worked on a system where everything was abstracted. Literally everything. You were basically not allowed to use any libraries. They had an ORM, but you could only use it via their wrapper („so it can be switched at a later point“). A lot of things were impossible with this wrapper, or just broken. You could file a ticket, but the library was just updated twice a year.
You could not make sophisticated HTTP-requests, because you had to use the in-house library. And off course it had much less functionality than some commonly used libraries.
So what I learned from that: abstractions can be nice, but they are useless if you can’t escape them. They must have „escape routes“ everywhere, to do things that are not covered by the abstractions.
I feel your pain, but the problem is that these "escape routes" are leaky abstractions. They're the worst of both worlds. You still have the bad architecture surrounding the whole thing, but also a lot of parallel stuff going around. Sure, they're great for getting things done in the short term, but after one year of everybody cutting corners, you have a big ball of mud.
There's unfortunately no known way to make good software other than keeping it simple, concise and without too many components.
A big working ball of mud is still better than a big ball of gold, that doesn’t do what it is supposed to do.
The thing you can do to prevent it: continuous refactoring. It’s better to ship features on time and clean up afterwards, than cleaning up a lot before and never ship things.
If you start with a simple ball of mud, sure. But a rigid architecture that's also a ball of mud is harder to refactor, and things also don't get done.
As I said, using escape routes for some time, for speed, is acceptable. The problem is making this into a rule.
Refactoring a bad abstraction is easier than refactoring an abstraction that is messy and bad. So either refactor sooner (and create proper abstractions) or skip the “ball of gold” altogether (eg: use the original framework directly).
As much as I appreciate the value of good documentation, forcing most developers to write documentation would be less than worthless. In part because most people are no good at writing to communicate complex ideas to others. Developers are no better, and may in fact be worse. While they might understand the complex ideas, in trying to explain them to others they run into the Curse of Knowledge. With no skill in turning ideas into communication, the output is at best a first draft of something that might be input into useful documentation.
Im not talking about end user documentation. More about how to configure and operate the software. How to add features, how to debug issues. How to deploy updates and so on. This is really often missing, I’ve seen it often that a developer quits, and then it takes weeks or months until the next bugfix can be deployed into production.
> More about how to configure and operate the software. How to add features, how to debug issues. How to deploy updates and so on.
That still implies writing to an audience other than yourself, and the Curse of Knowledge still applies.
In many ways, it's much worse, because it's easy to assume that because the document is for a technical audience that the reader will know as much and have the same context as the author, and easy to include less supporting material. I look at StackOverflow and see how many questions are technically answered in the documentation, but in fact do not prevent the question from coming up. It's not the the questioner can't understand or the question is stupid, it's that the mental model of the reader and writer don't match up.
Of course it's much worse if, as in your example, the knowledge is in one person's head. That's a related problem, and having something is better than nothing. Even with some documents, cases still arise where there's a missing piece of information that the document author didn't record. The author understood what the document meant, not realizing it is only understandable given some knowledge the author did not provide.
I'd say the proportion of developers that are able to write good, readable, documentation is about the same proportion as those who can write good, readable code.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." – Martin Fowler.
Most programers are no good at writing code the communicates to other humans. They write code that computers can understand, which is a completely different skill.
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.
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.
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) 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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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).
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.
> 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.
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.
> 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.
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.
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
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/) 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.
> 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!
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.
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”.
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 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?
> 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).
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.
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.
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.
153 comments
[ 3.2 ms ] story [ 239 ms ] threadThe 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.
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.
"Equity" feels like a mirage, often.
I mean yeah. That's everyone.
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.
Engineers read code when they have to work on it. If naming and structure are good, it will be self evident what that code does and why.
Unfortunately it takes a lot of time to learn how to code in such a way that the author and coworkers can come to that piece of code six months from now and understand what it does.
A corollary is that everything should be automated or made impossible to do, because even looking at the company's wiki is something that most people prefer not to do.
Unfortunately it's difficult to know which automatic process is doing something, given that that something is a known unknown.
Further investigation certainly makes sense
Just some ideas:
- speed (obvious) - capacity (that's fairly obvious too) - reliability (MTBF, incident count) - The Google Speed vs stability metric - usability (starts out as a toughie but if you record users mouse / UI activity then it becomes measureable - and this is kind of the point - the more HCI is captured and available to the "virtual world" the more these problems are within reach. the more software eats, the more it can eat. - scalability : scaling up or down? Measureable
In early greenfield software, sure, but given the test of time this assumption will always fail. The reason is that each team that works on a given software has an operating context that's often undocumented. They use lingo and rhetoric that likely aligns to that and is illuminating now but when that lingo isn't as common it'll likely die off. The very idea that words of a contextual language will be exactly relevant in the future is a short-sight in its own.
Writing a lot of docs has its own tradeoffs, but I do think it's worth pursuing principles of writing good notes. I'm oft fascinated by reading the comments on old code that remain durable.
The two organisations are merged and confused in most places - even the hierarchies probably should be seperate.
The point being that four of the hops you had weee probably not in the first org. The alignment was perfect for what stripe actually is / does. The politics lies in what it wants to become - and that is a function of whether te people in the second orgabisation will keep power in the new place.
Software means we can I think seperate the two orgs.
Yes, this feels partly correct. There is a meaningful part of all layers that skew towards self-interest. Every hop amplifies the skew and has fewer checks because it is less visible/accountable to the top level.
The local maximum for someone reporting to the CEO is much more closely aligned with the long-term best interest of the company than someone 3 or 4 hops away.
Something I learned was just how much success is dependent on one's manager. In early startups, executing on what's best for the long-term success of the company (including when that is short-term optimization) is a good career strategy. Maybe the best. In larger companies—or at least in this single anecdata point, though others have said similar things about other bigger companies—that's not so true.
I found that sad.
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.
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.
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.
Here's the official Ubuntu documentation about how to install WordPress on your Ubuntu server.
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.
So a go developer that reimplements all of that in go, using rewritten buggy libraries?
If you create difficult solutions, you need to create a lot of documentation. And there is nothing that people hate more, than writing documentation :).
„But we can scale from 500k to 50 million users now“, which usually doesn’t happen. But what does happen is, that the system gets too complicated and too hard to extend or fix bugs.
1.) No one writes blog posts about using old boring stuff and meeting expectations. And such blog posts can contribute to recruiting and even, indirectly, sales, by helping your company get general press for being "on the cutting edge."
2.) You can potentially get better overall results even if the new tech has more gotchas and unknowns, because certain developers will knock themselves out to deliver on time and prove you were right in trusting them with the platform/language decisions. But you have to pick very wisely on this and keep in mind such devs may immediately lever their experience on the new tech to get a new job and leave you with a team of juniors that wander lost without their guru.
One thing I found useful is: try to build something that is boring old tech, but the boring tech can be switched out easily. Like a monolith that can be also split up into micro services (via a build flag).
Typescript and Golang for example, are relatively new-ish but still solid and boring, and have significantly much less gotchas than older established tech like, say, Rails.
I don't do Java, but I see it getting a bit of a renaissance. Either because of new features or because people are moving to Kotlin (yep for backends), which is a different language but still has the "solid boring" feel to it.
It is tough to hire for devops, though. The currently experienced people want to work with more complex infrastructure. Maybe we need a few more years to see those people getting burned and deciding they don't want to life an exciting work-life anymore.
I'm also one who uses boring old technology. Mostly relational databases and LTS operating systems. May not make for interesting blog posts but I'll take that over being called at 3:00AM because some microservice isn't working.
So I tend to build a system that can handle the load that is expected, and some reasonable scaling (maybe 5x to 50x more load).
If your product grows way faster then expected (1000x), you will probably have way more budget, and be able to do it even better.
Also, unlike sales/PMs ideas (well, at least a few of them), those complications created by developers aren't really helping sell the software. Nobody is buying software simply because it has 50 microservices, all the design patterns and needs Kubernetes plus a few thousand-bucks per month of cloud to run.
If only sales and dev drive product direction, with neither of them having explicit focus on what the end user needs, you end up with overly complicated, half-assed products, that kind of work, but not really, and nobody wants to touch.
On the other hand, what matters is money in the bank, so doing stupid shit like this is fine if the cash flow looks good.
It's usually the developers telling the sales guy "Sorry man we can't deliver this feature on time because our Elastic Search cluster is on Fire All The Time and we need to fix it before we can start adding new features".
https://www.youtube.com/watch?v=y8OnoxKotPQ
"No, a junior can't add a filter to this column because the current system doesn't support filtering aggregates, so we have to partially rewrite it. No, we can't add this directly to the controller or model because there's no controllers or models anymore! Or more like: there's just one! Why? Because we wanted a future-proof system and decided to make a GraphQL simulacrum that allows adding new features without almost no cost! Sure, almost nobody understood it and sometimes it requires rewriting, but who wants to working on a fucking CRUD system?"
You could not make sophisticated HTTP-requests, because you had to use the in-house library. And off course it had much less functionality than some commonly used libraries.
So what I learned from that: abstractions can be nice, but they are useless if you can’t escape them. They must have „escape routes“ everywhere, to do things that are not covered by the abstractions.
There's unfortunately no known way to make good software other than keeping it simple, concise and without too many components.
The thing you can do to prevent it: continuous refactoring. It’s better to ship features on time and clean up afterwards, than cleaning up a lot before and never ship things.
As I said, using escape routes for some time, for speed, is acceptable. The problem is making this into a rule.
Refactoring a bad abstraction is easier than refactoring an abstraction that is messy and bad. So either refactor sooner (and create proper abstractions) or skip the “ball of gold” altogether (eg: use the original framework directly).
That still implies writing to an audience other than yourself, and the Curse of Knowledge still applies.
In many ways, it's much worse, because it's easy to assume that because the document is for a technical audience that the reader will know as much and have the same context as the author, and easy to include less supporting material. I look at StackOverflow and see how many questions are technically answered in the documentation, but in fact do not prevent the question from coming up. It's not the the questioner can't understand or the question is stupid, it's that the mental model of the reader and writer don't match up.
Of course it's much worse if, as in your example, the knowledge is in one person's head. That's a related problem, and having something is better than nothing. Even with some documents, cases still arise where there's a missing piece of information that the document author didn't record. The author understood what the document meant, not realizing it is only understandable given some knowledge the author did not provide.
The entire point of writing software is to communicate complex ideas to others.
Most programers are no good at writing code the communicates to other humans. They write code that computers can understand, which is a completely different skill.
Yes, there is - keeping huge documentation up-to-date.
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.
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
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.
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.
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.
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
-some guy who was wrong about cars in 1980 probably-
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.
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.
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-...
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).
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.
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.
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".
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/) 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.
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!
this... is 99% of times missing. Even the "We'll fire them" mentioned elsewhere in some comment, does not always work.
"false positive" and "false negative" are easier to understand than "type 1 error" and "type 2 error".
I was much more of a type 1 engineer when I was young. I read my email, I read instructions... doesn't everyone?
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).
A solves easy problems with complex solutions.
B solves even complicated problems with simple solutions.
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.
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.