Hacker News Reader

Comment by gedrap | Hacker News Reader

Extremely disappointed in this post to the point where I believe that the only reason people upvote this is because it's written by Kent. A lot of it reads just like motivational instagram posts. For example:

> Call your shot. Before you run code, predict out loud exactly what will happen.

M, okay, but what exactly do you mean by that? Or even poetic, kind of:

> Rhythm. Waiting until the right moment preserves energy and avoids clutter. Act with intensity when the time comes to act.

I have no doubt that each point has some very specific examples behind them and knowing them could actually be useful. But right now, you can only guess what was intended behind these #deep thoughts.

View on HN

True, they are a bit vague (particularly the one on "Multiple scales"). But a couple of them articulate my experiences better than I could. I think some of the overlooked value of things like this is having a short phrase to encapsulate those principles for your own use.

In particular:

> Rhythm. Waiting until the right moment preserves energy and avoids clutter. Act with intensity when the time comes to act.

I've sometimes gotten bogged down in trying to pull off a major refactor or internal initiative that I had to abandon because it was at the wrong time. It's important to wait for the surrounding social context/business context/preliminary work to be in place before making a major change.

EDIT: to complete a thought.

> > Call your shot. Before you run code, predict out loud exactly what will happen.

> M, okay, but what exactly do you mean by that?

I frequently do a variant of this, although not always out loud. One way to debug a problem is to randomly vary various bits of the program until the problem no longer appears. Another way to debug a problem is to use the scientific method: develop hypotheses, then test those hypotheses with an experiment. I think he's saying to develop hypotheses, and then run code to test them.

edit: https://news.ycombinator.com/item?id=11859090

I routinely use the "scientific method" to debug. But usually by then it's too late: the code is too hard to reason about so I have to treat it like a blackbox and "observe" its "responses" to the "stimuli" I'm changing.

The Rhythm one baffled me as well. I've been coding for 15 years and this bullet was one I couldn't find something to relate to or guess at its meaning.

Maybe it was more of a business aspect/market timing for a new product?

Probably refers to prioritizing the order in which you complete things.

The way I interpret this is: when you work at a company with a fair size, you have to work with the release schedule of the whole company. If you have a large change you want to push (such as a breaking change in a widely used internal library), timing is very important.

You will sometimes need to work very fast in order to push your change while everything else does not change much. In these cases, it's important to be able to enter crunch mode, and it's equally important to alternate crunch modes with slower paced work to not burn out.

At least, that's how I see it...

I remember writing an essay like this for an assignment. The professor called it 'strange'. Even if I had made some valid points, there was no way to validate them as it lacked real flow. Just bullet points with messages I wanted to communicate but with no real value on their own (and some symbolic paragraphs in between). Good to see a post calling out the naked emperor. The same post had received a better reaction in the comments the last time.

The best way to be a better programmer is to keep motivated, overcome roadblocks, ask the tough questions, and envision the final product. Its that easy.

Reply on news.ycombinator.com