IF your software product's job was to literally squeeze people into dollar bills and you had the world's greatest engineering team on it (because face it, y you'd have to, unlike lots of other ways of extracting revenue), that doesn't mean you are better people, it means you've gotten used to working with sociopaths. You might not even be very good at what you do, you have just gotten very good at doing a very niche thing.
It's just a tool. Tools don't make people good or evil. We've all wtched this industry say all the right things for the last two decades, why is so much of what we produce shit and we know it?
I do believe what can limit you from being a better person is to try to find ways to pat yourselves on the back instead of realizing we have a long way to go.
While I generally you are 100% on point, this posts both refer to the original articles, and makes a interesting point: there are a many companies whose goals are at least questionable.
I don't know how I could sleep at night if I was working for say google or facebook.
I don't think these skills scale up to larger levels of human organization. Heck, the Agile folks often make that point specifically with regards to team and corporate structure.
We cannot be equally understanding and empathetic with everyone.
It might be the other way around. I think you need to be right type of person to be a (good) software developer.
To be a (good) software developer you need to be at least a little bit honest with yourself (can't learn from mistakes if you can't acknowledge you made a mistake, etc.), you need to be curious, you need to be willing to observe and learn and you need to be able to put effort including in things that may not necessarily have immediate payoff.
All of which, I think, correlate with being a good person. Does not mean you will be a good person, it just means there is higher chance.
And, in retrospective, all good developers I have ever got chance to know a little better were nice, good people (at least to me). Which is not true for general developer population (which is to say I also got to know a lot of shitty people which were never good developers).
>To be a (good) software developer you need to be at least a little bit honest with yourself (can't learn from mistakes if you can't acknowledge you made a mistake, etc.), you need to be curious, you need to be willing to observe and learn and you need to be able to put effort including in things that may not necessarily have immediate payoff.
>All of which, I think, correlate with being a good person. Does not mean you will be a good person, it just means there is higher chance.
None of this correlates with being a good person at all! Let's imagine that I am pure evil and want to maximize harm. Being honest with myself, learning from my mistakes, being curious, being willing to learn and observe, and putting effort into things that may not have immediate payoff are all going to make me better at poisoning the water supply or what have you.
These traits correlate with being effective, not good.
A trait can lead to a lot of different outcomes being more likely. Including outcomes that directly conflict with each other.
Saying "having these traits makes you more likely to be a good person" does not contradict saying "having these traits makes you more likely to be effective evil dictator".
You assume that if having certain traits makes you more likely to be effective evil mastermind it also means it must make it less likely that you are good person. Which is not true.
Imagine following situation: you want to measure how a trait makes it more likely that any random person out of entire population is a surgeon. And then you want to measure if a trait makes it more likely that any random person out of entire population is a lawyer.
We know that being lawyer conflicts with being surgeon -- both require significant investment of time and effort and you have to choose being one or the other.
But, we can find that having wealthy parents makes it more likely that you are both surgeon and lawyer. And that is because being surgeon and being lawyer both requires a heavy investment of time or money or both -- which is more likely to be possible if you have wealthy parents that can support you.
Which of course does not prove my point, but it does invalidate your argument.
No, I am not making a logical mistake, and your 'invalidation' of my argument is actually just restating it.
> You assume that if having certain traits makes you more likely to be effective evil mastermind it also means it must make it less likely that you are good person.
I do not, and I don't assume that the traits listed make you more likely to be an evil mastermind or a good person, I think they are completely unrelated to morality, and only related to effectiveness (this is what I mean when I say the traits don't correlate with being a good person at all). If you wanted to find the most effective neutral people, you would look for the same traits, because that's what they measure: effectiveness.
Another way of putting your claim: effective people are more likely to be good people. I think that is a very bold claim and have seen no evidence of it in my life, competence and goodness are orthogonal.
I think it is more of the opposite -- having those traits on its own doesn't make you a good person, but lacking those definitely makes you a bad person. :)
Don't know it there's a relationship to being a good person, for whatever moral interpretation of good.
But I do agree that it helps to be a good developer that you have good introspection skills, honesty, curiosity, and confidence to make mistakes and learn from them.
But I think GP has a point, he just picked wrong qualities... I believe in software engineering especially it is important to have empathy (to code in a way that others understand) and humbleness (to accept your limitations in a team setting).
Maybe those correlate with being a good person? I don't know.
I know I shouldn't say this, but can't help to point out that this is some major HN circlejerk material. The type of post through which ppl form stereotypes about this board. The whole article is pretty bizarre.
> Have you ever been on a really good software team? There’s this feeling of connectedness, of shared purpose. We know what we’re building, and we are skilled at building it together. This kind of team can grow some amazing software.
> When we work at making our team great like this, we look for new ways of working together. The original agile movement scratched out imposed structure and asked the team to make their own. At our conferences, we talk about inclusion, empathy, emphasis on relationships. We talk about endless learning, freedom to fail, curiosity and compassion.
> In software, participatory sense-making means developing a shared mental model of what the software is, what it’s going to be, and how it works. We need to understand what we’re building deeply, with a clear language to talk about it. It needs to make sense to each of us, and to all of us. We construct this model together: that means there’s more of us to work at making it real in the world. It also means the model is richer, fits with more of the real world, and more rigorous. This comes from our many perspectives participating.
> In humanity, participatory sense-making is how we find shared reality in the different pieces of the world that each of us see. We build new concepts that exist only among our minds: money, economy, justice, law, music, conservation, fashion. These are real things that have causal effects on the physical world because we collectively create them.
It seems to me that even software people/communities, who have extensive experience working with complex models, very often fall victim to the same sort of counter-productive bickering when the topic of conversation changes to standard culture war topics. My theory (in part) is that when people are talking about such things, they tend to forget that they are talking about custom models of reality (we each have one within our mind) rather than reality itself....and as one should expect, chaos and strong emotions ensue.
Any job that requires problem analysis and coordination skills has the same effect. As a software developer (well they call me architect these days), I'm more or less sure there's nothing special about our profession.
The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't. If your airplane design doesn't fly, pretending it did doesn't work.
But in the soft sciences, like economics, politics, social topics, history, etc., deluded thinking is commonplace even among those highly educated in the field.
What I find curious, though, is STEM PhD's apply rigorous logic to determine if something is true or false. But the same people, when thinking about non-STEM topics, throw logic, reason, and analysis out the window and just go with their gut feel.
A commonplace example is STEM people know very well that (A implies B) is not the same thing as (not A implies not B). They don't make that mistake in their field. But they apply that logical fallacy everywhere else.
You certainly can pretend your car has 10 gallons of gas in it when it has only 1, but you're still going to run out of gas after that gallon is burned. I suppose one could conclude that pretending can work if the consequences are borne by others.
I wonder why the need for this validation. I see deluded thinking all the time in this field, in fact, I see it more in this field than any other because it is so easy to be self made here.
You can fake "working" software, that's why so much of it is low quality because to outsiders it is magic and to us insiders...apparently it is magic that only we can perform and those other people can't. We still get paid.
The weird thing is working across multiple fields, the social scientists were the most honest with what they didn't know and made no pretensions about it. But they won't write an essay bout it and post it to HN. The pretensions in this essay would have shot it down in their heads.
I got another comment flagged for "snarky", but I know you are smart enough to see the inherent disrespect to other fields (and perhaps ignorance of them), in your post.
> I know you are smart enough to see the inherent disrespect to other fields (and perhaps ignorance of them), in your post
There are undoubtedly good people in those fields. But when a distinguished professor of economics tells me personally that he believes in communism (yes that happened), I lose respect for him, not necessarily the field.
> you cannot pretend something is working when it isn't
You absolutely can. The problem is in the ambiguity around the work "working". Take for example the case of a person/team shipping a poor quality implementation which is initially celebrated and rewarded (because no one realizes it's a poor quality implementation) only to fall over in production and cause large problems/disruption for the team/product/business.
This is not an uncommon scenario in software development and I would argue is a case of people pretending (or thinking) something is working when it isn't.
Sure, but even in your example the it doesn't take long before something hits the fan. On the other hand the trickle down theory of economics (for example) is still going.
> The problem is in the ambiguity around the work "working".
We (engineers, scientists, whatever) exploit ambiguity as a work avoidance strategy all the time, but for many fields exploiting ambiguity is the work. IMO it's like the difference between a think tank abusing statistical bias versus using a firehose of falsehood to push their agenda. Ambiguity is just a tool in the former case that occasionally causes problems, but it is the life blood of the latter tactic and creates a much more destructive atmosphere for critical thinking and societal trust in general.
Law maybe? Economics? Journalism. Definitely all of wall street and the entire crypto industry. Every single sales person since the dawn of time... Real Estate agents (I guess those are sales people).
I agree with everything you have said and I have a mental game I play to quantify it.
It's the "how many people could leave this company before anyone noticed?" game.
Software organizations have such good margins on capital they can afford to hire extraordinary quantities of dead weight before they become unsustainable. I've been at organizations where probably 75% of the software engineering org could be fired with no impact on creativity, growth, or maintenance efficacy.
It's actually the efficiency of software that allows ineffective people to stick around without being noticed. Contra this article, I've noticed whole sections of the software industry deliberately float around organizations at scale. They're typically the people with a boatload of "ex-Cool Company" in their LinkedIn handles.
> I've been at organizations where probably 75% of the software engineering org could be fired with no impact on creativity, growth, or maintenance efficacy.
That's likely what the other employees were saying, too.
It's not exclusive to software orgs, either. Everyone at every company is a special rockstar without whom the company could not survive, and everyone around them is a disposable dumb asshole.
>STEM PhD's apply rigorous logic to determine if something is true or false. But the same people, when thinking about non-STEM topics, throw logic, reason, and analysis out the window and just go with their gut feel.
How much is it the other way round?
>you cannot pretend something is working when it isn't.
If you can verify any hypothesis with an experiment, you don't need logic. You can go with your gut feeling, and iterate until it works. Because the compiler and the program itself are bound by logic, software developers don't need to cultivate the same strict logical thinking that other disciplines need.
> The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't.
This is actually less true of software than of other engineering fields. An airplane can only weigh so much, and it needs an engine that's at least so powerful, else it will never leave the ground. With computing, the constraint ceiling is much higher, and it's still getting higher year over year albeit more slowly than it used to. Consequently, you can brute-force a terrible abstraction into kind of, sort of working and it will be acceptable for most use cases, only to break spectacularly when subjected to loads beyond a particular scale.
> The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't. If your airplane design doesn't fly, pretending it did doesn't work.
And yet engineers are doing it all the time. Think of Dieselgate or the Boeing 737 MAX.
One might object that the discovery of Dieselgate or the flaws of the Boeing 737 MAX is prove that the engineers responsible for it were not able to pretend. But then the sentence is analytically true for every other profession too: the discovery of a flaw falsifies claims of flawlessness.
I think that some types of flaws make themselves apparent comparatively easy in (software) engineering. But this might even fire back if it makes an engineer too uncritical so that she put too much trust into the result of her work.
Besides, I do not think that we have good metrics to compare distant professions in terms of their ability to deliver high-quality results. It is perhaps somewhat justified to compare neigboring professions, such as a biologist arguing with a physician or a historian with a political scientist in specific cases. But beyond that, I can really only imagine an exchange of prejudices.
> And yet engineers are doing it all the time. Think of Dieselgate or the Boeing 737 MAX. One might object that the discovery of Dieselgate or the flaws of the Boeing 737 MAX is prove that the engineers responsible for it were not able to pretend
These two are closer to fraud than engineering mishaps.
The big issue with the 737 MAX wasn't the MCAS, it was that management and marketing hid its existence from buyers and regulators. So when it started misbehaving the pilots were not aware this thing was turned on and was steering the plane.
The MCAS did what it was built to do (make the plane behave like a traditional 737).
Why did management hide this crucial information to buyers and government regulators? Because had they not, it's unclear regulators would have certified the plane to begin with since nobody could, in good faith, claim it was eligible to the same type certificate as its predecessors.
> the pilots were not aware this thing was turned on and was steering the plane.
But they were aware of how to deal with runaway stabilizer trim, which is supposed to be a memory item (i.e. don't need to consult the checklist). After the first crash, Boeing sent an Emergency Airworthiness Directive to all MAX pilots with instructions on how to regain control. The EA crew did not follow those directions.
In the case of Dieselgate, the engineers who programmed the emission control system built something that let other engineers believe that the system is working alright when it didn't. Of course, for the engineers who commited the fraud, everything worked as expected by hiding from the other engineers that the system was only in the test setup reaching the emission goals.
In the case of the 737 MAX, I doubt that only the manangement is to be blamed. This sounds like the adage that success has many fathers, but failure none. The practicality of certain design for its intented purposes in its actual use cases is at the heart of engineering. I don't think that a top-down view is sufficient where it is "manangement" that is setting specific goals and "engineering" is only obligated to observe these specific goals instead of also considering the broader context.
Back to the original debate: Even if "the MACS did what it was built to do (make the plane behave like a traditional 737)" the whole design did not what it was supposed to do. Admittedly it did fly, but not safely. And the whole process of quality control, which should ensure that it was safe, did fail as well.
This is why I think a claim like "engineering ... cannot pretend something is working when it isn't" is quite naïve. Why do we need all those complex regulations about quality control, when it is so obvious that something is working or not?
> you cannot pretend something is working when it isn't
Hm, not sure about that. People talk about making MVPs by letting the user think there's a product there when in reality the solution is done manually, or there to just collect email addresses. See Wizard of Oz, concierge, etc MVPs as examples [0]. There are also no-code tools one can employ to make things seem like they work, again at least to the end user.
> The only thing really "special" about software, and it applies to all engineering, is you cannot pretend something is working when it isn't. If your airplane design doesn't fly, pretending it did doesn't work.
The prevalence of Agile and Scrum in our industry suggests we're exactly as prone to magical thinking as other groups are. Maybe more so than some, in fact, because many people in the IT field seem to believe that studying some mathematics and logic immunizes them against unscientific thought.
A few years ago I saw a fascinating documentary about orangutans in Borneo. Local women used to come down to the river to wash clothes, and there were a few orangutans who saw them beating the cloth against rocks. So one or two of the more enterprising orangutans started copying them, picking up the clothes and beating them against rocks. Clearly the apes thought, if these ape-like things are doing it, there must be a good reason, and we should do it too.
In my three decades in the IT industry I see the same thing over and over. Groups and teams do things because that's what Google does, that's what Netflix does, that's what Microsoft does, that's what this blog post by this person says. No-one asks, what's the real reason that those companies do those things, and are we sure it even applies to us. So our industry is full of companies whose teams just cargo-cult whatever it is that other companies are doing, endlessly beating the wet clothes against the rocks believing that one day they'll be rewarded for it.
While I do appreciate the cross-species cargo-cult metaphor, I don't think Agile, Scrum and their ilk qualify as engineering in that sense. The program either compiles and does what it says on the tin, or it doesn't. The bridge either stands up, or falls down. Agile et al. are systems for managing humans, who aren't known for responding to inputs as reliably as gears, girders, or compilers.
I can design a car that runs on water. It will only go downhill but it works.
The bridge either stands up or falls down is an exercise in underspecification rather than a demonstration of an absolute metric.
This comment implies a lack of familiarity with other jobs. If you are a doctor, for example, you have little ability to determine the way you work, unless you are exceedingly elite in your field, and even then can be deeply constrained by the institutions you are a part of.
Unless you are "exceedingly elite in your field" you wouldn't do much problem analysis as a doctor, you would do routine checks. The point still stands IMO.
I became a better person during the recessions and the loss of ppl i cared for. Some of the worse examples of humanity ive seen were as a software professional. One of them, a boss I was certain was and is a sociopath. I dont think this was peculiar to software it could been some other profession. If software dev pushed you to be „better“ great. But maybe your going to anyway.
love the image, 'participatory sense making' is important, but IMO software teams that have an 'assembly line' do it by creating strong patterns and pushing them outwards
it's hierarchical style emitted from a relatively few people
my experience of my own 'developer mindset' is to be uncomfortable with uncertainty, and prone to overengineering; I've spent months unwinding this in order to be a product leader and this journey is far from over
there's some poli sci claiming 'desire for best practices' primes engineers to certain kinds of radicalization https://www.al-fanarmedia.org/2016/05/engineers-and-jihadist.... no idea what my threshold should be for believing social science these days, and the authors propose other explanations for the effect they observe
I think fundamentally this confuses "effective" with "good" in a way that seems actually quite incurious and verges towards dangerous.
Sure, to collaboratively build complex technical products, teams must cooperatively form an understanding of various parts, concepts, whatever. And yes, working with a group requires us to be conscientious of the complex and varied factors that impact on the effectiveness of that group.
But ... do those things make you "good people"? What if your team is working really great as a group to build a guidance system for a deadly weapon? What if your team is sense-making in the process of building tools to deliver disinformation in a highly targeted way in the lead up to an election? What if you're really great as a group at building tools to let the state find and censor dissenting speech? Something's clearly missing here.
And the failure to seriously consider what might be good or bad is also present in the author's sweeping claims about everything else that we collectively imagine into being:
> In humanity, participatory sense-making is how we find shared reality in the different pieces of the world that each of us see. We build new concepts that exist only among our minds: money, economy, justice, law, music, conservation, fashion. These are real things that have causal effects on the physical world because we collectively create them.
Is money "good"? Is "justice" good? Is law "good"?
Maybe. There's another lens which might say that all of these are mechanisms by which powerful people and institutions reinforce their own power. The law is good if you get to help write the law. Money is good especially if you get to use taxes to get a population to feed and supply your army. Justice is good if it lets you punish anyone who attempts to subvert your authority. Maybe an example of the trifecta of these would be the "participatory sense-making" that introduced the encomienda system? What if "sense-making" itself can be a weapon?
Sure, let's all try to have healthy communication and collaboration practices in our teams. But let's not delude ourselves that this makes us good.
Not my experience with the number of occupationally successful yet seemingly broken individuals I've worked with. Unless working crazy hours to the detriment of your health and family life is considered growth.
There is a lot to wade through with this blog post. But "pushing us to get better as people" is a VERY subjective statement.
For example, the author is one of the people who started the Greater Than Code podcast. Some of the regulars and panelists for that podcast, since its inception, have been involved in efforts to purging people from conferences, tech communities etc. that they deem to be "un-desirable" or "bad people". The challenge is that the lens they used for applying these labels generally seems to split along political lines, where left leaning individuals tend to agree with these labels and right leaning do not.
If you have successfully purged most of your "un-desirables", forced the other ones underground with the real possibility of losing their job etc., and the only people who dare to say anything are those who subscribe to your ideology (the "in" group), I'm sure that things must look really rosy. But, for the large number of people in the "out group", not so much.
Beyond this, I'm skeptical of software development itself pushing us in this direction. If that statement were true, would we have not noticed this in the early days of the profession?
If you have views that are ignorant and prejudice, and you act on those views in ways that harm other people, you should take responsibility for that, and there should be consequences. Saying that your ignorance and prejudice is a valid political opinion, does not change how people should respond to you. Attempts to politicize bad behavior is disingenuous and a thought terminating cliche.
Claiming cancel culture in the face of valid criticism is an easy out for powerful people who refuse to take responsibility.
Failure to have awareness and take responsibility is the thing that is destroying society. For some reason the institutions that should have been enforcing personal responsibility have failed to do so. Rather than giving up, people are organizing to form new institutions. You may like, or dislike them, but they are going to be different than the one that came before.
>If you have views that are ignorant and prejudice, and you act on those views in ways that harm other people, you should take responsibility for that
Will DA Chesa Boudin take responsibility for his "progressive" / "anti-incarceration" policies in San Francisco which led to a rise in crime?
Will the "defund the police" crowd take responsibility for the rise in crime they have caused?
Both political parties have ignorant views which are harmful. In a lot of ways, pro-choice policies are harmful and even deadly (and through a different lens, pro-life policies are also harmful and even deadly). The whole thing about politics is that you cannot objectively determine the harm of the beliefs involved.
I don't know the full story, but they originally were on Ruby Rogues, and they suggested very strongly they split away from that show for personal reasons. I know the host of Ruby Rogues, Charles Max Wood, is right-leaning.
I knew some of the people involved in that during that time. It was political that, just like everything else in the culture wars, was turned into personal.
> There is an alignment between writing really good software and being good people together
This statement makes me feel good but I don't think it's particularly true based on my experience of working with brilliant a-holes who metaphorically lived in caves by themselves and occasionally threw out amazing code releases.
Sounds good, as a theory. Next step for the author should be to do experiment, collect data, analyse it and reach a conclusion if this theory works or not.
The author seems to be making the point that trying to work effectively and create a good software team can potentially make you better at relating with other people, and maybe even at imagining a better society or reality, and I do think that's possible though not limited to software.
(For example musical groups may offer a literally harmonious and potentially transcendent experience as well as working cooperatively toward shared goals. Schools, religious groups, clubs, and sports teams can also be positive, and so can non-tech workplaces and other non-work communities.)
I would also add that trying to be a good software developer, team, or company means, at least in part, that you should try to write good software that is well-designed, reliable, and user-friendly.
Which is to say, kind of the opposite of much of modern tech which seems to be designed by accretion, unpredictable and buggy, slow and inefficient, hard to use, and often in opposition to the user's goals and well-being and optimized for the extraction of money, time, and attention.
61 comments
[ 3.4 ms ] story [ 123 ms ] threadIt's just a tool. Tools don't make people good or evil. We've all wtched this industry say all the right things for the last two decades, why is so much of what we produce shit and we know it?
I do believe what can limit you from being a better person is to try to find ways to pat yourselves on the back instead of realizing we have a long way to go.
"When disagreeing, please reply to the argument instead of calling names."
"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
https://news.ycombinator.com/newsguidelines.html
I don't know how I could sleep at night if I was working for say google or facebook.
We cannot be equally understanding and empathetic with everyone.
To be a (good) software developer you need to be at least a little bit honest with yourself (can't learn from mistakes if you can't acknowledge you made a mistake, etc.), you need to be curious, you need to be willing to observe and learn and you need to be able to put effort including in things that may not necessarily have immediate payoff.
All of which, I think, correlate with being a good person. Does not mean you will be a good person, it just means there is higher chance.
And, in retrospective, all good developers I have ever got chance to know a little better were nice, good people (at least to me). Which is not true for general developer population (which is to say I also got to know a lot of shitty people which were never good developers).
>All of which, I think, correlate with being a good person. Does not mean you will be a good person, it just means there is higher chance.
None of this correlates with being a good person at all! Let's imagine that I am pure evil and want to maximize harm. Being honest with myself, learning from my mistakes, being curious, being willing to learn and observe, and putting effort into things that may not have immediate payoff are all going to make me better at poisoning the water supply or what have you.
These traits correlate with being effective, not good.
A trait can lead to a lot of different outcomes being more likely. Including outcomes that directly conflict with each other.
Saying "having these traits makes you more likely to be a good person" does not contradict saying "having these traits makes you more likely to be effective evil dictator".
You assume that if having certain traits makes you more likely to be effective evil mastermind it also means it must make it less likely that you are good person. Which is not true.
Imagine following situation: you want to measure how a trait makes it more likely that any random person out of entire population is a surgeon. And then you want to measure if a trait makes it more likely that any random person out of entire population is a lawyer.
We know that being lawyer conflicts with being surgeon -- both require significant investment of time and effort and you have to choose being one or the other.
But, we can find that having wealthy parents makes it more likely that you are both surgeon and lawyer. And that is because being surgeon and being lawyer both requires a heavy investment of time or money or both -- which is more likely to be possible if you have wealthy parents that can support you.
Which of course does not prove my point, but it does invalidate your argument.
> You assume that if having certain traits makes you more likely to be effective evil mastermind it also means it must make it less likely that you are good person.
I do not, and I don't assume that the traits listed make you more likely to be an evil mastermind or a good person, I think they are completely unrelated to morality, and only related to effectiveness (this is what I mean when I say the traits don't correlate with being a good person at all). If you wanted to find the most effective neutral people, you would look for the same traits, because that's what they measure: effectiveness.
Another way of putting your claim: effective people are more likely to be good people. I think that is a very bold claim and have seen no evidence of it in my life, competence and goodness are orthogonal.
But I do agree that it helps to be a good developer that you have good introspection skills, honesty, curiosity, and confidence to make mistakes and learn from them.
But I think GP has a point, he just picked wrong qualities... I believe in software engineering especially it is important to have empathy (to code in a way that others understand) and humbleness (to accept your limitations in a team setting).
Maybe those correlate with being a good person? I don't know.
> Have you ever been on a really good software team? There’s this feeling of connectedness, of shared purpose. We know what we’re building, and we are skilled at building it together. This kind of team can grow some amazing software.
> When we work at making our team great like this, we look for new ways of working together. The original agile movement scratched out imposed structure and asked the team to make their own. At our conferences, we talk about inclusion, empathy, emphasis on relationships. We talk about endless learning, freedom to fail, curiosity and compassion.
> In software, participatory sense-making means developing a shared mental model of what the software is, what it’s going to be, and how it works. We need to understand what we’re building deeply, with a clear language to talk about it. It needs to make sense to each of us, and to all of us. We construct this model together: that means there’s more of us to work at making it real in the world. It also means the model is richer, fits with more of the real world, and more rigorous. This comes from our many perspectives participating.
> In humanity, participatory sense-making is how we find shared reality in the different pieces of the world that each of us see. We build new concepts that exist only among our minds: money, economy, justice, law, music, conservation, fashion. These are real things that have causal effects on the physical world because we collectively create them.
It seems to me that even software people/communities, who have extensive experience working with complex models, very often fall victim to the same sort of counter-productive bickering when the topic of conversation changes to standard culture war topics. My theory (in part) is that when people are talking about such things, they tend to forget that they are talking about custom models of reality (we each have one within our mind) rather than reality itself....and as one should expect, chaos and strong emotions ensue.
But in the soft sciences, like economics, politics, social topics, history, etc., deluded thinking is commonplace even among those highly educated in the field.
What I find curious, though, is STEM PhD's apply rigorous logic to determine if something is true or false. But the same people, when thinking about non-STEM topics, throw logic, reason, and analysis out the window and just go with their gut feel.
A commonplace example is STEM people know very well that (A implies B) is not the same thing as (not A implies not B). They don't make that mistake in their field. But they apply that logical fallacy everywhere else.
Tell that to my boss, who wants to ship every prototype and POC to our customers and call it a day.
You can fake "working" software, that's why so much of it is low quality because to outsiders it is magic and to us insiders...apparently it is magic that only we can perform and those other people can't. We still get paid.
The weird thing is working across multiple fields, the social scientists were the most honest with what they didn't know and made no pretensions about it. But they won't write an essay bout it and post it to HN. The pretensions in this essay would have shot it down in their heads.
I got another comment flagged for "snarky", but I know you are smart enough to see the inherent disrespect to other fields (and perhaps ignorance of them), in your post.
There are undoubtedly good people in those fields. But when a distinguished professor of economics tells me personally that he believes in communism (yes that happened), I lose respect for him, not necessarily the field.
Examples:
- Fixing a marriage
- The Vietnam war
https://en.m.wikipedia.org/wiki/McNamara_fallacy
This makes avoiding self-deception much harder in those domains.
Maybe not, but you can change your definition of what working is.
You absolutely can. The problem is in the ambiguity around the work "working". Take for example the case of a person/team shipping a poor quality implementation which is initially celebrated and rewarded (because no one realizes it's a poor quality implementation) only to fall over in production and cause large problems/disruption for the team/product/business.
This is not an uncommon scenario in software development and I would argue is a case of people pretending (or thinking) something is working when it isn't.
We (engineers, scientists, whatever) exploit ambiguity as a work avoidance strategy all the time, but for many fields exploiting ambiguity is the work. IMO it's like the difference between a think tank abusing statistical bias versus using a firehose of falsehood to push their agenda. Ambiguity is just a tool in the former case that occasionally causes problems, but it is the life blood of the latter tactic and creates a much more destructive atmosphere for critical thinking and societal trust in general.
Like what? Marketing, politics maybe, what else?
It's the "how many people could leave this company before anyone noticed?" game.
Software organizations have such good margins on capital they can afford to hire extraordinary quantities of dead weight before they become unsustainable. I've been at organizations where probably 75% of the software engineering org could be fired with no impact on creativity, growth, or maintenance efficacy.
It's actually the efficiency of software that allows ineffective people to stick around without being noticed. Contra this article, I've noticed whole sections of the software industry deliberately float around organizations at scale. They're typically the people with a boatload of "ex-Cool Company" in their LinkedIn handles.
That's likely what the other employees were saying, too.
It's not exclusive to software orgs, either. Everyone at every company is a special rockstar without whom the company could not survive, and everyone around them is a disposable dumb asshole.
How much is it the other way round?
>you cannot pretend something is working when it isn't.
If you can verify any hypothesis with an experiment, you don't need logic. You can go with your gut feeling, and iterate until it works. Because the compiler and the program itself are bound by logic, software developers don't need to cultivate the same strict logical thinking that other disciplines need.
This is actually less true of software than of other engineering fields. An airplane can only weigh so much, and it needs an engine that's at least so powerful, else it will never leave the ground. With computing, the constraint ceiling is much higher, and it's still getting higher year over year albeit more slowly than it used to. Consequently, you can brute-force a terrible abstraction into kind of, sort of working and it will be acceptable for most use cases, only to break spectacularly when subjected to loads beyond a particular scale.
And yet engineers are doing it all the time. Think of Dieselgate or the Boeing 737 MAX.
One might object that the discovery of Dieselgate or the flaws of the Boeing 737 MAX is prove that the engineers responsible for it were not able to pretend. But then the sentence is analytically true for every other profession too: the discovery of a flaw falsifies claims of flawlessness.
I think that some types of flaws make themselves apparent comparatively easy in (software) engineering. But this might even fire back if it makes an engineer too uncritical so that she put too much trust into the result of her work.
Besides, I do not think that we have good metrics to compare distant professions in terms of their ability to deliver high-quality results. It is perhaps somewhat justified to compare neigboring professions, such as a biologist arguing with a physician or a historian with a political scientist in specific cases. But beyond that, I can really only imagine an exchange of prejudices.
These two are closer to fraud than engineering mishaps.
The big issue with the 737 MAX wasn't the MCAS, it was that management and marketing hid its existence from buyers and regulators. So when it started misbehaving the pilots were not aware this thing was turned on and was steering the plane.
The MCAS did what it was built to do (make the plane behave like a traditional 737).
Why did management hide this crucial information to buyers and government regulators? Because had they not, it's unclear regulators would have certified the plane to begin with since nobody could, in good faith, claim it was eligible to the same type certificate as its predecessors.
But they were aware of how to deal with runaway stabilizer trim, which is supposed to be a memory item (i.e. don't need to consult the checklist). After the first crash, Boeing sent an Emergency Airworthiness Directive to all MAX pilots with instructions on how to regain control. The EA crew did not follow those directions.
In the case of the 737 MAX, I doubt that only the manangement is to be blamed. This sounds like the adage that success has many fathers, but failure none. The practicality of certain design for its intented purposes in its actual use cases is at the heart of engineering. I don't think that a top-down view is sufficient where it is "manangement" that is setting specific goals and "engineering" is only obligated to observe these specific goals instead of also considering the broader context.
Back to the original debate: Even if "the MACS did what it was built to do (make the plane behave like a traditional 737)" the whole design did not what it was supposed to do. Admittedly it did fly, but not safely. And the whole process of quality control, which should ensure that it was safe, did fail as well.
This is why I think a claim like "engineering ... cannot pretend something is working when it isn't" is quite naïve. Why do we need all those complex regulations about quality control, when it is so obvious that something is working or not?
Hm, not sure about that. People talk about making MVPs by letting the user think there's a product there when in reality the solution is done manually, or there to just collect email addresses. See Wizard of Oz, concierge, etc MVPs as examples [0]. There are also no-code tools one can employ to make things seem like they work, again at least to the end user.
[0] https://openclassrooms.com/en/courses/4544561-learn-about-le...
The prevalence of Agile and Scrum in our industry suggests we're exactly as prone to magical thinking as other groups are. Maybe more so than some, in fact, because many people in the IT field seem to believe that studying some mathematics and logic immunizes them against unscientific thought.
A few years ago I saw a fascinating documentary about orangutans in Borneo. Local women used to come down to the river to wash clothes, and there were a few orangutans who saw them beating the cloth against rocks. So one or two of the more enterprising orangutans started copying them, picking up the clothes and beating them against rocks. Clearly the apes thought, if these ape-like things are doing it, there must be a good reason, and we should do it too.
In my three decades in the IT industry I see the same thing over and over. Groups and teams do things because that's what Google does, that's what Netflix does, that's what Microsoft does, that's what this blog post by this person says. No-one asks, what's the real reason that those companies do those things, and are we sure it even applies to us. So our industry is full of companies whose teams just cargo-cult whatever it is that other companies are doing, endlessly beating the wet clothes against the rocks believing that one day they'll be rewarded for it.
At any given time, there might be piles of complexity that nobody has ingested at the moment, and would take time to dig through to get caught up.
A builder can look outside his window to get a crude idea of how far along the project is.
In software, it's often really, really hard to tell.
this article is hokum
it's hierarchical style emitted from a relatively few people
my experience of my own 'developer mindset' is to be uncomfortable with uncertainty, and prone to overengineering; I've spent months unwinding this in order to be a product leader and this journey is far from over
there's some poli sci claiming 'desire for best practices' primes engineers to certain kinds of radicalization https://www.al-fanarmedia.org/2016/05/engineers-and-jihadist.... no idea what my threshold should be for believing social science these days, and the authors propose other explanations for the effect they observe
Sure, to collaboratively build complex technical products, teams must cooperatively form an understanding of various parts, concepts, whatever. And yes, working with a group requires us to be conscientious of the complex and varied factors that impact on the effectiveness of that group.
But ... do those things make you "good people"? What if your team is working really great as a group to build a guidance system for a deadly weapon? What if your team is sense-making in the process of building tools to deliver disinformation in a highly targeted way in the lead up to an election? What if you're really great as a group at building tools to let the state find and censor dissenting speech? Something's clearly missing here.
And the failure to seriously consider what might be good or bad is also present in the author's sweeping claims about everything else that we collectively imagine into being:
> In humanity, participatory sense-making is how we find shared reality in the different pieces of the world that each of us see. We build new concepts that exist only among our minds: money, economy, justice, law, music, conservation, fashion. These are real things that have causal effects on the physical world because we collectively create them.
Is money "good"? Is "justice" good? Is law "good"?
Maybe. There's another lens which might say that all of these are mechanisms by which powerful people and institutions reinforce their own power. The law is good if you get to help write the law. Money is good especially if you get to use taxes to get a population to feed and supply your army. Justice is good if it lets you punish anyone who attempts to subvert your authority. Maybe an example of the trifecta of these would be the "participatory sense-making" that introduced the encomienda system? What if "sense-making" itself can be a weapon?
Sure, let's all try to have healthy communication and collaboration practices in our teams. But let's not delude ourselves that this makes us good.
For example, the author is one of the people who started the Greater Than Code podcast. Some of the regulars and panelists for that podcast, since its inception, have been involved in efforts to purging people from conferences, tech communities etc. that they deem to be "un-desirable" or "bad people". The challenge is that the lens they used for applying these labels generally seems to split along political lines, where left leaning individuals tend to agree with these labels and right leaning do not.
If you have successfully purged most of your "un-desirables", forced the other ones underground with the real possibility of losing their job etc., and the only people who dare to say anything are those who subscribe to your ideology (the "in" group), I'm sure that things must look really rosy. But, for the large number of people in the "out group", not so much.
Beyond this, I'm skeptical of software development itself pushing us in this direction. If that statement were true, would we have not noticed this in the early days of the profession?
Claiming cancel culture in the face of valid criticism is an easy out for powerful people who refuse to take responsibility.
Failure to have awareness and take responsibility is the thing that is destroying society. For some reason the institutions that should have been enforcing personal responsibility have failed to do so. Rather than giving up, people are organizing to form new institutions. You may like, or dislike them, but they are going to be different than the one that came before.
Will DA Chesa Boudin take responsibility for his "progressive" / "anti-incarceration" policies in San Francisco which led to a rise in crime?
Will the "defund the police" crowd take responsibility for the rise in crime they have caused?
Both political parties have ignorant views which are harmful. In a lot of ways, pro-choice policies are harmful and even deadly (and through a different lens, pro-life policies are also harmful and even deadly). The whole thing about politics is that you cannot objectively determine the harm of the beliefs involved.
This statement makes me feel good but I don't think it's particularly true based on my experience of working with brilliant a-holes who metaphorically lived in caves by themselves and occasionally threw out amazing code releases.
(For example musical groups may offer a literally harmonious and potentially transcendent experience as well as working cooperatively toward shared goals. Schools, religious groups, clubs, and sports teams can also be positive, and so can non-tech workplaces and other non-work communities.)
I would also add that trying to be a good software developer, team, or company means, at least in part, that you should try to write good software that is well-designed, reliable, and user-friendly.
Which is to say, kind of the opposite of much of modern tech which seems to be designed by accretion, unpredictable and buggy, slow and inefficient, hard to use, and often in opposition to the user's goals and well-being and optimized for the extraction of money, time, and attention.