Hacker News Reader

Comment by 100011_100001 | Hacker News Reader

Reading the comments first I suspected this was an HN over-reaction to the list. However upon reading it myself I must totally agree.

There is nothing actionable about this list. A lot of it is meant to sound wise, without any specifics.

Definition of heuristics:

> A heuristic, or a heuristic technique, is any approach to problem-solving that uses a practical method or various shortcuts in order to produce solutions that may not be optimal but are sufficient given a limited timeframe or deadline.

A small sample of the heuristics from the "evolving list":

> Our only measure of progress is delivering into our customers hands things they find valuable.

> Outcomes matter more than output. A focus on output yields sub-par outcomes.

None of this is practical or a shortcut of any kind. It just "sounds" nice as an abstract idea.

View on HN

> A lot of it is meant to sound wise, without any specifics.

This unfortunately applies to most of the popular advice in our industry. You could argue that "meant to be wise, without any specifics" is a requirement for a meme to get picked up and recognized by a large enough mass of people in order for it to become viral.

Consider if you can apply anything in SOLID in an actionable way. None of it is actionable, except LSP. It's meant to sound wise, without any specifics.

I'm getting misty-eyed over here. Seriously, I thought I was the only one.

I have heard almost no advice that's anywhere near actionable in our industry. The way I see it is that we have no objective ways to even talk about good code versus bad code (and forget all of the support tasks like "can we estimate this"; those require some objective understanding on how terrible the code happens to be).

We've got code smells. Like, the most primitive and "from your gut" sense. This for-loop makes my tummy feel bad.

It all feels like poetry to me.

There are a number of agreed bad practises: long functions, deep nesting, obtuse identifiers, unrestricted use of gotos, global variables, no coding standard, premature optimisation, C macros, raw pointers...

False.

Bryan Cantrill (OS developer who used to work at sun microsystems) talks about how the C macros are great [1].

John Carmack talks about how long functions can be better than short ones [2].

Every piece of advice that I've heard has had a contradiction coming from a preeminent developer.

To be fair, yes, people do agree on bad practices. They are just often wrong. People agreeing that something is true doesn't make it that way.

[1] - I believe that he mentions that here however, I'm not sure. I have heard him mention it in more than one video. https://www.youtube.com/watch?v=LjFM8vw3pbU

[2] - http://number-none.com/blow/john_carmack_on_inlined_code.htm...

Not false.

Sure there are exceptions to most rules, but break them only if you know what you are doing and are able to justify doing so.

I often think there's an equal and opposite other side to that: Don't /make/ any rules unless you know what you are doing and able to justify them (and their scope of effectiveness).

I've recently had to work on a project controlled by someone who's swallowed "clean code" and a couple of C# style guides and now just unthinkingly applies what he thinks he's read. E.g: you are not allowed any comments in this codebase. No variable may be typed. Period.

Both extremes are.. not good.

> there are exceptions to most rules, but break them only if you know what you are doing and are able to justify doing so.

Isn't this exactly the kind of vague advice that GP was talking about?

Perhaps, or perhaps it is a meta-rule, i.e. a rule about rules. Either way it is just obvious common sense IMO.

I remember reading John Carmack's comments a few years back and it kind of broke my coding style because it seemed like I did everything opposite of his suggestions.

I haven't recovered since. For anyone interested, here is my notes summary from various articles and videos from John.

### John Carmack

* Do-always, then inhibit or ignore strategy

* Common pattern for me: get first results with hacky code, then write a brand new and clean implementation with the lessons learned, so they both exist and can be cross checked.

* If a function is only called from a single place, consider inlining it.

* If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that.

* If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters.

* If the work is close to purely functional, with few references to global state, try to make it completely functional.

* Try to use const on both parameters and functions when the function really must be used in multiple places.

* Minimize control flow complexity and "area under ifs", favoring consistent execution paths and times over "optimally" avoiding unnecessary work.

The problem is if you take any actionable idea as law, there is a pendulum swing to the other side to the point that you need a counter actionable idea to reset it.

OOP started like that, as an initial concept it made a lot of sense. Try to force OOP into anything you have a problem. Functional Programming, is the counter to OOP design, but it also has problems.

Same is true to having short functions doing one thing vs abstracting too early. Our industry is filled with counter points.

Even the "recent" shift to microservices, taking to the extreme they create new problems that monoliths didn't have.

...this is one of my biggest struggles as a developer currently, conflicting ideas that all make sense and trying to figure out which one I should apply for a specific piece of code.

I find these actionable as well:

O - "Don't modify, extend instead."

I - "Don't group interfaces into a god object - separate them."

D - "Depend on abstractions not concrete implementations."

S is the most disputed but Uncle Bob occasionally clarifies (paraphrased, again): "Object definitions should be beholden to only one stakeholder group."

SOLID seems actionable enough to me... whereas Holub's article is a bunch of fluffy mothering statements.

>> Outcomes matter more than output. A focus on output yields sub-par outcomes.

But isn't this just stating the obvious, e.g. don't measure success by lines of code written, number of commits, number of bugs fixed...? And there is nothing wrong in stating the obvious, especially as when it is not obvious to some people.

Generally, we get paid by our output (agreed upon deliverables). However, on the other hand, we generally get repeat business by our outcomes (users became much more productive and now they want more).

There's enough nuance required here to fill a small series of books. If you state the obvious and then go on to actually examine the nuance, then I'm fine giving you credit. If you don't then I don't really see the benefit.

Worse, you've given people a thought terminating cliche that can be disastrous in the hands of a novice. "Hey, we're focusing on the outcomes!" Yeah, but you've missed three milestone dates so your funding is going to be pulled and everyone is now unemployed.

"agreed upon deliverables" is one definition of output. I think he is talking more generally, e.g. lines of code, over-long email, unnecessarily verbose documentation, ..., I could go on indefinitely.

But you are really arguing in general against such lists like this, that don't "examine the nuance". But perhaps they are useful discussion point or memory joggers. And shouldn't the senior members of a team or managers explain to novices the importance of meeting such milestones that you mentioned?

> And shouldn't the senior members of a team or managers explain to novices the importance of meeting such milestones that you mentioned?

I basically read the whole list as: "How do be successful? Step 1: Be successful. Step 2: Be successful at purple. etc"

Some of it sort of makes sense. Some of it might as well be gibberish. None of it is useful without a bunch of senior members of a team who have been successful before. And if that's the case, then we can just delete the list and stick with the senior members of the team.

The prefer "outcomes to output" is not a "How do be successful? Step 1: Be successful. Step 2: Be successful at purple". I can see the use of such a list for example on a team wiki as a reminder that you don't get credit for writing a 3 page email when a 6 liner would be as useful.

I can see the use of such a list for example on a team wiki as a reminder of what the team considers good practice.

Reply on news.ycombinator.com