Mastering Programming (2016)

> Multiple scales. Move between scales freely. Maybe this is a design problem, not a testing problem. Maybe it is a people problem, not a technology problem [cheating, this is always true].

The key to this is realizing that once you decide a problem is at a certain scale, the fix needs to be at that scale too. So you might have a data problem, a code problem, a workflow problem, a design problem, an architectural problem, a team problem, a project problem, an organizational problem, a leadership problem, or an existential problem. (on the level of the company)

Each type of problem has to be resolved by the resources on tap at that level. You fix data problems by editing the data. You fix code problems by changing code. You fix leadership problems by changing leaders. You fix existential problems by changing jobs.

Becoming a more effective programmer involves understanding at a deep level how everything interlocks and moves together. If you can't solve it at one level, escalate to the next level and try to solve it there.

So you might have a code problem that you get pushback on fixing, this makes it a design problem. So you get the stakeholders in a room to come to a decision about what the code should be doing. If they can't come to a decision then it's an organizational problem, so you go to the leader for a decision. If he can't make a decision then you've got clues to a hidden leadership problem at the company.

Problems should be instantly solvable once you get to the level they're really at. You don't escalate though until you know enough about it to make a short presentation to the next person in the chain.

Once you get above the workflow level, you're in the realm of politics. Political problems are defined by the fact that multiple people in the organization care about it and you need to get sign-off before you go and unilaterally change something.

He talks about common patterns of master programmers, but does not define what master programmers are, and why he thinks they are masters in the first place. I really don't get the point of this article.

I've seen a lot of programmers that love design patterns, SOLID code, and hip new frameworks; but hate talking to users, getting stuff shipped or keeping things running.

Even if the code is "messy" and given that JUnit is used by millions of programmers hourly without trouble, I suspect Kent prefers the latter to the former and which makes him a master programmer in my book.

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.

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.