Hacker News Reader

Comment by cjonas | Hacker News Reader

I work as a "consultant", building cloud based business software. Above all else, my job is to deliver value. Something I constantly struggle with is "clean code" vs just pumping out a mostly static transaction script and moving on.

More and more, I write code I'd almost be embarrassed for colleagues to review. But for the type of work I'm doing (poorly defined, highly volatile, potentially short lifespan), I can't justify anything more.

It doesn't feel good and it's still hard to accept that I'm doing the right thing.

If the language I'm working in supported FP, then my world would be much better.

View on HN

I've exactly the same problem with perfectionism. It's not what the industry wants.

And I mean anywhere: "If the language I'm working in supported FP, then my world would be much better" :) I've seen the fuckups that are possible in FP, and indeed worked with a guy who used it to make things as complex as possible. You can really produce nasty code because of it's much-touted compositionality in the hands of a dickhead can generate horrors. Map within a map composed with a reduce composed with... in one statement.

Add in statelessness, which can complicate things in some cases, if said prat pushes statelessness due to the latest blog article he read, it can get worse.

From memory: "against stupidity the gods themselves struggle in vain".

Nice quote from Friedrich Schiller. When I searched it from curiosity, I found another statement by him that seemed appropriate for the topic at hand:

"He who considers too much will perform little."

> "He who considers too much will perform little."

The perfectionist's curse? I have to say there's a core of truth to that! Analysis paralysis IOW.

This is why procrastination is more widespread in high IQ individuals.

I recently built a system under very changing directions. I put all my calls into a single controller, so there were some tens of methods in the single controller.

It felt nasty, it felt ugly, but when time came to actually keep up the desired functionality, put a break and comb the system, it was great to have a single place from where to extract common functionality from. At this point, it was obvious what functionality needed extraction.

This is exactly the attitude we need. Make it work, make it right, make it fast. In that order.

It's sad that too many people are so afraid of technical debt that they demand perfection at first try. At their first try, they don't even know what perfection is.

I've been doing Go for a while now, and more and more I find myself just writing out really dumb looking code. Add a new line, write another short-lived variable, treat the guy reading it - me - like he's a complete idiot. I don't work in a team at the moment, but what I do now is the groundwork for something that will likely be used for the next decade (UI work, back / front-end).

I also write the most dumb and simple code and if it works, then great, I don't touch it until it needs to be optimized or more likely: removed.

Sometimes I don't really know what I'm doing, just getting all tests to pass. Then once it's working, when I know why it works, I will clean it up by removing unnecessary variables, double negations, and name the magic numbers, etc, and try to make it as simple as possible.

> really dumb looking code

You cannot imagine how I'd value having really dumb looking code in my life.

Yet here I am, swimming in a swap of cleverness that I can't refactor nor will ever be able to wrap my head around.

I envy you.

Both "dumb" and abstracted code can be hard to read and change. The most important part is consistency.

It is generally easier to write dumb code that is consistent. It requires less mental energy and is often a very good starting point for refactoring into something more declarative and DRY.

The pain comes from inconsistent code, often either based on wrong previous assumptions, premature optimization or time pressure.

Clear and concise isn't dumb. It's more readable and maintainable. The dumb code is the clever code that no one understands and requires weeks of effort to do, and to understand, no more than what the clear and concise code does.

> poorly defined, highly volatile, potentially short lifespan

This. This is the reality of software development, especially in a startup. You have to quickly adapt your code to the <not well defined> client's needs and to the business constraints, because if there is no cash, the company wouldn't exist anyway.

You can't do that with "perfect" code.

> You have to quickly adapt your code ... You can't do that with "perfect" code

Actually, I would say that the exact opposite is true: only perfect code is perfectly adaptable. The times I want to yell at my past self are the times that he wrote something quick and dirty that I now have to rewrite because the requirements have changed.

>If the language I'm working in supported FP, then my world would be much better.

Assuming FP means functional programming and not function pointers, what language these days doesn't support functional programming?? Are you coding in AWK? Seriously almost every language but C supports higher order functions, anonymous functions, and recursion (though recursion is an anti-pattern and iteration is superior).

Reply on news.ycombinator.com