This post got me thinking: the structures that help people learn coding will also help experienced programmers be more productive.
Working in the head doesn’t scale. The head is a hardware platform that hasn’t been updated in millions of years. To enable the programmer to achieve increasingly complex feats of creativity, the environment must get the programmer out of her head, by providing an external imagination where the programmer can always be reacting to a work-in-progress.
Source: “Learnable Programming,” Bret Victor.
Office Politics 101 for Recovering Idealists. The article title says it all. I found this eye opening.
In the meantime, there’s a pretty easy rule of thumb to follow. When in doubt, keep it to yourself. Listen more than you speak and certainly more than you vent, collect as much information as possible, and ponder how it can be used to make yourself seem more of an asset to your boss than your competitors.
I was encouraged to know that a pattern of thinking I sometimes slip into has a name. It also challenges me to overcome this distorted thinking so that I am no longer controlled by fear.
Catastrophizing essentially involves imagining and dwelling on the worst possible outcome of something. It’s basically overreacting and letting your thoughts run away to dire and highly unlikely scenarios. It’s the kind of thing that happens when you’re lying awake at three in the morning worried sick about the future and what’s going to happen to you.
Patrick McKenzie with one take on a software career track. This article influenced me a lot:
Engineers are hired to create business value, not to program things: Businesses … converge on doing things which increase revenue or reduce costs. Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things. (That can, but does not necessarily, entail actually doing them.)