[HN Gopher] Write Dumb Code (2018)
___________________________________________________________________
Write Dumb Code (2018)
Author : dvcoolarun
Score : 46 points
Date : 2024-02-25 19:14 UTC (3 hours ago)
(HTM) web link (matthewrocklin.com)
(TXT) w3m dump (matthewrocklin.com)
| DriftRegion wrote:
| Relevant: https://grugbrain.dev/
| DriftRegion wrote:
| I have a nit with this concept being called "dumb" code. I see
| that term is an ironic rebuttal to clever code. However,
| calling it dumb is misleading.
|
| Readability, composability and elegance in programming are
| always a reaction to trauma caused by the shortcomings of some
| previous system. Therefore I think it is not possible to teach
| new programmers to write it.
|
| I think this trauma is the most fundamental force in
| organizational coding standards as well as programming language
| design.
| dang wrote:
| Discussed at the time:
|
| _Write dumb code_ -
| https://news.ycombinator.com/item?id=16257270 - Jan 2018 (66
| comments)
| antoniojtorres wrote:
| I couldn't write any other type of code if I tried
| doctor_eval wrote:
| Hmm. I always think I'm writing the simplest possible code, and
| yet when I look at it six months later, it's still difficult.
|
| I just last night was trying to remember how a PKCE client
| works by looking at my previous implementation. It's not
| simple. This morning I was thinking, there must be a simpler
| way. And yet...
| GMoromisato wrote:
| This advice boils down to "write good code." Unfortunately,
| practical advice that goes beyond that is really hard.
|
| Software engineering is hard because everything is a trade off!
| Should I add another layer of abstraction or just add another
| optional parameter? Should I add flexibility for future
| requirements or simplify the code so it's obvious to a junior
| programmer?
|
| The answer to almost every question is, "It depends!"
|
| What are the skills of the dev team? How much time do you have?
| Do you already have a lot of tech debt? Are you building a
| prototype or a safety-critical system?
|
| Worse, many answers depend on unknowable facts: How will
| requirements change in the future? Will we ever need this
| functionality? Did we bet on the right ecosystem?
|
| The best software engineers can balance all these questions, even
| the ones they don't have answers to, and come up with a design
| that works. The fact that we, as an industry, can build multi-
| million-line programs is a minor miracle. The wonder isn't that
| so many projects fail but that any succeed.
|
| If anyone were to ask me for advice--which I notice they're not--
| I would just say two things:
|
| 1. Write lots of programs.
|
| 2. Work with good software engineers.
| whstl wrote:
| What you're saying about everything being a trade off really
| resonates with me.
|
| I don't think I really "grasped" software engineering until a
| more experienced friend told me, a couple decades ago, that
| every abstraction is also has trade offs and hidden costs.
|
| To me it seemed ludicrous, since abstractions were "obviously
| good", but ruminating on that and observing closely the code I
| was maintaining taught me that it was true. Everything is
| indeed a trade off...
| geophph wrote:
| Reminds me of this quote attributable to Kent Beck
|
| "first you learn the value of abstraction, then you learn the
| cost of abstraction, then you're ready to engineer"
| GMoromisato wrote:
| Dr. Gregory House's motto is "Everybody lies."
|
| My fantasy is to create a hit TV series about an
| engineering firm and the motto is "Everything's a trade-
| off."
| screenoridesagb wrote:
| And yet you see hundreds of people on this site seriously
| advocating stuff that has zero relevance or utility. Haskell,
| Perl these are languages that WILL make so the vast majority of
| developers will never touch it and yet here we are writing "I'm
| so smart I knew to use Haskell" code just so intern 8 months
| later will steamroll with ChatGPT generated Python that people
| will actually read.
| lubutu wrote:
| I mean, learning Haskell has made me a better programmer even
| if I've never used it at work.
|
| Perl I have used. I wouldn't say the same about that...
| thesnide wrote:
| Perl is the canonical example of "less is sometimes
| better".
|
| I love coding in Perl. But it seems that everyone uses a
| disjoined subset of it, which makes collaboration awkward.
|
| And, if C let you shoot yourself in the foot, C++ give you
| a shotgun to do so.. Perl gives you a timed nuclear device.
| ay wrote:
| Perl (without dependencies) works awesomely well as a
| replacement for bash in scripts, in my experience. Unlike
| Python, chances that it will break the next month (or the
| next decade) are virtually nil.
| XorNot wrote:
| Python without dependencies will also work everywhere
| basically forever. Hell, most Python 2 is valid Python 3,
| but it's been over a decade now - Python 3 is the default
| system Python in most everything.
| charlie0 wrote:
| Being able to list different solutions and their tradeoffs is a
| true mark of seniority.
| jayd16 wrote:
| I really don't see how it's just "write good code." In fact the
| opening line is about removing code being better than writing
| more.
|
| Maybe it boils down to KISS but IMO it goes deeper than that.
| The lesson that code is a liability not an asset is not
| represented in either "be good" or "be simple."
| GMoromisato wrote:
| Maybe you're right. Obviously, if this advice helps people,
| then I should just back off.
|
| It's true that removing code is better than adding it, and
| that code is a liability. And I admit that I needed to hear
| that early in my career.
|
| But the article acknowledges that "over-adherence to [that]
| dogma can be counter productive". Great--so how can I tell if
| I've gone too far? How do I know if I should write more code
| or less code? How do I know if my code is "dumb" enough? The
| article does not help with that.
|
| Saying that "code is a liability" is not actionable advice.
|
| Edit: In contrast, I found this article full of actionable
| advice: https://tidyfirst.substack.com/p/mastering-
| programming
| okamiueru wrote:
| Then, there are a lot of programmers who are completely unaware
| of these tradeoffs, and simply follow some trend or methodology
| without any thought of their own. 20 lines of code split over 4
| microservices? Sure, why not? "It's supposed to make
| development more flexible and improve the developer
| experience". Cherish coworkers who actually care about their
| craft, not all shops have them.
| overgard wrote:
| > This advice boils down to "write good code." Unfortunately,
| practical advice that goes beyond that is really hard.
|
| I don't think that's true. I think a better way to phrase it is
| "avoid being clever if you don't need to be." Sure, you _could_
| write that algorithm as three nested list comprehensions, but
| does that accomplish anything other than showing off? Do you
| really need that metaprogramming or would a simple function
| suffice? The worst code I 've ever had to deal with was never
| written by juniors, it was written by guys that knew fancy
| template metaprogramming in C++ and would create a nightmare
| for everyone else to deal with because they wanted to show how
| smart they were.
| from-nibly wrote:
| > We should not seek to build software. Software is the currency
| that we pay to solve problems, which is our actual goal. We
| should endeavor to build as little software as possible to solve
| our problems.
|
| _Slow clap_
| hawski wrote:
| I think it is better to have a little "smarter" code if that
| means you will not bring a dependency. For example in Python or C
| I like things that do not need anything except the standard
| library. When you need to think about PIP or compilation of
| another library it is more code shifted to things that usually
| suck (like build systems) or you lose control and when something
| breaks you are still to blame. Sometimes it means to use
| something that is a bit more complex in comparison to using some
| nice libraries. Maybe the thing is that the library is not a dumb
| code anymore?
| XorNot wrote:
| Conversely, your efforts to _not_ bring in a dependency are
| being paid for in code you have to write and test and hope
| doesn 't trip over a more fundamental security flaw or exploit
| somewhere. If you have problems they're now bespoke, there's no
| userbase of knowledge out there.
|
| And there's a big difference between going from ZERO
| dependencies, to 1. Because once you've got 1, the complexity
| cost has been mostly paid already so your efforts not to bring
| in other dependencies are going to be marginal.
|
| So the question is, are you really saving time or complexity by
| avoiding the dependency management process, or just wasting it
| deferring something you'll already have to do later? It is wise
| to constantly reproduce the same common code across multiple
| bits of software, rather then write it as your own library
| anyway (at which point you'll be inheriting a dependency
| management process as well, even if it's only internal).
| ljosifov wrote:
| Write boring code. Dumb code - that's too much, no need for.
| Boring is just right. Steve Maguire's "Writing Solid Code" is the
| rare book that is both practical and abstract in the right
| amounts. With time passing, it looks to me that boring, obvious
| is close enough to solid.
| alganet wrote:
| That's a neat idea. Do something simple, easy to understand.
| Can't go wrong, right? No chance of complexity sneaking in all
| sorts of ways.
|
| I wonder if someone had this idea before.
| yawboakye wrote:
| while i agree that simple is better than complex, there is no
| absolute measurement nor definition for what simple is. and
| typically complex structures/foundations are what we build simple
| on top of. if our medium of expression isn't already complex
| enough, we risk accidental complexity.
|
| compare:
|
| _sapienti pauca_ , a compact latin sentence which takes
| advantage of the complexity of latin grammar to say what may be
| translated into english as 'a word to the wise is enough.'
| there's some poetic beauty in the latin sentence that adds to the
| force of the advice (it's only two words after all). i don't
| think we should avoid pithy expressions where the celebrate
| wonderful achievements (eg recursion) all in the name of sparing
| our audience some pain. no, write that compact code, please.
| we're happy to spend time learning just as we've spent time
| learning and appreciating the works of masters of other fields.
___________________________________________________________________
(page generated 2024-02-25 23:00 UTC)