Software development pushes us to get better as people
jessitron.com
jessitron.com
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.
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.
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.
> 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.
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.
this article is hokum
We cannot be equally understanding and empathetic with everyone.
(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.
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
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.
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.