[HN Gopher] Software engineers hate code
___________________________________________________________________
Software engineers hate code
Author : dfcowell
Score : 294 points
Date : 2023-07-08 09:28 UTC (13 hours ago)
(HTM) web link (www.dancowell.com)
(TXT) w3m dump (www.dancowell.com)
| JohnFen wrote:
| > This is the best-kept secret of the software engineering
| profession: engineers hate code. Especially code written by other
| people. It's why they love working on greenfield projects so
| much. No code, no maintenance, no headaches!
|
| Except that I've met lots of engineers who were the opposite.
| They hate greenfield projects and prefer maintaining existing
| code. I noticed this broad division of personality early in my
| career. And it's a great thing -- both sorts of engineers are
| critical to a successful project.
| austin-cheney wrote:
| Sure. Of course there are actually software developers out
| there in the world that read and write code. After all, that's
| where all this software in the world actually comes from.
|
| But for the other 85+% of people in the profession its
| basically a game of AdLibs. Fill in the blank. That's why there
| is such heavy reliance on things like frameworks, dependencies,
| and _Invented Here Syndrome_ (people who don 't trust their own
| or teammates code). That's why you have expert beginners,
| because you can get really masterful at coloring with crayons.
|
| Try to take any of this color by numbers nonsense away and see
| immediate full on emotional apocalypse. It's not a choice. The
| number one priority is to retain employment, and if your
| employer has failed to provide you the preparation or
| environment necessary to perform with confidence this is what
| you get.
| Der_Einzige wrote:
| The way that masked language models are trained is nothing
| more than madlibs. This is how I've always explained it to
| normies and they get it quite well.
| jacurtis wrote:
| > But for the other 85+% of people in the profession its
| basically a game of AdLibs
|
| This is so true. I work at a fairly small organization (~35
| devs). Large enough to see roles form but small enough that I
| can tangibly see everyone's contributions. I work SRE, so I
| see lots of code from all the teams and ultimately talk to
| almost all the devs.
|
| In our impressive enterprise-level codebase (our SaaS product
| has average annual subscriptions in the range of $1.5M per
| customer), there are probably 3 developers that wrote 80% of
| the codebase. I can name them all and call them up. But I
| said we have 35 devs in the organization. So what do they do?
| Mostly little things. Flipping a conditional or making a
| slightly more explicit test case to fix an unexpected edge
| case we experienced.
|
| Most of these 32 other engineers are solving simple problems,
| basic refactoring, and so forth. Not too different from the
| adlib, fill-in-the-blank analogy you provide.
|
| Also, to be clear, it isn't like we hired 3 seniors and
| expect them to write all the code. These are just groups
| people fall into naturally.
|
| The reality is most software engineers have only ever done
| the adlib style work and have built an entire career around
| never solving any real problems. They know just enough syntax
| in a language to solve the little problems and with software,
| there is a near infinite supply of these little problems.
| intelVISA wrote:
| This is why the tech interview is still an unsolved problem
| (for non-tech ppl).
|
| How does a non-tech role sift through the 32 devs who did
| 10YOE flipping bools vs. the 3 that built the entire
| system? They'd look similar on paper and in superficial
| conversation.
| zerbinxx wrote:
| This is the plague of hiring senior engineers, and one of
| the reasons we needed a new code test/challenge to get
| fewer bool flippers in our senior engineer hiring
| process. If you make them do something
| complicated/complex you get a lot more signal than if the
| test is bool flipping/a simple project from scratch
| snickell wrote:
| Sounds like SRE has afforded you a unique "who's writing
| what code small-org-wide" semi-impartial perspective.
| Thanks for sharing!
|
| I'm curious if the ~three devs that "wrote 80% of the
| codebase" mutually recognize one another? i.e. do you think
| they think of themselves as in a "writes a lot of code"
| category along with the other ~two devs? Do they think of
| themselves as "writes a lot of code"? Does management
| recognize this and/or plan around it?
|
| I've sometimes been one of the "people writing a lot of
| code" in a small org. When I'm in that mode/context, I find
| myself daily appreciating the types of contributions made
| by the larger body of folks less deep in the woods. They do
| a different and complementary type of work, and I've found
| both types bring something valuable (and different) to the
| codebase.
| whstl wrote:
| When I was a developer I hated it. I was almost always
| the #1 in LOC, Jira Tickets, Scrum Points, you name it. I
| was naturally good at it, but the environment was always
| very competitive and the other top performers would brush
| it off as just me being lucky with "LOC Heavy" tasks. And
| it would piss me off that I would get paid the same as a
| guy who wrote 200 LOC a month and wasn't doing much more
| than those lines.
|
| Being a manager/lead developer today, I enjoy the people
| doing small work. I just let them pick tasks as they
| wish, and it takes longer, but they eventually pull
| through.
|
| The problem is just that they're a bit unpredictable, so
| if something has a tight deadline, we gotta assign to
| someone else.
| austin-cheney wrote:
| As a developer I don't mind that other people don't do
| work. If they want to stagnate in their career that is
| their problem, but it certainly isn't a problem for me...
| until they make it my problem. This typically happens
| when entitlement sets in and the baseline lowers so
| dramatically that not doing work becomes a mandatory
| expectation only shattered by the crying when
| conveniences are peeled away.
|
| Worse than that are the people who work their ass off,
| but just aren't good at it. I would rather work with
| people who prefer to not do work. The output is generally
| the same, but the people who work their asses off cannot
| see the difference and believe they somehow deserve more.
|
| In my career the single biggest failure that I see
| repeated EVERYWHERE is confusion about what software
| really is. There is only one purpose to any of this:
| automation. In that mantra actually not doing work is
| supremely desirable so long as the output meets
| expectations.
| lo_zamoyski wrote:
| Or someone who does both.
|
| 1. Only working on greenfield means you don't want to learn
| from others or have difficulty doing it. Lots of knowledge is
| expressed in the code you refuse to read and you need humility
| and patience with your own ignorance.
|
| 2. Only reading code is insufficient as you are not only a
| scholar of the code base, but a maintainer and developer who
| must extend and adapt it.
|
| Working with a code base is more like a conversation. There's a
| back and forth, though not symmetrical. (1) is someone who
| monologues. (2) is an audience member only.
| dvhh wrote:
| Because a greenfield project would require to do something that
| software engineer abhors more than writing code: giving time
| estimates in an "agile" environment.
| rco8786 wrote:
| I'm pretty good at writing code but I consider one of my
| "superpowers" to be that I also love to read code. I cannot
| even begin to estimate how this has affected my career and
| abilities. It's a task that most seem to dread, but is
| something that I do for fun.
| faitswulff wrote:
| This article on makers versus menders highlights the
| differences between those who prefer greenfield and those who
| don't pretty well:
| https://corgibytes.com/blog/2015/08/14/makers-vs-menders/
| zirgs wrote:
| They prefer maintaining existing code until they get a project
| that's full of legacy stuff and nobody wants to replace it,
| because it works (most of the time at least).
| YZF wrote:
| Most of my early career was "greenfield". I really loved doing
| that. Sometimes that meant me doing everything. Guess where the
| buck stops? There's no way to disconnect the final result from
| the work. Keep in mind though that green field pretty quickly
| turns into maintenance. You ship something, guess what, there's
| bugs to fix. You want to add a feature, you have an existing
| code base. The nice thing is that there's no one else to blame.
| Is it really hard to add a feature? You (or your team) messed
| up. Does the quality suck? You (or your team) messed up.
|
| Even in well established code bases there can always be "green"
| new pieces. These are choices to make: should we refactor the
| code, should we fix the old code, should we rewrite pieces of
| it. There is no one answer that always works. The problem is
| when you look at something and your answer is always a rewrite
| just because you didn't write the original code. I've seen
| people/team rewrite perfectly good code for no business reason,
| just because they want to.
|
| In terms of code written by others, sometimes that's a thing of
| beauty, a piece of art. Sometimes it's just garbage. I'm sure
| we've all seen some code where we go wow, this is incredible.
| And then we've all seen code where we go wtf. I don't really
| see the need to dig too deep there, what's great is great and
| what's garbage is garbage and then a lot is somewhere in the
| middle. I sometimes look at code I've written in the past and I
| think it's really great; and sometimes I go wtf. Usually the
| latter is where I was not familiar enough with the problem
| space or the code base I was working in. Questions to ask are:
| does it work? what's the cost of maintenance? Ugly code that
| works well, doesn't need to be touched, can be fine.
| fzeindl wrote:
| I like both. Greenfield projects can be pretty boring when
| there isn't something special about the functionality or a new
| architecture to try out, but it feels good to spurt out stable
| features when you know what you are doing.
|
| Repairing / fixing / retrofitting an old code base always has
| it's wonders. I've seen much code in my life that was in a bad
| shape and my approach for fixing was seldomly the same, it was
| always tailored to the team and situation.
|
| To rephrase from Tolstoy: "Good code bases are all alike, every
| bad code base is bad in it's own way."
| jrochkind1 wrote:
| But do they actually want to read the code on the existing
| project, or just write new code adding to it?
|
| Nothing is universal, but I think often the latter.
| lylejantzi3rd wrote:
| I love rehabbing legacy code. It's like furniture restoration
| for apps.
| [deleted]
| levidos wrote:
| I'm one of the persons who loves refactoring existing code.
| It's much easier to get started than writing something from
| scratch. I change a few bits, then I get more ideas on how
| the code can be further improved. I always try to consider
| the business value - is the a maintainability problem? Does
| the code need upgrades to reduce tech debt? Etc. Hard to sell
| this sort of work to PMs who just keep pushing for new
| features.
| bayindirh wrote:
| Well, I'm currently trying to reverse engineer something done
| by an open source SaaS offering, to patch a tool written by
| another person which works with that part I'm trying to
| reverse.
|
| I just wanted to use the tool without any effort, but I have
| to understand the interface and patch the tool to make it
| work again. I'm not complaining.
|
| Just wanted to add a data point for the former part of your
| comment.
| jrochkind1 wrote:
| And you enjoy and prefer this kind of work? OK! I guess
| occasionally I enjoy this kind of work too, when I'm in an
| environment with reasonable expectations of how challenging
| it will be/long it will take, when I have room for it.
| delusional wrote:
| I always apply Chesterton's fence when working on existing
| systems. You don't get to add, remove, or change things
| before you understand what exists. That discovery is
| inherently exciting to me.
| WJW wrote:
| Depends on the project and the person I guess. The trust of
| your manager is tremendously important. N=1 here, but at my
| current client it took me several hours of staring at a huge
| SQL query before I understood why it wasn't fast but the
| client was trusting enough that it was time well spent. I've
| also has PMs who could barely understand the concept of
| refactoring at all.
| soneca wrote:
| I am one of those who prefer working on existing code. I like
| making things better, understanding how a code works is thrill,
| adding new features on existing premises.
|
| I am also an amateur fiction writer, and I notice the same
| thing in it. I like planning, but the first draft writing is a
| chore to me. An effort to vomit all my ideas as words. Then, I
| love rewriting. Revisiting what I wrote and improving it,
| fixing it, perfecting it.
| flir wrote:
| Some people are editors, some people are authors.
|
| Some authors _really_ need an editor.
| Brian_K_White wrote:
| Some editors don't know they're not authors.
|
| Not a rebuttal just an addition. All these things are true.
| jvm___ wrote:
| How do you find job postings for these types of jobs? Any
| keywords to look for? And how do you interview for them?
|
| I don't want level 3 support or on-call rotation, just
| established software that needs diagnostics, bug fixes and
| upgrades.
|
| I guess you just have to apply and ask in the interview.
| srcreigh wrote:
| My brother works for Birds Canada making 40k CAD a year.
| Got dropped into a 500-1M line Java codebase and asked to
| do site redesign and is now implementing SSO for them.
|
| I recommended "Working With Legacy Code" and he read it.
|
| His first job so great experience. I guess be underpaid is
| the answer.
| [deleted]
| riku_iki wrote:
| I think the reason to like working on existing code is that
| infra is usually very complex nowdays, and for greenfield
| project you need to do lots of boring tasks to bootstrap it,
| and for existing code it is already bootstrapped by someone.
| therealdrag0 wrote:
| Not just infra. It's the tests, it's the crud, its getting
| clients and config setup, it's banal decisions around
| copying existing patterns or trying to refine them for next
| gen copy pasting.
|
| It's fun early in career, but gets boring fast IMO. These
| are good things to have junior and mid eng cut their teeth
| on.
| 0xEFF wrote:
| The sweet spot is for someone with deep experience to lay
| down the skeletal structure of the tests, rpc, infra,
| lifecycle, etc... then hand it off to a broader team who
| could learn the intention behind the decisions.
| jrumbut wrote:
| > who could learn the intention behind the decisions
|
| If people did learn those intentions we wouldn't have the
| problems we have.
|
| I inherited a project like this once as the third
| generation to take it over. The (evidently, I never met
| them) well trained and experienced first developers laid
| down a foundation using a textbook OO style with a few
| little tricks needed to make that work in a language
| where OOP support was bolted on. The code was not
| perfect, but it was professional work and I would put it
| around the 80th percentile in terms of code quality.
|
| These tricks caused the virtues of that foundation to be
| overlooked entirely, and so the project was essentially
| reimplemented in spaghetti style over time with various
| ad hoc stovepipes to pass data back and forth between the
| two sides when the original had functionality that wasn't
| understood well enough to be reimplemented.
|
| The importance of training, communication, and retention
| can not be overstated.
| riku_iki wrote:
| Yeah, sorry, I personally call it dev infra
| djangelic wrote:
| I'm similar, and I've found AI to help with this. I'm able to
| guide the AI to write the first draft, then I go in and
| rewrite it. It's helped remove that frustration at the first
| draft.
| lolinder wrote:
| What model do you use for this?
| mrweasel wrote:
| > I am one of those who prefer working on existing code.
|
| Me too, mostly because I hate starting a project form
| scratch, it's something I'm not particularly good at. Like
| you, I love rewriting, I love improving things, making them
| better, faster, or easier to understand.
|
| The notion that software engineers hate code is wrong,
| depending on who you consider a software engineer. SREs,
| systems administrators, operations people, they hate software
| with a passion. Developer (who in my mind are software
| engineers) freaking love code and will write more code to
| cover up problems which should have been address by
| revisiting designs and earlier assumption. I've meet with
| developers who's understanding of IT outside the realm of
| development have been so extremely poor that they frequently
| reinvent basic webserver or database feature, but badly.
|
| Currently I'm working on a Django project, in the back of my
| mind I always have a notion that if something requires more
| than 20 - 30 lines of code, then it's either already a
| feature of the framework, or I'm doing something terribly
| wrong. That rules has yet to fail me.
| jtxx wrote:
| hah humans are interesting! I'm the opposite. I love starting
| a codebase, I also make music and it's way easier for me to
| make 100 cool unique sketches live and improvised but not
| finish anything. it really takes all kinds
| mrweasel wrote:
| I would love to team up with someone like you. Having a
| person that can start a new code base and not be
| overwhelmed by the task is a godsend. I'm much more
| comfortable diving into an existing project and extending
| it or fixing bug than I am starting something new. Somehow
| it's just more natural for my brain.
| lc9er wrote:
| My favorite musical partnerships have a balance of a
| starter and (me) a finisher. I really struggle with
| producing raw material, but am good at revising, reworking,
| and cutting out fluff and my best writing partners are
| great at spewing out ideas, most of which are cut. It
| together, we are able to make something we're both excited
| about.
| sanderjd wrote:
| Yep I have a hard time with a blank page and love the flywheel
| of incrementally iterating on a working baseline. I didn't
| realize this until very recently; I think I had internalized
| "well everyone loves greenfield projects, so I must too".
| parineum wrote:
| I think it's a culture thing in SV/VC//startup world and I
| think that group is very public, outspoken and sure that they
| speak for everyone.
|
| Most if us aren't that but we just continue about our business
| developing new features and squashing bugs. I like greenfield
| projects but the choices and freedom they present come with a
| lot of non-coding and missing infrastructure.
|
| A nice brownfield project lets me check in code, see it auto
| built into the dev environment and have QA feedback the next
| day.
| antigonemerlin wrote:
| I mean, there are badly designed brownfield projects with
| tight coupling, bad documentation, and, where you have to
| spend half an hour to figure out why a simple change broke
| everything.
|
| Funnily enough, personally, I can handle badly designed
| projects as long as I was part of the team designing it. At
| least then I understand it enough that changing things isn't
| too much of a pain, and I can pretend my refactors will
| eventually make the codebase look good (or if that fails, I
| can write enough documentation to at least mitigate the
| problem). It's a pain in the ass for new maintainers though.
|
| But goddamn, working in a good established project where
| other people have done the hard work of figuring out non-
| coding project management stuff is a fricken breeze. No
| arguments there.
| bayindirh wrote:
| I think it's a spectrum. For example I like writing new code
| and designing new things, but I don't hate or dislike my or
| other people's old code.
|
| That code also has been written by a human, and it's
| disrespectful to approach somebody else's work with this
| prejudice.
|
| It might not be good code, by our standards, but who knows how
| it was written. Was the author under stress, under time
| obligations, or happy, or something else?
|
| Also, being able to approach somebody else's code and work with
| it is humbling and deeply educative for me. You get a (free)
| passage to a wisdom of a person or a group. That's priceless.
| BossingAround wrote:
| > That code also has been written by a human, and it's
| disrespectful to approach somebody else's work with this
| prejudice.
|
| Not only has it been written by a human, but one should also
| remember that they're missing the context in which the code
| was written. Was the author stressed about their latest
| children being born? Fearful of possible layoffs? Under time
| pressure? Tired?
|
| I've definitely written code myself that came to bite me
| later, and I marveled at how badly written that was.
|
| We're all human, which, among others, means that we're all
| inconsistent to a large degree.
| j45 wrote:
| Brilliant summary and the parent comment.
|
| Too many developers remain hyper committed to shiny object
| syndrome, or wanting to relearn lessons of the past as if
| they are the first to ever lay eyes on it.
|
| No code is perfect, and lots can be learned even from a
| well intentioned approach gone wrong.
|
| It's far easier learning from other folks and their
| rattlesnake bites instead of insisting of recollecting that
| baggage yourself, first.
|
| Greenfield is still useful, but too often it has to do with
| preference and interpretation or a lack of willingness to
| do so.
| HeyLaughingBoy wrote:
| The funny thing is when you get used to someone's coding
| style, you can tell if they were stressed or under time
| pressure or not.
| fragmede wrote:
| Also important is Chesterton's fence and the history lesson
| when touring existing code. What were the business
| requirements the first time around that were thrown out the
| window for version two, but there was no time for
| refactoring so version three has this known wart that
| version four tried to refactor but that wasn't complete
| until version five which had this new feature that needs
| another refactor.
| evandale wrote:
| > That code also has been written by a human, and it's
| disrespectful to approach somebody else's work with this
| prejudice.
|
| Small piece of advice: it is much better to learn how to take
| criticism of your code as exactly that - it's criticism of
| your code. People will always be unkind when reviewing code.
| Even if it's the best code ever written someone will have a
| different opinion and express it in a seemingly unkind way.
| It's easy to be unkind in code reviews because it's _code_
| being reviewed and NOT a person with feelings.
|
| Like you said, a different human (the more junior version of
| you) wrote that code, not you. It's not a criticism of you no
| matter how much your brain tries to tell you it is. People
| will never stop saying "who the fuck wrote this shit!?" and
| you will hear that phrase until the end of time. It's still
| not personal when people yell that in frustration.
|
| For example, I have learned that Eastern Europeans tend to be
| absolutely brutal in code reviews. Everything will be
| nitpicked and the most benign design decisions you've made
| will be questioned. They make you feel stupid and inadequate
| but that's your own feelings. It's more likely you're dealing
| with a direct and to-the-point perfectionist who can see the
| code beyond your PR and how your code fits in with the rest
| of the application. They're not the greatest at communicating
| this context and their comments seem like personal attacks
| without that context.
| WJW wrote:
| Indeed! This phenomenon has been a great source of freelancing
| customers for me.
|
| Startups naturally thrive on an early team that loves building
| new things, but the flip side is that they rarely seem to go
| back to fix existing stuff. That leaves a gap for people like
| me, who prefer to take something that works poorly and make it
| bulletproof. For some reason this quite often seems to involve
| db access patterns but there's a fair bit of algorithms work
| too. Usually the "building new things" engineers are quite
| happy to let me take over the investigation into why the 150
| line SQL query is slow, so it's a win-win.
| j45 wrote:
| Startup teams also aren't great as they should be at being
| even slightly kind and thoughtful to their future selves.
|
| Understanding greenfield usually means iteration, a small
| amount of conceptual architecture and organization before
| dialing into the matrix to go full Neo can go a long, long
| way.
|
| Specifically, it's easier for startups to create productive
| new beginners in their codebases.
| elbows wrote:
| Out of curiosity, how do you go about finding clients for
| this kind of work?
| lapcat wrote:
| Am I unusual in enjoying both?
|
| Earlier in my career, I was stereotyped as a "maintainer", but
| now I've been a self-employed indie developer for years, so all
| of the code is mine.
|
| Once your own code gets to be 5 years old or so, it's almost
| like maintaining someone else's code. It's like, why in the
| world did I write that before??
|
| I guess my focus has always been on the product and the user
| experience, so I don't make the code itself central to my work
| and my identity. The code is not the product.
| delusional wrote:
| [flagged]
| klysm wrote:
| Oh please. By your definition no greenfield project has ever
| existed in thousands of years.
| wsve wrote:
| This makes no sense to me... Greenfield projects have
| problems that legacy projects don't (What language to use,
| what framework to use, where/how to deploy, etc.), and vice
| versa (How do I design my feature with the existing
| limitations of the system in mind, do I need to to redesign a
| part of the existing system to get it to work, etc.).
|
| None of that has anything to do with "Time thinking about the
| problem", nor does either one imply that its questions are
| easier or harder to answer in all scenarios. They're just
| very different questions, but some devs prefer dealing with
| the issues a greenfield project presents.
| andrewl wrote:
| _If you wish to make an apple pie from scratch, you must
| first invent the universe._ Carl Sagan
| RhodesianHunter wrote:
| What use is this sort of pedantry? No project is greenfield
| unless you hand made the silicon?
| delusional wrote:
| Fair question, I suppose I didn't express myself clearly.
|
| Firstly, I'd like to abolish the idea that "greenfield" and
| existing are somehow opposites. Greenfield projects take on
| a bunch of existing abstractions and complexities from all
| the stuff they are built on. Instead, these two terms are
| actually very similar, "greenfield" projects just chose to
| throw out one more layer than using the existing system. My
| argument here is that the dichotomy here is false, and that
| the two terms are instead a classification of degrees to
| which you abandon existing abstractions.
|
| As I said, I understand that this is what you mean when you
| say greenfield, I'm not asking you to use different words.
| I'm asking you to pay notice that this is what you are
| saying. That you are explicitly not in a "green field" with
| nothing around you. You've thrown all the furniture out,
| but the building is still there, the walls are still the
| same color, and the windows are still overlooking the same
| parking lot.
| zeroonetwothree wrote:
| I like both types of work. It's fun to do greenfield projects
| because of less maintenance and the ability to do it the way
| you want. But it's also fun to take something years old that's
| barely working and try to gradually improve it while minimizing
| down time.
| dfcowell wrote:
| This is a really great point, and it's awesome when a team
| strikes the right balance. In my experience these engineers
| tend to be rarer than the group I talk about in this post, but
| when you find them they're worth their weight in gold!
| scarface_74 wrote:
| I didn't realize how unique my circumstances were until I
| started reading r/experiencedevs.
|
| I've had 8 jobs over 25 years and over that time, I've mostly
| done green field work, including at my first job out of
| college.
|
| I'm not even sure I have the skillset to modify a huge existing
| code base.
|
| Even at one job where there was a large codebase that I was
| "modifying", it was mostly to add new CRUD features to an API
| or website and I did my own vertical "slice" that didn't
| involve modifying existing code.
| revskill wrote:
| Writing "unreadable code" is easy, just as too easy to make your
| room a mess.
|
| Writing "readable code" is so damm hard.
|
| Readable code leads to maintainable code, which reduces tech
| debts.
|
| Alright, many engineers just knows how to fix the bug and call it
| a day. It's a disaster thinking.
| zerodensity wrote:
| I have heard of this magical beast "readable code" but have not
| yet encountered it in the wild.
| someweirdperson wrote:
| Examples have been discussed here [0] before.
|
| [0] https://news.ycombinator.com/item?id=4331688
| paseante wrote:
| ROFFFFFLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL.
|
| OMG this is brilliant
| rglover wrote:
| I love code (similar to how an artist might love a type of paint
| brush), but what I don't love is code that's designed to impress
| or an attempt to show off hOw SmArT i Am. More often than not,
| that code isn't the most efficient or the cleanest, it's just a
| contraption that _looks_ impressive to an untrained eye. _That_
| type of code is guaranteed to turn a code base into a mess--all
| for the sake of someone 's ego.
|
| My preferred heuristic is: "will I or any other developer be able
| to understand this--quickly--in six months (preferably without
| comments)?" If the answer is "no," refactor using a different
| approach.
| 000ooo000 wrote:
| Doesn't seem right to say that engineers hate code. IMO, in a
| sense, code is lossy; rarely does it document the full set of
| assumptions, intentions and context relevant at its inception or
| over its life. Possibly more appropriate to say that writing new
| code can sometimes avoid the lack of those things which make
| modifying code simpler. Do engineers hate being in a position
| where they have to rely only on intuition and inferences rather
| than hard evidence? Well, I do, at least. Do I hate code? Nope
| easeout wrote:
| In this thread: Software engineers also love to point out when
| their counterexample has been glossed over by an intentionally
| simplistic thesis.
|
| (In this comment: Software engineers also love to sass one
| another)
| riwsky wrote:
| Sass is unnecessary in modern stacks; just use tailwind instead
| fsociety wrote:
| Reading and untangling code is the best part of coding in my
| opinion. It's like solving a fun puzzle and trying to
| incrementally evolve a system.
|
| What I hate is inconsistency. Inconsistency is what makes code
| intolerable to work with, because changing it becomes so much
| harder.
|
| Consistency, in the way I mean it, does not mean DRY or over-
| abstraction. What I mean is, pick a mindset or design philosophy
| and stick to it. Don't randomly switch between exceptions and
| returning errors. Don't over-abstract some areas early on and
| then spaghetti code other areas. Have some consistency in how you
| do this.
|
| For example, have a rough standard for when something is X or Y.
| Either accept spaghetti code for areas and keep things uncoupled
| as much as possible (my preferred), or have some concept of
| abstraction you apply to new layers. Just rough examples.
|
| If it turns out you did it wrong, which is likely, then it is
| relatively easy to reason about a change. But as soon as you lose
| the consistency then it becomes a nightmare. Don't have special
| snowflakes in your code.
|
| The last thing I'll write is.. sometimes the over-generalization
| this article makes is used as a weapon to justify sunk cost
| fallacy. Sometimes throwing away a part of your codebase and
| starting from scratch is the best thing to do. But you should
| work with it for a bit to understand the code before doing so.
| [deleted]
| bulhi wrote:
| There are only a few experiences in life that give me a dopamine
| rush as intense as when I delete code. I used to think I was
| weird, but apparently I'm just a senior engineer.
| exmicrosoldier wrote:
| There is only one more thing I am afraid of more than duplicate
| code. Shared code that someone changes to make their code work
| better that breaks yours.
| miikavonbell wrote:
| I've been a software developer for almost 10 years and during
| that time I've questioned many times why I keep on going.
|
| A while ago I realized that the biggest thing that I like about
| software development is the simplicity within it's complexity.
|
| What I mean by this is; software either works or it doesn't. In
| many other professions this is not the case.
|
| So while there are many things that could be done better and more
| efficiently, at the end of the day, your code either works or it
| doesn't.
|
| So simple, but yet, so ruthless.
| akira2501 wrote:
| > software either works or it doesn't
|
| You don't use threads in your software, do you?
| turdprincess wrote:
| I find it to be more nuanced. Your code has to work correctly
| in a bunch of scenarios. Some are very simple to see, others
| are nuanced corner scenarios.
|
| A good developer will write code that passes many of these
| scenarios, but even the best will miss some. And an
| inexperienced developer might write code which passes some
| basic scenarios.
|
| So, "this code works" is really a range, not a binary
| condition.
| miikavonbell wrote:
| "Code either works or it doesn't" is more like a mindset and
| a pholisophy rather then truth or a fact.
|
| In the context of this article and this thread, I was just
| reminded about this approach.
|
| Hating or loving software development, other peoples code, or
| approach is sort of meaningless.
|
| At the end of the day, we all get paid to build software and
| it is our job to make the software functional.
|
| As long as the code works and does what it is supposed to do,
| thats all that matters.
| jowdones wrote:
| My high school computer science teacher (almost 30 years ago
| that is) used to say: "A program that 'almost works' is like a
| plane that 'almost flies'".
| falcor84 wrote:
| Now I'm just trying to mentally picture what a mode of
| transportation that almost flies would work like via animal
| metaphors - would it almost fly like a chicken? or like a
| flying squirrel?
| jononomo wrote:
| If you like ruthless simplicity you should try functional
| programming.
| [deleted]
| Falkon1313 wrote:
| >Senior engineers hate extraneous code. They hate seeing time and
| effort invested in building yet another solution to an already-
| solved problem. [...]
|
| >Don't write new code when you can use, improve or fix what
| already exists.
|
| Caveat: Refusing to write new code often means pulling in and/or
| writing a whole bunch of extraneous code.
|
| Senior engineers also hate dependency hell, having to patch other
| people's code because upstream hasn't fixed it yet, knowing that
| might break on the next update, yoinking in massive complex
| frameworks and libraries when you could've just used a few simple
| functions, and having lots of kludgy plumbing code to wire up all
| those third party dependencies and generic abstractions.
|
| All those things that people do just because it's best practice
| not to "reinvent the wheel". All those things that require extra
| work, maintenance, and system resources, but aren't directly
| related to solving the business problems. All that time wasted
| not even working on the valuable domain logic.
|
| And then when you do eventually get around to implementing or
| modifying a domain case, can you even find where the domain code
| is in all that mess of extraneous code?
| _madmax_ wrote:
| This is so full of over generalizations it gets boring really
| fast.
| zerodensity wrote:
| All code is not created equal. In a project there is normally
| some divide between shared code and service specific code. This
| divide can be as simple as a base class and its children or a
| library and the microservices that use it. I declare that shared
| code is sacred and should only be touched for a good reason.
| (Note: sacred does not imply good)
|
| So when reviewing my carelevel is highly dependent on if shared
| code is touched. If the commit only contains changes in the leafs
| eg subclass / single microservice my gut instinct is to trust the
| code and go into LGTM mode (if it goes wrong it's at least
| localized). But if shared code is touched I don't trust it, I
| deep dive and complain about everything I can think of.
| ranting-moth wrote:
| Using a house analogy, I don't hate other people's houses. I hate
| it when other people blow a hole in the side of my house to put
| in a new window.
|
| They blasted a hole through two walls because it was the quickest
| way. Then just taped some plastic over the second hole. The
| project manager said it's still summer and we don't really need
| that wall at the moment.
|
| I know who will have to fix the wall when the winter comes and
| I'm not looking forward to it. There's nothing in it for me and
| I'll get asked why my wall wasn't OK in the first place?!
| coding123 wrote:
| it's not a good analogy when it's not realistic. How often are
| people walking down the street blasting holes in peoples houses
| to add windows?
| Brian_K_White wrote:
| It's a good analogy if the reader understands it, and it is
| accurate.
|
| Both are true here. People don't get away with quite that
| level of nonsense with buildings because even laypeople can
| see all the essentials, why it would be bad, who to blame if
| it did happen, etc. So it never happens and doesn't need any
| kind of illustraing analogy to explain it to anyone.
|
| That DOES happen all the time in software and it's invisible
| to almost everyone including your own bosses, and does need
| some kind of analogy to illustrate what's wrong about it, and
| how wrong, and the nature of the wrongness.
|
| Any other example that actually ever happens, would just be
| some other equally opaque phenomenon from some other esoteric
| field, and would by definition be useless as an analogy.
|
| The whole point is so that anyone can see it and conclude
| "that would be crazy, outrageous, intolerable". Of course it
| never actually happens.
| wudangmonk wrote:
| I get the point but I do agree that it might not be a good
| analogy since when building structures people might disagree
| on where they should go but not on what a wall and a door
| are. In software your caretfully crafted "house" can just be
| a convoluted way to get from a to b to someone else.
|
| To me writing a story comes closer to what writing software
| is. I can't just get an overview of their plans and know
| right away where I should be connecting the new "room" I want
| to build. Instead I need to understand what story the author
| was trying to get across and make my insertion in a way that
| makes sense with what was there before.
| dap wrote:
| My house has a hole where a cable tv contractor inserted a
| coax line that they ran all the way around the house, from
| the service drop to right outside the living room. This
| despite the house being wired with coax internally, including
| between these two points. There was a disconnect where
| someone had replaced a tee with a coupler some years ago, but
| this was easy for me to find and fix.
|
| Years later I spoke with an ISP about an install and they
| proposed exactly the same thing. I think people do this a
| lot.
| jokethrowaway wrote:
| You don't hate other people's houses until you're forced to
| live in one of them.
|
| Then, I agree on the point of someone else blasting a hole in
| your house.
| Tade0 wrote:
| In the same tone:
|
| Someone put fake shutters on the sides of the windows - the
| wrong size at that. This was accepted as a good solution
| because no one tried to close them. Would be impossible anyway,
| because there are no hinges.
|
| This happens more often than it might seem.
| zer8k wrote:
| A follow up analogy is more typical in my experience. The
| foreman says that we should reinforce the walls. The PMP
| certified 6 sigma ninja Project Manager insists that the
| reinforced walls aren't necessary because no one is going to
| put anything on the wall. We will revisit the wall later when
| we the city tells us to enforce new wall codes.
|
| No more than 6 months later a contractor tried to add a shelf
| to the unenforced wall. The contractor was never aware of what
| was in the wall and assumed he could find a stud. What he
| thought was a stud was actually the stud finder pinging on a
| water pipe. The construction workers didn't have time to run
| any tests with stud finders so they just wired everything up at
| the behest of management and hit the wall a few times with a
| rubber mallet to see if it held up. The project was behind by a
| week already due to the plans getting to the job site late.
|
| He pounds in the nails, hits the water pipe, collapses the wall
| and floods the house. The on staff construction crew lose their
| jobs, the VP gets a promotion for showing they did something
| about this egregious error, and they are replaced with
| contractors.
| coding123 wrote:
| this is also not a good analogy because building codes will
| often just require 20" O.C or 16" O.C studs and those are in
| the plans- drafted by a person that designed the home (self,
| architect, drafter). Reinforcements for shelves or cabinets
| are also part of the code for kitchen walls. Those are not to
| be expected in every location in the house.
|
| The framers are locked into the house plans as far as stud
| distances and special framing members that are specified.
| County inspections will make sure that's all there.
|
| House construction is far, far more standardized and strict
| that programmers coding crap code. It's not a good analogy.
| sli wrote:
| No analogy is good when you dissect it to pieces. Being
| perfect encapsulations of reality is not the point of
| analogy, they are simply there to increase understanding.
| weswilson wrote:
| I'd say it's a pretty good analogy, the details aren't
| perfect, but it gets the point across.
|
| https://www.youtube.com/watch?v=FfEX6GUxfZM
|
| Here's an example of an arguably good builder who had one
| team install a in-wall tank toilet, then another team
| drills right through the tank causing a leak. The repair
| work essentially meant ripping out everything and doing it
| over, even though there should have been mitigations in
| place to prevent it and having the plans/documentation
| available to everyone.
|
| While construction has more standardization, planning, and
| inspections, it still relies on implementation and is going
| to have failures.
| andrekandre wrote:
| > House construction is far, far more standardized and
| strict that programmers coding crap code. It's not a good
| analogy.
|
| the way i took it was that in home construction what they
| describe is completely absurd and yet that is how most
| businesses do software, so the contrast there drove the
| point home (no pun intended)
| ranting-moth wrote:
| "programmers coding crap code" vs. builder building crap
| houses. Both exists and both are very real.
|
| In many ways the builders are even worse because they can
| usually hide the faults with caulk and paint if you want.
| Problem becomes evident when things start to leak or rot.
| That can be later but been causing damage in the meantime.
| bloqs wrote:
| "The PMP certified 6 sigma ninja project manager" had me
| rolling
| gabereiser wrote:
| "All of this has happened before, and all of this will happen
| again" - Six, BSG.
| B1FF_PSUVM wrote:
| Filching from Nietzsche, scriptwriters are lazy bums.
| pdimitar wrote:
| Pieces of art are repurposed all the time, I am sure
| Nietzsche took it from somebody living even further back
| in the past.
| gom_jabbar wrote:
| The eternal return of the same :)
| dontknowwhyihn wrote:
| "What happens once will never happen again. What happens
| twice will surely happen a third time."
| tehnub wrote:
| Ecclesiastes 1:9
|
| "The thing that hath been, it is that which shall be; and
| that which is done is that which shall be done: and there
| is no new thing under the sun."
| usefulcat wrote:
| Plus ca change, plus c'est la meme chose
| ChainOfFools wrote:
| Either that or they were aware of what they were doing
| and left the extreme irony of what they chose to repeat
| as a kind of Easter egg for anyone familiar with the
| source.
|
| Just kidding, they're lazy.
| activiation wrote:
| They got off easy with your analogy.
| goto11 wrote:
| Code is only greenfield until the first commit.
| nathants wrote:
| false. it's until the concrete hardens. could be quick, could
| be slow.
| [deleted]
| nfw2 wrote:
| Literally my primary motivation to be productive at work is
| maxing the ratio of my code to other people's code that I have to
| deal with
| birdyrooster wrote:
| Literally my primary motivation to not be productive at work is
| people maxing the ratio of their code to my code. They do all
| the work and management is still fine with paying me more
| because of seniority. I think this is a fair trade as all
| freedom comes with responsibility -- I used to be the same way
| earlier in my career.
| formerly_proven wrote:
| I always say "one bug per if".
| Supermancho wrote:
| I dont like this, but it's hard to find fault in it in the
| context of an aging (eg 50yrs+), large, corporation. There are
| always corner cases and workarounds that would require
| inverting the expected output of an 'if statement', requiring
| yet-another-one altogether.
| B1FF_PSUVM wrote:
| That's a good phrase, true or not. Poetic licence.
| syntaxing wrote:
| Better yet, engineers in general hates discipline. A lot argue it
| stifles innovation, makes them work slower, a bunch of red tape.
| While it's true to a certain degree, you also can't scale without
| discipline. If you can't scale, it's not engineering, it's a
| science project. It is a balance, too much processes hinders
| execution, too little means everything will be a mess by the time
| you deliver.
| anonzzzies wrote:
| Don't think it's a secret though.
| 29athrowaway wrote:
| Software engineers do not hate code.
|
| They hate when they're put in front of horrible code and they are
| disempowered to do anything about it.
|
| Or they are forced to agree with people with learned
| helplessness.
| nikanj wrote:
| The people who truly hate code work in upper management. Coders
| are expensive, hard to hire, and tend to say no a lot.
|
| You can make so much money selling hoax "zero code" solutions, as
| management is very happy to drop money into projects that promise
| to replace coders with Magic Product(tm)
| ibejoeb wrote:
| > we deprecate it as legacy and replace it with something new.
| Rolling green fields forever!
|
| That's a good way to put it. The nuance is that, most of the
| time, "deprecated" means "not going anywhere anytime soon, so now
| we have 2+ subsystems for the same thing."
|
| You really do need someone with a grand plan to keep this in
| check.
| psychoslave wrote:
| That is non sense. Like any peace of art, code can be a delight
| to contemplate or an awful experiment that was done as is just
| because, see, it's possible.
|
| Of course 99% of everything is crap, and no one like to ingest
| crap.
|
| Add to that impossible deadlines and usual exponential
| accumulation of hot fixes to a point where a bright new product
| will be more effective than paying the technical debt. Crafting
| software is on far worse road than most form of art.
|
| All that said, yes, there are great peaces of code that are a
| delight to contemplate.
| beebmam wrote:
| I like contemplating all code and thinking about ways to
| improve it. I've made a career of being a code janitor.
| notjoemama wrote:
| I'm an engineer and I don't hate code.
|
| But I do hate clickbait.
| thenoblesunfish wrote:
| Yes, hell is other people's code, haha. But you don't need
| microservices to write modular or encapsulated code.
| dgbrewer1989 wrote:
| Interesting. I'd say that's true for the majority of engineers
| yeah. For my own career I've been stuck on projects (with the
| exception of one last month) that was all over 3 years old and
| needed maintenance. Some projects were learning to read AS400 RPG
| code then converting that into java code. So I guess that is
| kinda greenfield? I don't know, I enjoy reading code and
| understanding what's happening But I absolutely get the distaste
| for it
| rationalfaith wrote:
| [dead]
| nixpulvis wrote:
| This is like writing "mechanics hate bolts".
|
| Yea, mechanics love to complain about metric and imperial sizes
| and when they don't thread in correctly, but at the end of the
| day a good mechanic loves seeing a smooth running car.
|
| Similarly, a good software engineer loves it when they have a
| smooth running service. Updates work without hiccup and the
| system can be inspected to see how things are running. Having
| clean and maintainable code is directly proportional to the ease
| and pleasure of work on this service.
|
| I believe in quality over quantity and I also believe that
| beautiful code exists. My hatred of code comes from lazy or
| rushed implementations, which can and should be improved over
| time.
|
| LGTM culture is a product of bad management and should not be
| used as an excuse to ship lazy code or code written by people who
| hate what they do.
|
| A good engineer should take pride in their work, even on the bad
| days. And even when the product itself isn't what they would
| personally want.
| resonious wrote:
| > LGTM culture
|
| What are you referring to specifically here? A culture where
| nobody is actually doing reviews and just LGTMing everything?
| nixpulvis wrote:
| Yep
| formerly_proven wrote:
| Yep
| dools wrote:
| "I hate writing. I love having written"
|
| https://www.goodreads.com/quotes/57688-i-hate-writing-i-love...
| jrochkind1 wrote:
| What percentage of code you have worked with in your career is
| that beautiful code that you love to work with?
|
| To make it more fair, code you wrote yourself doesn't count,
| because you aren't an objective observer -- and more
| importantly, have a different relationship to it making it
| easier to work with since you wrote it, and often to your own
| preferences.
|
| I think I agree with you, it's just that... the actual way
| software is written doesn't seem to allow for much clean and
| maintainable and easily extensible code to be written, so I'm
| not sure how much it matters practically.
| nixpulvis wrote:
| A healthy percentage of the open source projects companies
| I've worked for have used and opened PRs against I would call
| pretty good looking. Ruby on Rails was always nice to read
| through and well documented. I also find a lot of datasheets
| and RFCs to be highly elegant and beautiful, if not a bit
| dense and verbose. It just depends sometimes, what makes
| something like _art_ beautiful.
|
| I disagree strongly that "the actual way software is written
| ...", though it does feel like trying to write clean code is
| an uphill battle sometimes.
|
| Back to the shop analogy. Cleaning up oil spots and
| maintaining well polished tools requires time and care.
| weinzierl wrote:
| I'm not so sure about software engineers. We often value
| _working_ solutions even if the code base is not perfect. I
| certainly do and I very much agree with Joel Spolsky in his
| classic:
|
| " _Things You Should Never Do, Part I_
|
| "They did it by making the _single worst strategic mistake_ that
| any software company can make:
|
| They decided to rewrite the code from scratch."
|
| [1] (Emphasis his.)
|
| Where I'm 100% sure is that consultants hate code. I've never
| ever seen one recommending the reuse of existing code - not once.
|
| And it's understandable: They have nothing to gain from
| recommending reuse of existing code.
|
| In the best case the code is good _and_ everything else goes well
| and the client saves some money. If the consultant can not pull
| this of repeatedly their benefit will still be limited. The
| praise will be with the programers.
|
| On the other hand, if the old code is bad or anything else goes
| wrong everyone will blame the consultant for the recommendation.
|
| For the consultant it's a risk-return tradeoff that just _always_
| favors a rewrite from scratch.
|
| [1] https://www.joelonsoftware.com/2000/04/06/things-you-
| should-...
| andix wrote:
| Im a big advocate of rewriting code from scratch. Because on a
| rewrite you have a much better starting point. You have a
| (mostly) working solution, you understand the problem much
| better than on the first attempt, you have some tests and some
| data. Most of the time you don't rewrite it 100% from scratch,
| often you can copy a lot of code from the old solution.
|
| To utilize all those benefits you can't rewrite everything at
| once from scratch. You need to do it incrementally.
| aledalgrande wrote:
| What you are describing is called "refactor" not "rewrite".
| Incremental changes that use existing code don't allow for
| great changes in the architecture.
|
| I'm not against rewrites, sometimes the company grew so much
| that you need to start from scratch and rethink given your
| current knowledge. Or you started with a low fidelity
| prototype and you rewrite to create a production ready
| feature, without the crufts in the design you had when you
| started.
| andix wrote:
| It's also possible to incrementally change the
| architecture. It doesn't have to be a Big Bang.
|
| Edit: refactoring is usually considered to be done on
| existing code base. I really mean thowing a whole component
| away and re-doing it from scratch. The components need to
| be small enough though, that you can deliver them to
| production within 2-5 months.
| aledalgrande wrote:
| Yes, it's not a black and white situation.
| jvans wrote:
| The incrementally part is extremely important and often
| overlooked. I have seen project after project attempt some
| major big bang rewrite that always takes way longer than
| expected, delivers less value than promised, and causes
| problems in areas that used to work fine. We often understand
| some big picture things better as time goes on but there's a
| thousand small decisions baked into the existing code that
| are very easy to overlook
|
| On incremental improvements you should be able to stop what
| you are doing within a week or two and be ok with leaving the
| code like that for a long time.
| hinkley wrote:
| The main value a big bang rewrite has is that for six to
| eight months the dev team gets a break from being asked a
| lot of uncomfortable questions. By the time the questions
| get properly uncomfortable again, you've worked there long
| enough for it to be reasonable for you to leave.
|
| Incremental improvements require more skill. The sorts of
| skills that make you a better developer. So even though
| it's more difficult, it's much more valuable to all parties
| for you to attempt it.
|
| The only reason for a rewrite is when you have a language
| or framework that's dead, and there are often other
| dynamics that put you in that spot in the first place.
|
| There are a bunch of common mistakes people make with trees
| that take years off their life expectancy. The worst
| guarantee the tree will be dead in twenty years (and
| potentially dangerous before that). Software has similar
| phenomenon, on a much shorter time scale.
| jvans wrote:
| I am sure there are good reasons for it, the postgres
| proposal for switching concurrency models[1] comes to
| mind. I actually just posted this question to see what
| people come up with:
| https://news.ycombinator.com/item?id=36646299
|
| My knee jerk reaction to rewrites is so negative I
| actually would like some counter evidence on when it
| worked out.
|
| [1]https://www.postgresql.org/message-
| id/4658520e-5cd0-6242-e54...
| ficklepickle wrote:
| We're in the midst of a couple rewrites that are
| going/have gone well. Perl to golang and angular1 to
| react.
|
| The common factor is doing it gradually, basically page
| by page. There is no big switchover, new code goes live
| as it is ready. We have some very competent people with
| long tenures which surely helps.
| parineum wrote:
| I'm not a usually a huge fan of buzzwords and I usually
| give trends time to pass before bothering with them but
| this is an advantage of micro services that I really like.
| lisasays wrote:
| Of course Joel was wildly hyperbolizing, to the point of
| absurdity.
|
| Code gets re-written from scratch all the time, for perfectly
| legitimate reasons. As even Joel Spolsky knows. He just meant
| that you should be _aware_ of the trade-off, and that _most of
| the time_ , you probably don't want to re-write from scratch.
|
| But "Never do X" sounds much catchier. And succeeded in getting
| the article shared and quoted infinitely and endlessly, to this
| very day.
|
| Even though everyone knows it isn't, you know, actually
| literally true. Even Joel.
| jvans wrote:
| I don't think this is hyperbole, i completely agree with it
| as written
| [deleted]
| partomniscient wrote:
| Software Engineers also hate sensationlist headlines/titles.
| CyberDildonics wrote:
| I think Hacker News shows that they love them.
| someweirdperson wrote:
| Most people love to hate something. That and reproduction are
| the two main factors that govern almost all human behavior.
| nathants wrote:
| sturgeon's law applies. most of the time they are right to.
|
| put another way, 90% of code is a liability, 10% of code is an
| asset.
|
| i'm not sure any code ever moved from one group to the other,
| though good ideas may be stolen sans code.
|
| greenfield is the only way to grow that 10%. it's the reason
| startups exist.
|
| it's like all the failed rewrites. those engineers gained
| knowledge and fitness through that failure. if their current
| employer doesn't retain them, that knowledge and fitness will pay
| dividends to the next one.
| klysm wrote:
| Rewrites are a phenomenal way to sprint through an incredible
| number of Chestersons fences. That is one way to find out why
| they are there though it's just a bit more expensive
| boringuser2 wrote:
| I'm terrible at reading code.
|
| I've analyzed myself in process and it's because I get bored and
| start glossing over details.
|
| In some cases, I feel this makes me a weaker engineer than my
| detail-oriented counterparts.
|
| In other cases, I connect concepts and problem solve better than
| they do because I am quite smart.
|
| The division of labor, I guess.
| theknocker wrote:
| [dead]
| hahamrfunnyguy wrote:
| It's a great day when I've deleted more code than I've written!
| mtippett wrote:
| To me, it isn't about the code itself, it's about communication,
| it's about a relationship with others through code, systems and
| architecture.
|
| Using the relationship analogy, when you can hear something small
| from your partner and know what they are thinking, understand
| what they may do next it feels effortless.
|
| When you look at some code, can you trust what the function name
| implies is done, without concern?
|
| When something is complex in a relationship we pause to take time
| to communicate and come to a common understanding, we write notes
| to each other.
|
| When we have something complex in code do we write down
| information to help the other engineers work through it?
|
| In a lot of ways the way we relate to our peers through code is
| possibly a reflection of how we relate to others in life.
| [deleted]
| lolive wrote:
| Sometimes, software engineers find abstractions that suit their
| mental model.
|
| Sometimes, they even are able to create codes that match such
| abstractions.
|
| Sometimes, those abstractions are now flawed.
|
| Sometimes, those abstractions are properly tooled.
|
| Sometimes, the rest of the team also understands those
| abstractions.
|
| The conjonction of all these rarely happen.
| usrbinbash wrote:
| > Don't write new code when you can use, improve or fix what
| already exists. If you must write new code, write only what you
| need to get the job done.
|
| While the article resonates with me alot, I would like to, in the
| best spirit of the article, propose an addendum to that line:
|
| _When modifying existing code, do a very careful cost-benefit
| analysis; On the one side is the cost of a rebuild. On the other
| side is the projected cost of keeping this thing and maintaining
| it, not just for this change, but for changes in the forseeable
| future._
|
| I realise that this is essentially an impossible requirement. We
| cannot forsee the future. But: We can make predictions. And when
| the predictions say, that, forseeably, the company will lose
| money down the line because we waited to long for a rebuild, it
| may be time to pitch that to whoever allocates resources.
|
| Because, dragging a legacy-system along incurs it's own set of
| costs. This is especially true when it's not just maintained, but
| modified and extended. And many of those costs have a nasty
| tendency to remain hidden until they suddenly don't, and at that
| point, people often already expended inordinate amounts of
| resources on them.
|
| So yeah, the first instinct should be: Use what already exists.
| But check the costs of doing so. Premature rebuilds are a waste
| of resources. And so is holding on to legacy systems past their
| expiration date.
| goto11 wrote:
| > when the predictions say, that, forseeably, the company will
| lose money down the line because we waited to long for a
| rebuild, it may be time to pitch that to whoever allocates
| resources.
|
| Only developers who love greenfield or need a new framework on
| the CV would suggest a company could lose money by _not_
| rebuilding.
|
| If the developers are not competent enough to write
| maintainable code or maintain existing code, then you will have
| exactly the same difficulties after the rebuild.
|
| If they are competent enough to write maintainable code and
| maintain existing code, then you have no need for a rebuild.
| Just adapt and extend the existing code to meet the new
| requirements.
| Silhouette wrote:
| _If the developers are not competent enough to write
| maintainable code or maintain existing code, then you will
| have exactly the same difficulties after the rebuild._
|
| Why assume the _same_ developers would be doing the rewrite
| as the original? Maybe the reason for the rewrite is because
| the original is hopeless and most of the people who worked on
| it are no longer around.
|
| Also everything usrbinbash said in a sibling comment - but if
| something like a changing environment forces a big rewrite of
| an otherwise successful code base then having the original
| developers still around can dramatically increase the chances
| of success IME.
| usrbinbash wrote:
| > If the developers are not competent enough to write
| maintainable code or maintain existing code
|
| Or if the old system simply doesn't work with modern
| environments.
|
| Or if it depends on long abandoned frameworks.
|
| Or if the business grows but the old implementation scales
| badly or not at all.
|
| Or if it depends on components that incur licensing fees that
| become prohibitively expensive when it's scaled up.
|
| Or if there are other legacy systems on different technical
| baselines that it could work with better after being rebuilt
| on the same base.
|
| Or if its tech simply requires more maintenance than an
| alternative, thus binding dev resources the company could
| otherwise use more productively.
|
| There are alot of reasons why maintaining an old system may
| be an undesireable move in the long run, that have exactly
| zero to do with the competence of the developers involved.
| goto11 wrote:
| The key is identifying which parts of the code needs to be
| adapted or replaced and which do not. If the code is well
| designed with separation of concerns, replacing a framework
| or library or external dependency should not require _all_
| the code to be scrapped, just the layers directly
| interacting with replaced part.
|
| Some trivial applications are basically just glue between
| frameworks, but most non-trivial application of value will
| have lots of code which is not tied to any particular
| framework, and often this is the most valuable part of the
| application.
|
| Scalability is improved by identifying the bottlenecks and
| improve the design at those core points - not by rewriting
| everything from scratch.
|
| I guess moving to a different programming language is a
| case where you literately have to touch all the code, but
| even then code can often be ported semi-mechanically
| instead of starting from scratch.
| zerbinxx wrote:
| In my experience one of the main reasons for wanting to
| scrap code is not only that it has scaling/other tech
| issues, it also has very poor separation of concerns.
|
| Granted, that concept can and should be introduced into
| old codebases. Last year my team successfully warded off
| the Sirens of Rewrite by just doing the hard work of
| extracting all of the dead framework calls and then NOT
| adding them back in drag-and-drop style, but properly
| exposing them through interfaces that don't require
| everything to know everything about the particular
| replacement framework we used.
| usrbinbash wrote:
| > If the code is well designed with separation of
| concerns,
|
| "If" is the operative term here. "If" it is well
| designed, then there is usually not alot of reason to
| scrap it in the first place.
| hinkley wrote:
| You say that as if these events are unfortunate accidents
| instead of lack of technical leadership.
|
| I've met quite a few "unlucky" people in my life and what
| nearly all of them had in common was the inability to
| connect their actions and inactions to consequences. They
| were blindsided by predictable outcomes over, and over, and
| over again. Eventually the people who could actually help
| you get tired of your drama and move on, and then you're
| left in an echo chamber where your narrative makes sense.
|
| I've spent a lot of time on this job thinking about the
| thoughts and plans of the people who have left. If our
| vertical were more compelling I believe we could make a
| better product with the people who have left than with the
| people who stayed. Even considering the lack of depth in
| domain knowledge. There's a lot of things that don't change
| because they were the right thing to do ten years ago.
| That's an explanation for how we arrived here, not a reason
| to stay.
| Silhouette wrote:
| _You say that as if these events are unfortunate
| accidents instead of lack of technical leadership._
|
| Sometimes they are. I've seen several applications that
| were successful for many years but eventually had to be
| rewritten because some vital dependency was no longer
| viable.
|
| In web development we had an early generation of web apps
| that used plugins like Flash or Java to do things. Fast
| forward five years and those plugins have been brutally
| killed off by the browser developers. However other web
| technologies have become viable alternatives for some of
| those things. That's a big rewrite.
|
| Some programming languages have had big jumps that
| weren't entirely compatible. Python 2 to Python 3 is an
| obvious example that took years but eventually resulted
| in not only Python 2 no longer being supported but some
| libraries never being updated to support Python 3 and
| others being created to provide similar functionality. In
| this case many of the direct code changes could be
| automated but you can't automate swapping out each
| obsolete library for a replacement with a similar purpose
| but a different API. And maybe you wouldn't want to
| because in the 5 or 10 years since you built the last
| version new ideas have come along and you're better off
| adopting them instead since you have to make a big change
| anyway.
| dfcowell wrote:
| This is a really good addition, and something I wish I'd
| thought to cover. I've added a link back to this HN thread to
| the post so that people who find it from other sources can
| benefit from your perspective!
| delusional wrote:
| >On the other side is the projected cost of keeping this thing
| and maintaining it, not just for this change, but for changes
| in the forseeable future.
|
| That's going to be very difficult, especially when you then
| also have to consider that the changes you could do could
| REDUCE the cost of maintaining it. If you're only ever
| appending code, then the cost to maintain can quickly
| skyrocket. If you're also diligent about removing the features
| that you don't need, there should be no significant difference
| at the limit.
|
| Basically, assuming you are properly maintaining the existing
| system, you should be continually refactoring it to be what you
| would build if you started from scratch. In that view, the cost
| of maintaining it will be identical, and the only cost that
| matters is the cost of bringing the existing system into
| alignment with what you would build now.
| PartiallyTyped wrote:
| Personal example I am living through.
|
| By the estimates of another team, it will take 2-3 months to
| build a wrapper around their codebase (it is that entangled)
| and throw that in EC2. The whole project will become infested
| with that codebase and those issues because as we all know, a
| "temporary fix" is never temporary. The codebase doesn't cover
| anywhere near what we have in mind for features and
| extensibility is ... yeah.
| elygre wrote:
| I notice that on your "one side", you have the cost of the
| rebuild -- but _not_ the "projected cost of keeping this thing
| and maintaining it".
|
| That's a common fallacy of programming: the existing code is
| convoluted and hard ti maintain, but the new code I would
| replace it with will be much better and much cheaper to
| maintain.
| kmoser wrote:
| In addition to projected cost to maintain, there is also the
| potential ill will you are continuing to generate with your
| customers if the existing buggy/legacy system affects them.
| Your reputation with your customers matters. This is one of
| the biggest factors I see companies ignore all the time.
| XorNot wrote:
| Conversely...in a lot of cases you can reasonably project
| it's likely you won't be maintaining it. So what you're
| really projecting is how much trouble you expect to save
| yourself for your forseeable remaining time at the company.
| usrbinbash wrote:
| That's a very good point you make there, and I should have
| mentioned that in my post.
|
| Yes, the cost of the rebuild itself, PLUS it's own
| maintenance, fit with the rest of the codebase, extensibility
| and so on, must be considered in that equation.
|
| I glanced over that, because usually the rationale for a good
| rebuild is an improvement regarding exactly these metrics.
| djbusby wrote:
| Yea, they(we) always say the new code will be better. Yet,
| eventually the new code becomes the old code and the cycle
| repeats.
|
| Assumptions and Environment change. New becomes old. And old
| has maintenance cost.
| jt2190 wrote:
| > And many of those costs have a nasty tendency to remain
| hidden until they suddenly don't, and at that point, people
| often already expended inordinate amounts of resources on them.
|
| Any business that employs software developers knows _exactly_
| how much it costs to employ them. If that math doesn't work
| then the software developers loose their jobs. This basically
| establishes a baseline for "value" that must be delivered, at
| minimum.
|
| _Above_ the baseline, software devs are left to their own
| devices: There will be no hard accounting of weather
| development effort is "worth it", rather it'll mostly be about
| whether people _feel_ like it was. (This is sort of the origin
| of "too much money spoils things".) As long as the effort
| doesn't destroy everything, it can be argued that it was a
| success!
|
| So, the "hidden" costs are actually "bearable costs" because
| the business is just fine. The costs are "revealed" only when
| they're no longer bearable. Ironically, well designed software
| "hides" the costs much longer than poorly designed, so what is
| missing is that we don't have a great way of assigning value to
| in-house developed software that "just works". Developers don't
| even really think about it much because they get paid for
| writing code.
|
| I think that's why the advice...
|
| > Use what already exists
|
| ... becomes very hard, in practice, for devs to follow, even
| though it's _excellent_ advice. It's a problem for management
| to solve.
| m3kw9 wrote:
| Reusing code cause issues if you are not very careful because
| if not checked people often keep adding to it or someone
| modified it for their use case and breaks others. Many times is
| just better not to reuse
| edgyquant wrote:
| This is what tests are for
| [deleted]
| wizofaus wrote:
| > The more code that gets written, the more things there are to
| break, and more of those precious hours will be taken up by
| maintenance
|
| Can definitely relate - PRs with lots of new code immediately
| trigger alarm bells for me, and while reading through all that
| new code ain't necessarily fun, coming up with ways to reduce it
| is a worthwhile and rewarding challenge - unfortunately you're
| then stuck with the thankless task of convincing the author why
| they should throw away all their hard work.
| lolc wrote:
| It's a good idea to pull in reviewers early while mapping out a
| solution. Not easy though.
| kodah wrote:
| Reading this article I realize how different I am from, I guess,
| some of my peers. I do like working on new things, but
| methodically shaping old software, bringing it up to date, and
| all the tactical thinking you need to employ to do so is very
| fun. Microservices are okay, and I use them mainly when I have a
| particular part of a codebase that's best suited to scale on its
| own. Outside of that, I'm a big fan of starting with monoliths
| that are written so they can be decomposed at a later date.
| There's something really nice about a well put together codebase.
|
| Stack overflow is probably another place I differ from other
| engineers. I'll use it to discover patterns I'm not aware of, but
| I'm much more inclined to actually Ctrl+click and look at how a
| thing is implemented and it's sibling methods. Of course, you
| need well put together local configuration to do all that. I'm
| always looking for ways to keep my debugger in-tact, even when
| dealing with things like secret storage on a zero trust network.
| I use flags a lot for this that let me use mock-local responses.
|
| Then again, I work on infrastructure stuff. The kind of
| applications I work on _have_ to exist for a long time because of
| internal contracts and dependencies. Maybe this piece is more
| aimed at product SWEs.
| VirusNewbie wrote:
| Yeah i'm a swe SRE and i love going into a moderately well
| architected application and making it even better or more
| scalable. It's fun!
| klysm wrote:
| I hit a turning point at some point where I stopped being
| afraid to read library code and ctrl click through things. Not
| sure when exactly it happened but I think it was related to
| some imposter syndrome and holding the library code as "holy".
|
| Looking through library code instead googling can be incredibly
| productive and polishes your code reading skills which are very
| important.
| drooby wrote:
| Q
| raincole wrote:
| Developers hate code. Non-developers _fear_ code.
| B1FF_PSUVM wrote:
| ChatGPT _shits_ code
| praveen9920 wrote:
| It's not 100% true. It depends on how well the code was written
| and documented. When we see patterns or complex code which are
| different from what we are used to, it takes some amount of
| effort to understand and to make changes.
|
| code that is simple, documented and well written is best thing
| any developer can inherit.
___________________________________________________________________
(page generated 2023-07-08 23:00 UTC)