[HN Gopher] Thoughts on why sometimes programming/software engin...
___________________________________________________________________
Thoughts on why sometimes programming/software engineering
discussions suck
Author : retpoline1
Score : 56 points
Date : 2022-08-19 10:08 UTC (12 hours ago)
(HTM) web link (trolololo.xyz)
(TXT) w3m dump (trolololo.xyz)
| Innominate wrote:
| A big thing I think is left out is how deeply personally invested
| people get in the language(s) and tool(s) they use. Technical
| discussions around those things become perceived as personal
| attacks and reasonable discussion is impossible.
| runevault wrote:
| I could be wrong, but I feel like a lot of the most ardent
| defenders are people who stick to one/a couple of languages and
| tools. As someone who loves a lot of languages and has liked a
| lot more before falling out of love, I also tend to have a bit
| more critical eye because I've seen the warts by comparing one
| language to another. No tool is perfect.
|
| It would be interesting to see which tools people are the most
| defensive about. I've certainly noticed a lot of JS defenders
| who ignore how insane some of the weirdness of that language
| (never mind the ecosystem) are, but one person's observations
| aren't data.
| [deleted]
| mdaniel wrote:
| > 2: Everybody may be right
|
| that's the one I was expecting to be there. Computer Science may
| be a science, but software engineering (to say nothing of
| "programming") is a series of scar tissue in bits, intermixed
| with so many different _expectations_
|
| I _expect_ that if a webpage encounters an error, it tells me
| that it did; most managers expect that error handling is for
| paranoid people and slows down ship velocity. Thus, all software
| is terrible, just to different audiences
| wnolens wrote:
| > but software engineering (to say nothing of "programming") is
| a series of scar tissue in bits
|
| Lol. I will use this from now on: A software engineer is a
| computer scientist with scar tissue.
| eastbound wrote:
| The more I work with The Cloud, the more I feel like software
| is alive: Things that used to work, don't, a piece that works
| well becomes bloated with logs that needs to be saved and
| inspected regularly, surgery is sometimes needed to hot-
| replace log4j with 1.18.2, and anything you connect to the
| internet can be infected by diseases. Can't wait for AI-
| specialized psychologists to intervene to understand how its
| infancy is related to their adulthood problems.
| seti0Cha wrote:
| Beyond that, engineers have different ways of approaching
| problems and of crafting the code. TDD may actually work great
| for one engineer, but be terribly disruptive to another.
| Engineers working in IDEs tend to have a different idea about
| what constitutes readable code than ones working in basic
| editors. There is no one way of writing code that is ideal for
| every coder.
| jlg23 wrote:
| > Engineers working in IDEs tend to have a different idea
| about what constitutes readable code than ones working in
| basic editors.
|
| I do like beautiful punch card layouts, too. But I'd still
| not hire someone who uses punch cards to write java. If one
| cannot configure the "basic editor" to provide basic semantic
| tools IDEs had for 20 years, then I don't care much about
| opinions on readability...
| seti0Cha wrote:
| I can see arguments either way. IDEs allow people to create
| complex code effortlessly so the resulting code tends to be
| more complex. Forcing developers to remember names and file
| locations causes the developer to try and encapsulate the
| complexity so they don't have to remember as much. Also, I
| often need to read code outside of an IDE. If the code was
| written to be understood that way, it tends to be easier.
| If I'm going to be living in a single codebase for a long
| time, I love a good IDE. Having good refactoring tools is
| awesome. But I often jump around across many codebases
| across multiple languages and I appreciate if I can make
| sense of them without firing up some specialized tool.
| mdaniel wrote:
| TDD, as the top-most comment correctly points out
| <https://news.ycombinator.com/item?id=32509268>, relies on
| having _requirements_ against which to test, and as very best
| I can tell, requirements aren 't "Agile" because (pick one:)
| (the users don't even know what they want || there's never
| time to do it right, but there's always time to do it over)
|
| don't even get me started on the "basic editor" versus IDE
| war; that's a topic that 100% of the time grinds my gears
| seti0Cha wrote:
| Sure there are other factors that are involved, but my
| point was, some coders are more deliberative while others
| are more exploratory. I'm in the latter group. I think by
| writing code. I do lots of refactoring and sometimes start
| over. Writing tests in the middle of that process would
| result in lots of thrown away test code and a much slower
| exploration of the problem space. Other coders think
| through problems first and know what they want before they
| start. They are more likely to benefit from something like
| TDD.
| Huggernaut wrote:
| Agile isn't about requirements in the sense of "all
| behaviour of this project must be specified up front" but
| that doesn't mean for small slices of validated or to be
| validated behaviour we can't say "this is what it should
| do" (otherwise nothing sensible would ever get written?)
|
| From that point of view, a developer has what they need to
| move forward with TDD (or any other process of their
| choosing).
| dllthomas wrote:
| I've been wanting a documentation system that lets me
| "cite" tests in support of a claim, such that when a test
| fails the programmer can see what claims that test was
| meant to support, which is crucial context in deciding
| how to fix the code, test, and/or docs.
| goostavos wrote:
| Above all else, TDD requires that... ... ...you like
| working that way.
|
| I dunno why the TDD folks specifically get so zealot-y
| about it being the one-True Way(tm). I'm happy that they've
| found something that they like and are passionate about,
| but, damn... it seems like they missed the episode of Power
| Rangers where you learn that different people will like
| different things than you do, and that that's okay. They
| don't have to be "wrong" for you to still enjoy your TDD.
| ARandumGuy wrote:
| I think another factor is that real world software development is
| a never-ending series of compromises. Compromises of performance
| vs readability, developer desires vs client demands, and best
| practices vs "we need that bug fixed now".
|
| Whenever compromises are necessary, conflict inevitably arises,
| based on what different people value. There are rarely
| objectively correct answers in software development, which means
| compromise and arguments are inevitable.
| mason55 wrote:
| And people are bad at taking a step back to examine what it is
| that they're valuing differently. Instead, they just argue
| about the "correct answer" even though they're coming from
| different starting points.
| pdimitar wrote:
| "Sometimes"? I'd say 95% of them suck and more often than not,
| religious-like beliefs get in the way... as usual in all human
| discourse.
|
| People like me who moved on from several different technologies
| during their career -- even though they have built profitable
| sub-careers on their shoulders -- seem to be an exception. I
| didn't expect that. I was convinced that programmers are rational
| and ruthlessly effective and that everyone is like me: they will
| understand and realize the limitations of what they work with and
| will move to something that serves them and the business better.
|
| Oh, how wrong I was.
|
| So yeah, most such discussions are like various religious
| fanatics screaming at each other. With time I severely dialed
| down my participation in such "discussions" and nowadays I only
| comment on HN and leave the occasional (read: 1-2 times a month)
| comments on Reddit. And I have trained myself to care less and
| less if somebody disagrees with me for emotional reasons or due
| to sunk cost fallacy. It's extremely tiring to explain those to
| people, from scratch, every time, and them eventually ending up
| saying stuff like "I don't know man, you might be right but I
| still believe that..." -- and proceeds to repeat something we
| disagreed on 20 times already.
|
| No time or energy for that stuff anymore. If you want to believe,
| then believe. Not my problem anymore, and nowadays I wonder why
| it was ever my problem in the first place (in the past).
| bombela wrote:
| You care because most often it is your problem still. For
| example, when you know with facts that a given technology is
| less error prone than another. But the other party still picks
| the worse one. When a year down the line shit hit the fan, it
| usually ends up back on you. Because you are the only one with
| enough knowledge and expertise to even understand the mess they
| put themselves in.
| hutzlibu wrote:
| "For example, when you know with facts that a given
| technology is less error prone than another."
|
| I am sorry, but this sounds a bit like you are in the
| fanatics camp.
|
| It always depends on what you want to build and what is the
| given skillset of the people and the avaiable time.
|
| Bad teams will mess up even with the best technology and good
| teams can deliver with outdated imperfect languages. And good
| teams can disintegrate over religious tech wars ..
| pdimitar wrote:
| This is always down to context -- so please don't
| generalize somebody as a fanatic.
|
| Many times during my work it has become apparent that (some
| examples follow):
|
| 1. We constantly introduce bugs due to the dynamism of the
| language we use. We had in-house devs that could have
| rewritten a few very small services (think 20-ish
| endpoints, we're not talking rewriting a mastodon with 500+
| here) in a static strong typed language. Alas, almost
| everyone mercilessly shot that effort down even though it
| was right in everyone's faces how that will reduce the
| upkeep of bugs and maintenance with at least 50%, if not
| 80%.
|
| 2. Somebody figured it's a genius idea not to follow the
| conventions of a certain web framework. At least 15 people
| came and left over the course of a year and they all
| struggled hard to adapt. It's not because they're stupid;
| it's because you have a well-working schemata in your head
| that you have to undo many times over just so you can work
| in a single team / company. Eventually all these people
| figured it's not worth it and I can relate to them (even
| though I and several others had no difficulty adapting).
|
| 3. At one team somebody decided that the in-VM cache
| implementation is buggy -- even though it absolutely is not
| because otherwise even stuff like WhatsApp wouldn't
| function well, btw! -- and they said "hey, let's not only
| use Redis for cache" (which is fine) "...but also let's use
| it for mutexes and semaphores that span several computers"
| (lol). Only after me and another senior threatened to leave
| did management finally budge and they left us to rewrite
| the thing which resulted in smaller Dockerfiles, simplified
| deployment, inadvertent fixing of 20-30 intermittently
| failing integration tests, and reduction of coding lines by
| about 1200 (in a project with 11500-ish coding lines so 10%
| decrease). Then we still left afterwards btw, both of us
| together, because management figured we're some kind of a
| threat and sabotaged us at every turn afterwards. Petty
| small humans ignoring feedback from users and other dev
| departments telling them we did the right thing. Those I'd
| call fanatics.
|
| Point is, people want one thing to "just work" and never
| touch it again, and then proceed to use fluff language to
| disguise this like it's anything else BUT that. Some of us
| see through that BS.
|
| Yes, error-prone tech exists. Yes, projects get improved by
| the removal of those. And I truly believe all this mindset
| of "you can do your project in ANY tech and it won't make a
| difference" seriously has to stop. This has been
| demonstrably false throughout most of computing's history.
| Supermancho wrote:
| I'm certainly in the defensively argumentative crowd.
| Eventually, as someone who likes doing this work, a
| single/series ends up being a massive albatross on the team
| until the project dies or someone steps up. That's often me,
| because I don't want to be miserable. Sometimes the choices
| are so monumentally bad, there is no way to fix it. It's just
| a miserable death march.
| pdimitar wrote:
| Yeah, I am very much the same (if I read you correctly): I
| get it that maintenance is more important than "devs
| playing with new shiny toys" -- a saying over which I
| slammed a manager in a high-level meeting and I didn't
| flinch doing it; I'd do it again! -- BUT sometimes it's
| painfully obvious, usually months later, that using tech X
| or Y just makes it that much harder to maintain the
| software.
|
| There are points at which difficult decisions have to be
| made. It's a shame most managers / CTOs / VPs of
| engineering are so cowardly and idolize not being spotted
| by upper management for having a few hiccups in their
| projects, over any other concerns.
|
| I have no patience for their political in-fighting in
| companies so I usually arrive at a contract, beat a bunch
| of things into shape, reduce test failures, simplify
| deployment, introduce a few conventions (and document them)
| that make it easy to change code, make 1-2 high profile and
| very requested features and then usually end up leaving 6-9
| months in -- simply because I start getting included in the
| political games. At that point I am like "hell no" and just
| move on.
| [deleted]
| Quarrelsome wrote:
| mirror: https://archive.ph/SRcA7
|
| due to https issue and my corporate firewall was blocking it.
| jackblemming wrote:
| This is exactly right. For every developer who hated so and so
| framework, there may have been a developer who absolutely loved
| it. And they're both "right".
|
| Most decisions do not have a right or wrong, just trade-offs that
| some developers would make, others wouldn't.
|
| But seriously don't use crappy ORMs.
___________________________________________________________________
(page generated 2022-08-19 23:01 UTC)