Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code doesn’t have to be a mess

danielsieger.com

Post reply on HN
Print view View original

91–100 of 190 posts

Re: Code doesn’t have to be a mess

#91

Post by dagss »

camgunz wrote: post #51
korijn wrote: post #41

Earlier quoted context omitted.

Being married to your code/output is just another flaw typical for juniors. Put them on features that aren't critical or ensure they are made aware up front that their work may be rejected if it doesn't meet design expectations.

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…

If only 10% of your work is thrown away consider yourself very lucky, I would think of that would be a minimum number in the industry...

Myself I not too long ago did a 6 month crunch with the rest of my team on a product that was cancelled right before launch...

Re: Code doesn’t have to be a mess

#92

Post by commandlinefan »

ape4 wrote: 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…

I can top that: `man read` gives:

BASH_BUILTINS(1) General Commands Manual BASH_BUILTINS(1)

NAME bash, :, ., [, alias, bg, bind, break, builtin, caller, cd, command, compgen, complete, compopt, continue, declare, dirs, disown, echo, enable, eval, exec, exit, export, false, fc, fg, getopts, hash, help, history, jobs, kill, let, local, logout, mapfile, popd, printf, pushd, pwd, read, readonly, return, set, shift, shopt, source, suspend, test, times, trap, true, type, typeset, ulimit, umask, unalias, unset, wait - bash built-in commands, see bash(1)

Re: Code doesn’t have to be a mess

#93

Post by kristov »

wefarrell wrote: post #75

Personally I think the most important thing to minimizing code complexity is ensuring that it understandably maps to the business logic. The business logic is the essential complexity and everything else can be seen as waste. The first step is getting the lexicon right. Frequently the business lexicon is ambiguous in such a pervasive way that the people immersed in the business aren't aware of the discrepancies. For…

I agree. As a dev in a pretty large organization, I have seen the knowledge of business logic dissapate as the org grew, with some churn. To the point now where very few people actually know how the current system works, let alone how it is supposed to work. This means the only concrete definition of "this is what the system is supposed to do" is only in the code. The organization is disorganized, and the code is only as good as the level of organization outside the code - so very poor. All this gotme thinking about what does it mean exactly to be organized? We call companies "organizations" because they are groups of people getting together and organizing. If the organization is not organized the code (or any other artifact it produces) will also be poorly organized. Organizing is sorting, classifying, grouping, communicating etc.

Re: Code doesn’t have to be a mess

#94

Post by nosianu »

idontwantthis wrote: post #85
nosianu wrote: post #15

Earlier quoted context omitted.

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.

Yes it is about tests in general. I think it fits the discussion and many comments very well, this does not really seem to be about only unit tests specifically. Many comments are more general in tone.

The very comment at the top of this sub-thread does not seem to limit itself to the subject of unit tests.

Re: Code doesn’t have to be a mess

#95

Post by biorach »

dannyobrien wrote: post #23
ape4 wrote: 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…

Wasn't the "Unix philosophy" explicitly formulated by Rob Kernighan in 1983 in opposition to this kind of growth? I mean, there's a whole website of Unix purists named after it: 'UNIX Style, or cat -v Considered Harmful' http://harmful.cat-v.org/cat-v/

The Unix philosophy is to do one thing and do it well. The ssh command wraps the large and complicated ssh protocol - I would say it does one complicated job and does it well.

Re: Code doesn’t have to be a mess

#96

Post by scrapheap »

light_hue_1 wrote: post #28

> Minimize Dependencies ... Consider doing it yourself. This is terrible advice! Maximize your dependencies. Adopt as much external code as possible. Build what you can with it. Then, as you reach the limits of those dependencies, and you absolutely understand what needs to get done replace them as you need to. The vast majority of what people write will be trashed and/or changed radically. You should adopt whatever…

Honestly, I think you're both wrong. You shouldn't be trying to minimize or maximize your use of dependencies. You should add a dependency when it makes sense and write your own code when it makes sense.

Doing more complex time and date work, then a good solid library for manipulating datetime variables will save your sanity. Need to right justify a string to set length then using a leftpad will leave you at the mercy of a random author on npm.

Re: Code doesn’t have to be a mess

#97

Post by alphanumeric0 »

samsquire wrote: post #33

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…

> 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.

I genuinely can't tell if you're being serious or not. If you are, do you also like to read books written as one giant chapter? Or entire chapters as one giant paragraph?

Re: Code doesn’t have to be a mess

#98

Post by wefarrell »

kristov wrote: post #93
wefarrell wrote: post #75

Personally I think the most important thing to minimizing code complexity is ensuring that it understandably maps to the business logic. The business logic is the essential complexity and everything else can be seen as waste. The first step is getting the lexicon right. Frequently the business lexicon is ambiguous in such a pervasive way that the people immersed in the business aren't aware of the discrepancies. For…

I agree. As a dev in a pretty large organization, I have seen the knowledge of business logic dissapate as the org grew, with some churn. To the point now where very few people actually know how the current system works, let alone how it is supposed to work. This means the only concrete definition of "this is what the system is supposed to do" is only in the code. The organization is disorganized, and the code is onl…

Oh god you just brought back a memory from when I was brought in to manage a team at a dysfunctional organization and I was trying to figure out how a complex service was supposed to work. I asked: "Do you have any documentation or requirements", I was told "The code is the requirements", to which I responded "Wonderful that means there can't ever be bugs because there will never be a discrepancy between the code and requirements".

Getting requirements in writing was an uphill battle and the lack of requirements always wound up screwing over the developers because there was no contract to prevent scope creep and the developers were the ones that were held accountable for misunderstood features and missed deadlines. As a result everything was constantly rushed and not well thought out. It took me a long time to convince my boss that the issue stemmed from unwritten requirements and a lack of planning.

Re: Code doesn’t have to be a mess

#99

Post by traeregan »

twawaaay wrote: post #69

I think this is terrific advice. Over decades I have compiled my own list which contains all these and bunch of other behaviours that are needed for successful project. I would add one or two very important thing missing from the list. One, not explicitly mentioned but covered in other points is to plan for simplicity . Make simplicity an explicit goal of the project and set up process to remind of it at various impo…

Any chance that your list is organized in a way that you wouldn't mind sharing it? I've been on a documenting spree the past few years at work (after ~14 years of not documenting much), and it would be great to see your decades-long process notes. I totally understand if that's your secret sauce and you'd prefer to keep it that way though.

Re: Code doesn’t have to be a mess

#100

Post by dsieger »

idontwantthis wrote: post #3
dsieger wrote: post #2

Would be curious to know what strategies other people apply in order to keep complexity down over time!

Unit Tests. If you can't write a unit test for it, it's too complicated and it's going to snowball quickly into a giant mess.

Absolutely! For me, comprehensive testing is key to keep things clean over time. Not sure why this didn't come to my mind when writing the article. I think I was somehow assuming that this is a necessary pre-condition anyway.
Post reply on HN