Live data from Hacker News

Code doesn’t have to be a mess

danielsieger.com

81–90 of 190 posts

Re: Code doesn’t have to be a mess

#81
post #32

Earlier quoted context omitted.

There ought to be a Zen lesson hidden here somewhere. Perhaps tech companies could have kickoffs/workshops where the participants would create sand mandalas together?

Yes, this is more practical than anyone might imagine. The guy who just poured the concreted for a foundation, does he care that much that it's torn up or not use? Probably not, even though he's likely skilled and professional. We are far too precious.

I know for a fact that a lot of people who build real things take pride in seeing them in use and still around many years later. I think they'd absolutely be demoralized if the typical case saw their work torn up and discarded without ever being used.

Re: Code doesn’t have to be a mess

#83
post #51

Earlier quoted context omitted.

I'm not a junior dev and I still get peeved when my time is wasted. I guess I would only not care if I didn't care about what I was working on, but that's a different kind of existential torment haha. Beyond opportunity cost, you can think of it as deleterious to your performance. If 10% of your work never gets merged because of shifting priorities, compared with someone else who has miraculously dodged these problem…

> that's pretty unfair. Hilarious. I wonder what a plumber or carpenter would say if you were to complain to them on how unfair your job is, because 10% of your output doesn't show in the finished product, yet you are still paid for that output. Imagining the reaction to that just made my day.

The enormous silliness of this argument doesn't seem to stop it from popping up all over the place. People's expectations are relative to their environment. The large majority of things you might think to complain about in your life would look hilarious to a caveman or a medieval peasant or even someone from 1980. Similarly, the vast majority of HN users are extremely high-percentile for global wealth and income: this would be a very boring place if people bought in to your paralyzing insistence that you can't ever discuss improvements to something because problems larger than it exist somewhere in the world.

It's a worldview that's so nonsensical that it's its own reductio ad absurdum: If a fast-food worker complained about wanting to be treated with dignity at work, would you similarly scoff at them because coal miners or sweatshop workers don't even get physical safety?

Having high standards is a _good_ thing. It's the hallmark of society's progress. It doesn't preclude being grateful for the privileges you do have, and it's nothing to be ashamed of unless your self-esteem is so low that you think you don't deserve to be treated well.

Re: Code doesn’t have to be a mess

#84

Earlier quoted context omitted.

I'm a big fan of the "IO Sandwich". This is where you keep complex computation as pure functions as much as possible. And push the IO to the edges of the system. So you might have read-compute-write. This keeps the computation functions testable and composable.

In probably my favorite software-related talk[1] (certainly the one I most frequently share), this is referenced as “functional core, imperative shell”. 1: https://www.destroyallsoftware.com/talks/boundaries

Does anyone know of a transcript of this talk? There is a link on the YouTube copy of the video, but it seems to be dead.

Re: Code doesn’t have to be a mess

#85
post #15
post #7

Earlier quoted context omitted.

I love unit tests, but admit I have absolutely seen unnecessary complexity including complete classes and namespaces solely to enable testability in many cases. It's a justifiable trade off for me, but I don't pretend that unit testing reduces complexity.

I think it is of at least slight interest to some who missed it, to bring back this thread from 2018, about Oracle code (I too once worked on it so I immediately saved that comment link when it was posted): https://news.ycombinator.com/item?id=18442941

I'm not sure if you're saying so, but those are not unit tests.

Re: Code doesn’t have to be a mess

#86
post #8

Ah the Unix philosophy. `man ssh' gives `ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] destina…

Never mind ssh(1), ls(1) pretty much uses all of [A-Za-z] as its options plus -1, but still no -0 option. What I'm personally really looking forward for is -2 option, whatever it would do.

Re: Code doesn’t have to be a mess

#87

In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstraction is necessary. I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. One of the first things I do when I study a new codebase is find a…

>>People abstract before an abstraction is necessary.

This!

Re: Code doesn’t have to be a mess

#89
In the real world you can't (and shouldn't) always say no to evolving and added functionality, nor can you always make unanticipated changes in the cleanest way given project deadlines.

The real solution is to recognize when new features are slower and messier to implement than they should be (because the evolving requirements have outgrown your original design), and periodically take the time to refactor to clean things up.

Re: Code doesn’t have to be a mess

#90
post #71
post #57

Earlier quoted context omitted.

Try to direct your personal energy away from getting your code into the product and towards making the best product possible. Often after building a feature it is obvious that it makes the product worse. I've had many such features cut.

My irritation comes from that decision/realization happening after we already devoted engineering time to something--the most expensive time to reverse yourself.

I've hit this many times over the last 20+ years, and have come to recognize/accept that most people can not really grok something until they can 'use' it in some capacity, often with 'real' data.

Clickable wireframes, design sessions, mockups, etc - they can all help explore ideas before code, and potentially save things. I've had numerous examples where I can identify "this is confusing" or "this doesn't solve the problem, just moves it around a bit" and I'm usually 'outvoted' by others, and do the work. It's usually only after it's in peoples' hands that they identify the rough edges (or more).

Post reply on HN