[HN Gopher] Good code is like a love letter to the next develope...
___________________________________________________________________
Good code is like a love letter to the next developer who will
maintain it
Author : feross
Score : 102 points
Date : 2023-07-20 21:32 UTC (1 hours ago)
(HTM) web link (addyosmani.com)
(TXT) w3m dump (addyosmani.com)
| aye01 wrote:
| fuck the guy after me. I write good code for my own sanity and so
| my OCD doesn't make me want to refactor it all later. it's like
| saying save the trees for your grandchildren or the future
| generations. fuck them, I want a clean environment for myself
| gosh darn it!!
| nashashmi wrote:
| The next developer ruins your code like new twitter runs old
| twitter or new arrogant engineer overwrites old humble
| engineering.
| rpastuszak wrote:
| 1) "Code sober, debug drunk"
|
| It's harder to read the code than to write it so if you can
| barely comprehend the thing you just wrote, you probably won't
| understand it in the future: https://sonnet.io/posts/code-sober-
| debug-drunk/
|
| 2) I think it's more like speaking with ghosts (including a
| spoiler for The Sixth Sense):
|
| https://sonnet.io/posts/emotive-conjugation/
| majikandy wrote:
| >it's harder to read code that to write it
|
| Isn't this only true of bad code? Good code is almost certainly
| the other way round, harder to write than read... just like a
| really good book was much harder for the author than it was for
| you, the reader.
| ugh123 wrote:
| Meh. I've seen teams and projects bogged down by "good clean
| code" rules and nit picking code reviewers. These folks,
| typically "staff" engineers, over-police the repos and care more
| about clean code than delivery and execution.
|
| I'm waiting for the day where AI/co-pilots can enforce team and
| industry best-practices, style, maintainability, testability, etc
| _before_ the code is even committed.
|
| Call it "uber-linting" and _get rid of code reviews_.
| ModernMech wrote:
| Plot twist: that next developer is you. Love yourself!
| malikNF wrote:
| I prefer the quote that goes
|
| "Always code as if the guy who ends up maintaining your code will
| be a violent psychopath who knows where you live."
| majikandy wrote:
| This. I was about to mention the same quote. This quote alone
| has served me well over the years. Sounds jokey but if you live
| by this, it's brilliant.
| mellosouls wrote:
| This blog entry is a much nicer and more graceful version of the
| old adage about writing your code like the next guy is a
| psychopath who knows where you live...
| anon7331 wrote:
| It's a very nice way to imagine good code. More likely, someone
| inexperienced or less caring will come along and edit it just
| enough to turn it into mediocre code and no one will care
| anymore.
| loph wrote:
| Truth.
|
| Years ago a wise man told me "The compiler is not your customer.
| The next person who maintains this code is your customer. It
| might be you."
| m00x wrote:
| The customer is the one using your product, not the one
| maintaining your code.
| NetOpWibby wrote:
| Precisely why I also create READMEs in top-level directories. I'm
| not going to remember how to structure queries for my API a year
| from now.
|
| Future me will always appreciate how considerate present me was.
| imoverclocked wrote:
| As someone who has gone back and read my old code as well as a
| lot of others old code, there is no such thing as good code.
| IMHO, the problem is one of cultural context which is often not
| shared between generations of coders. Languages and best
| practices can change so violently that best-practices one decade
| are often anti-patterns in the next.
|
| As a codebase outlives its best-practices, do you stick with them
| and extend with those same anti-patterns or do you implement new
| things with a different mindset than the rest of the code?
| -- If you break with tradition then you are making it harder to
| understand the codebase as a whole. eg: why do we have a
| mix of procedural/OO/functional/... methodologies with spaghetti
| code at the core? -- If you refactor everything then
| you are definitely breaking something. eg: you have a 10M+
| line java codebase with transformations bringing you into the
| 2020s from coders who originally knew C and Java 1.4.
| -- If you keep with tradition then are you writing the best code
| possible? eg: would you willingly use goto of some variant
| in new code if you jumped into a Cobol 74 codebase?
|
| I think what the article really wants to talk about is "clear"
| code or "understandable" code and not "good" code.
| woooooo wrote:
| Style changes over time, but factoring is evergreen.
|
| Something could be written using Java 1.4 idioms with good
| organization and factoring, or using the latest functional
| hoohas with everything all mashed together. Or the inverse, of
| course.
|
| If the structure of the code matches the structure of the
| problem, the implementation style is a much smaller deal.
| munificent wrote:
| I think about this all the time when it comes to evolving
| systems. I work on a programming language, and these tensions
| are core to my job. In the context of a language, I think it
| can be:
|
| * Modern, where the language's features and idioms reflect the
| best way we know to write good, clean code today.
|
| * Compatible, where code written in the language years ago
| continues to run the same as when first written.
|
| * Simple, where the language has relatively few concepts that
| compose in clean ways and where there are few ways to
| accomplish the same goal.
|
| But you only get to pick two.
| 38 wrote:
| > there is no such thing as good code
|
| definitely not true. this is good code:
|
| https://github.com/torvalds/linux/blob/master/fs/file.c
|
| this is good code:
|
| https://github.com/golang/go/blob/master/src/strconv/atoc.go
|
| its formatted, commented, direct. the fact that you struggle
| with writing time tested code does not mean that everyone does.
| Attummm wrote:
| And remember, the next maintainer could very well be you.
| SaintGhurka wrote:
| Or it could be a homicidal maniac.
| Gabriel_Martin wrote:
| Or both, depending on how readable it is
| dasil003 wrote:
| Yeah, it's humbling enough when you are reviewing some old code
| and thinking "what idiot wrote this" only to git blame and
| realize it was you. What's even more jarring when you find some
| code, surprised the capability/feature even exists, then git
| blame and realize again it was you (this time hopefully with a
| pat on your own back because of how well it's written). Yes
| this has happened to me.
| JohnFen wrote:
| All of the code I wrote more than a year or two before the
| time I look at it strikes me as being embarrassing. I hope
| this is always true, because I think it says that I have
| grown as a programmer over that time.
| roflyear wrote:
| I recently had the opposite experience: encountered some code
| from 2017(!!!) that was really solid. Few "silly" things but
| the important stuff was there.
|
| I realized that when I did that project I "had the time to
| care" which is not the case lately!
| LordDragonfang wrote:
| Nothing beats the feeling of having a coworker suggest what
| might be a substantial change to a codebase you haven't
| touched in months, only for you to look at the code and
| realize that the way you wrote it makes it a one- or two-line
| change.
| jedberg wrote:
| When I do personal projects for myself, I try to comment them
| really well for this exact reason.
|
| Just today in fact I was trying to update some code I wrote two
| years ago because one of the underlying tools broke. I was very
| happy with past me for commenting the workflow of that tool so
| I could easily work around it.
| majikandy wrote:
| A good alternative is code without comments that communicates
| just as well as that code without the comments. Not
| necessarily better but less likely to slip out of sync with
| the comments upon change.
| Arrath wrote:
| Perfect opening for the classic "well its a good thing I hate
| myself!" joke.
| UnixSchizoid wrote:
| I write shitty code only I understand for job security. This is
| probably why I'm a sysadmin lol.
| mcdonje wrote:
| Most bad code doesn't exist because the writer didn't
| sufficiently love the future maintainers.
| m00x wrote:
| After more than a decade of development, I've come up with this
| mindset:
|
| I don't really care that much about the developer, and care a lot
| more about the users of my product, especially since that
| developer is usually me.
|
| If I'm unsure of the value I'm adding, or if the ability to do
| something is greater than its quality, I will take shortcuts if
| needed.
|
| If the codepath is critical, or if doing so is dangerous, I will
| take my time on the quality and the foolproofness. I will be
| pertinacious in this mindset, and if managers try to rush me, I
| will remind them of the consequences of failure and log
| _everything_.
|
| I've seen too many developers (myself included) spending weeks
| and months on perfecting something that's never used, or barely
| used. The latter issue of not spending enough time is a lot more
| rare, but does happen.
| more_corn wrote:
| Good infrastructure is too. I had a colleague deploy the power
| whip for the last available rack position on his way out the
| door.
|
| Years later when I desperately needed that rack to keep the site
| up I was able to roll it in and light it up without waiting
| 6weeks for an electrician change request.
|
| He saved my bacon by thinking ahead. It was a gift he gave me,
| never mentioned and was not around to receive thanks for.
|
| I aspire to be more like him in everything I do.
| commandlinefan wrote:
| As much as bad code irritates me, I'm not quite so quick to blame
| the original maintainer - they may well have wanted, badly, to
| write something better, but been put under artificial (and
| usually meaningless) time pressure that didn't allow it.
| [deleted]
| Smoosh wrote:
| I maintain mainframe systems and very often I would like to
| restructure code to improve it, but the requirement is to make
| the most minimal change that achieves the fix or change
| required. Mostly because the code is 30 years of patches and
| minimal changes which is not well documented and is extremely
| fragile and not well understood.
| hkon wrote:
| Good code is not like art, such as good books or paintings. No
| matter the quality of your code, if the product or service is not
| a good market fit. It will be retired. No one will stumble upon
| it or pick it up after it's gone. Knowing this, the only reason
| for putting effort into it is to make it easier for myself.
| majikandy wrote:
| The two aren't always mutually exclusive, you might be writing
| code for a good market fit that stands the test of time and
| needs maintaining.
|
| The times you appreciate it are actually when you open
| something and it's nice and easy to change and you realise you
| were the one who wrote it. But real developer happiness comes
| when you have the same experience and someone else wrote it.
| mostlylurks wrote:
| > No matter the quality of your code, if the product or service
| is not a good market fit. It will be retired. No one will
| stumble upon it or pick it up after it's gone.
|
| This applies to artistic endevours like books and paintings as
| well (especially those two, since markets for them are very
| oversaturated). Your technique might be masterful, but if your
| art doesn't align with current trends (along with a number of
| other factors), it'll drown in the endless barrage of other
| art, and nobody will stumble upon it or pick it up, even if
| it's still available.
| hirundo wrote:
| So a love letter to myself? Who wrote this crap?!
| `git blame` D'oh!
|
| Just today I found an old spec I wrote that was so completely
| mocked that the code it specified made no difference. I wasn't
| feeling the love.
| xupybd wrote:
| > The beauty of our creations, however, is not judged solely by
| the elegance of our algorithms or the efficiency of our code, but
| by the joy and ease with which others can build upon our work.
|
| Often this is not true. Our creations are judged by the user.
| They don't care how good it is under the hood. They care that it
| works correctly, that it's easy to use and that it's as fast as
| they need it to be.
|
| Your boss should care that it's well written because that should
| mean it's cheaper to maintain. But, they don't look that far into
| the future when evaluating your performance. So, often they only
| care about how fast you did it and how happy the customer is with
| it.
|
| Our industries incentives don't often align with good code.
| [deleted]
| manderson89 wrote:
| Reminds me of the Damian Conway quote "Documentation is a love
| letter that you write to your future self"
| pwdisswordfishc wrote:
| So documentation is only written by narcissists?
| thebruce87m wrote:
| I guess I'm writing hatemail every day.
| ThalesX wrote:
| Sorry next developer, I'm on a tight deadline, used to love this
| craft, now I just do what the product people tell me to get a
| nice paycheck.
| m00x wrote:
| The craft is not the code, but the product.
|
| You can have beautiful code and garbage product, and great code
| and a garbage product.
|
| If your PM is pushing bad products, that's on them. Your job is
| to deliver good product, not good code.
| Arisaka1 wrote:
| Yep. Yesterday I ran into a job opening asking for "Java
| developer who delivers 3x faster than the other developers" in
| one of the bullet points. It's such a weird point to emphasize
| that you want speed with no concern to trade-offs, and the
| maintainability and scalability of the codebase will be the
| first victims sooner or later.
| rpastuszak wrote:
| Sounds like they're looking for a person who'll work 3x
| faster than the rest of the team by taking shortcuts and
| slowing everyone else down.
| mostlylurks wrote:
| There are cases where the tradeoffs don't involve the actual
| codebase. For instance, there are certainly many developers
| who are 3x faster than the average developer simply as the
| result of having enough experience and/or skill to know which
| tools and/or approaches are optimal for a large subset of the
| kinds of problems they encounter in their typical work, such
| as a developer familiar with a particular ecosystem
| accomplishing some task in 10 minutes by knowing which
| library and which function to use, and how, whereas another
| might take hours (or days) to accomplish the same task since
| they have to figure out what tools are even available to
| solve an issue and how to use them, or worse (sometimes),
| rolling their own solution where a library implementing the
| functionality already exists. The tradeoff here is simply
| that it will be harder to find such developers, and they'll
| generally want higher compensation, but their work will not
| degrade the quality of the codebase, quite the opposite.
| BugsJustFindMe wrote:
| My personal experience is that the majority of developers I
| ever encounter at work (as opposed to within my social
| network) are usually slow because they're bad engineers who
| don't understand problems quickly, don't have the knowledge
| or experience to see solutions quickly, and in general don't
| think deeply quickly. It's not hard to 3x performance without
| sacrifices when the baseline is mediocre at best.
|
| "Fast must be cutting corners and not just actually better at
| programming" is a weird fallacy to hang your hat on.
| 3-cheese-sundae wrote:
| There is always a cost to everything.
| BugsJustFindMe wrote:
| > _There is always a cost to everything._
|
| There's a huge cost to having engineers who are bad at
| understanding and solving problems. The cost of having
| people who are good at understanding and solving problems
| is supposed to be that you pay them more, but that's not
| how employment incentive structures work in practice
| because information asymmetry and stigma around talking
| about salaries.
| webdood90 wrote:
| > the majority of developers I ever encounter at work are
| usually slow because they're bad engineers
|
| hm, something about this that I just can't put my thumb on
| screye wrote:
| "Majority of people who drown cannot swim."
| mikepurvis wrote:
| "You'll get to work on a codebase for whom the entire
| development mindset has been 3x-speed-at-all-costs."
|
| Yeah..... pass.
| renox wrote:
| The emphasis on tests made me laugh: I work on a project where
| it's mandated that all the code is covered by Unit Tests. In my
| estimate the time to make UT is 3* the time to create the code.
| And no, nobody use TDD in this project because it takes 3 minutes
| to compile one UT (C++ sigh), so we all do 'post coding' tests.
| While sometimes the UTs do help, they're also a huge burden:
| wants to fix some code? Well you also have to update the UTs..
| swayvil wrote:
| The computer in this metaphor is what, a marital aid?
| beebmam wrote:
| In my opinion, good code is like a Brita filter. It does its job,
| will one day need to be replaced, and it should be easy to
| replace.
|
| More importantly: metaphors are not a healthy way to understand
| an idea. Ideas are more nuanced than a metaphor could possibly
| account for. Abstaining from metaphors might not make for a
| catchy headline though.
| dmbche wrote:
| Little pushback here - metaphors are great tool to understand
| something, and can convey some meaning more efficiently than
| other means.
|
| But "the map is not the territory"!
| themodelplumber wrote:
| The territory isn't the territory either, so no big deal!
| Minor49er wrote:
| Metaphors are also ways of communicating ideas. A good metaphor
| is as simple or as complicated as it needs to be in
| illustrating a new concept
| KarlKode wrote:
| Problems arise as soon as you (ab)use a metaphor (used to
| explain a higher level/adjacent problem) to explain concepts
| it was never meant to model.
|
| Example: Array of items as a shopping cart: how do you
| efficiently remove an item from the array (as you can from a
| shopping cart)?
| inopinatus wrote:
| metaphors are like, herding .. fine old .. elephants .. in
| the air
| xupybd wrote:
| In my opinion, metaphors are like a picture. They can
| communicate vast amounts of information very quickly but can
| have inaccuracies.
|
| You should expect some additional nuance when receiving a
| metaphor.
| inopinatus wrote:
| good code is like vintage wine: you don't recognise the
| packaging, no-one agrees on which aspects exactly make it good,
| and the only person who remembered how it was made retired ten
| years ago
| peteradio wrote:
| Is this supposed to be ironic? Your first sentence was a
| metaphor.
| haswell wrote:
| Why can't good code be all of the above?
|
| Thinking about code this way takes nothing away from
| appropriately deep explorations of nuance.
|
| They coexist without issue.
| dools wrote:
| The headline is a simile.
| bena wrote:
| I think the issue you may have with metaphors is that people
| tend to argue the metaphor rather than engage with the concept.
|
| Arguing the metaphor is pointless, because the metaphor isn't
| the thing, it's just a way to explain an aspect of the thing.
| henning wrote:
| dear future developer, nothing matters and code will still be
| hard to read even if I try my very hardest to make it as good as
| i can. the world is dying and we are doing our best to kill it.
| you having a hard time understanding my code is not really
| anything that can be fixed. it pales in comparison with the
| actual problems the world faces. tough it out or rewrite it.
| sorry
___________________________________________________________________
(page generated 2023-07-20 23:00 UTC)