[HN Gopher] Software development pushes us to get better as people
       ___________________________________________________________________
        
       Software development pushes us to get better as people
        
       Author : zdw
       Score  : 60 points
       Date   : 2021-11-28 16:08 UTC (3 days ago)
        
 (HTM) web link (jessitron.com)
 (TXT) w3m dump (jessitron.com)
        
       | egeozcan wrote:
       | 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.
        
         | leoh wrote:
         | 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.
        
         | WalterBright wrote:
         | 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.
        
           | randomsilence wrote:
           | >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.
        
           | Archelaos wrote:
           | > 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.
        
           | hyperxy wrote:
           | 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.
        
           | afarrell wrote:
           | Some problems genuinely aren't very amenable to
           | mathematical/engineering analysis.
           | 
           | 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.
        
           | cortesoft wrote:
           | > is you cannot pretend something is working when it isn't
           | 
           | Maybe not, but you can change your definition of what working
           | is.
        
           | cercatrova wrote:
           | > 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.
           | 
           | [0] https://openclassrooms.com/en/courses/4544561-learn-
           | about-le...
        
           | bitwize wrote:
           | > 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.
        
           | stronglikedan wrote:
           | > you cannot pretend something is working when it isn't.
           | 
           | Tell that to my boss, who wants to ship every prototype and
           | POC to our customers and call it a day.
        
             | WalterBright wrote:
             | 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.
        
               | alisonkisk wrote:
               | Or programming your flash drive to pretend it has 32GB
               | when it only has 4GB, as is done on Amazon.com
        
           | jensensbutton wrote:
           | > 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.
        
             | discreteevent wrote:
             | 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.
        
             | akiselev wrote:
             | _> 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.
        
         | jollybean wrote:
         | The level of specificity in the complexity I think makes it
         | unique.
         | 
         | 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.
        
       | fnord77 wrote:
       | I've been a software engineer for 3 decades on several teams.
       | 
       | this article is hokum
        
       | awinter-py wrote:
       | 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
        
       | lliamander wrote:
       | 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.
        
       | black_13 wrote:
       | 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.
        
       | hyperxy wrote:
       | 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.
        
         | dang wrote:
         | " _Don 't be snarky._"
         | 
         | " _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
        
           | csdvrx wrote:
           | 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.
        
       | mistermann wrote:
       | FTA:
       | 
       | > 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.
        
       | lmilcin wrote:
       | 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).
        
         | Hasu wrote:
         | >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_.
        
           | lmilcin wrote:
           | I think you are making logical mistake.
           | 
           | 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.
        
             | Hasu wrote:
             | 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.
        
         | didibus wrote:
         | 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.
        
           | ratww wrote:
           | I agree with you.
           | 
           | 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.
        
             | lmilcin wrote:
             | I agree, empathy and being humble will probably correlate a
             | lot better with both being good person and good developer
             | than some what I listed.
             | 
             | The issue being I think it is much more difficult to say if
             | somebody is empathic and humble. I can easily say I can put
             | more effort in learning stuff than other people I know, but
             | I can't easily say the same about empathy or humbleness
             | because I don't have a way to compare these things, seeing
             | how my understanding of my capability for empathy or my
             | humbleness is so colored by my own subjective point of
             | view.
        
       | sva_ wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2021-12-01 23:01 UTC)