Hacker News Reader

Comment by Pannoniae | Hacker News Reader

But if all code looks like the same homogenized paste, then all expressivity from code is lost. Which is fine if you want to write the 68th CRUD app with developers who don't want to work on it, but seriously, it does wonders to productivity when everyone enjoys the tools they work with and the work itself. Forcing everyone to satisfy tools/code reviewers just kills all the joy from programming, so you get everyone to be mediocre.

View on HN

But if all pipework looks like the same homogenized paste, then all expressivity from plumbing is lost. Which is fine if you want to install the 68th kitchen sink with plumbers who don't want to work on it, but seriously, it does wonders to productivity when everyone enjoys the tools they work with and the work itself. Forcing everyone to satisfy standards/inspectors just kills all the joy from plumbing, so you get everyone to be mediocre.

Before code review:

    // fires the missiles. 
    // Spongebob case (and extra underscores) makes it hard to accidentally type.
    void FiRE___MIsSiLeS();  // !!!!
    // be careful!
    void fire_missives(); // posts a witty tweet

After code review:

    void fire_missiles(); // fires the missiles
    void fire_missives(); // posts a witty tweet

Code is more uniform, zero downsides!

...until someone has to work on someone else's overly clever "masterpiece". It's not so black and white and a tricky thing to get right and almost impossible to satisfy everyone's needs.

In an ideal world, developers care more about how their program works more than how it is written. But ya, unfortunately most people are working on applications they don't care about, so they get overly creative with code and tools.

Almost always, the "overly clever "masterpiece"" is unreadable because there is no proper documentation, not because the program itself is horrible. If you can't understand it because the writer didn't document it properly, shout at them for the lack of documentation, not for the unorthodox code style....

I'm not saying not to document nor did I say that the program itself is inherently horrible. Often we're working on one problem which will having us jumping into a function we've never seen before. If I have suddenly switch context to read a bunch of documentation to understand someone's "creative" coding style, I will not be happy. Agree to disagree, it seems!

Workaday code should be documented so another developer can skim it in n minutes rather than spend n3 close-reading it.

If workaday code needs documentation for other developers to understand it to begin with, it needs a rewrite. Even if it runs great as code, people aren't computers and it needs to communicate it's purpose to both. Finding a showstopping bug under pressure in code like that is enough to make you want to put pencils though your eyes.

I really like the term "workday code". I always struggle for a concise term to use for this and now I have one! Thanks :)

Also, agreed on documentation though I didn't feel like diving into that one in my response.

you misread workaday

I don't think I did but I wouldn't know since you neglected to explain how.

EDIT: Ohhhh I see now :)

I googled it but didn't really see anything obvious -- what is "workaday code"?

Not your side project.

Others also seem confused— it clearly wasn't the best wording. Maybe the usage is more common in my regional dialect or something.

'Workaday' technically has two definitions: the first is something work related, and the second is something ordinary, common, or routine. Both definitions carry connotations of the other though. In this context, I'm referring to the everyday code that we write to solve most problems. I'd juxtapose this with unusual code working around really weird constraints or making up for a fundamental shortcoming or bug in a language or critical library which might require janky counterintuitive code.

I do think this is a real consideration. In my view, the best case is that the code is as boring as possible, in service to an exciting project. Or to flip it around, I think the desire to find enjoyment in the code itself is more pronounced when working on boring projects.

Reply on news.ycombinator.com