Archive for the ‘Quotable quotes’ Category

Quotable quotes 2

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.

Source: “Office Politics 101 for Recovering Idealists”, Erik Dietrich.

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.

Source: “Building Your Resiliency: Part VI – Quit Catastrophizing,” Brett & Kate McKay.

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.)

Source: “Don’t Call Yourself A Programmer, And Other Career Advice,” Patrick McKenzie.

Quotable quotes

It would be arrogant of me to think that I have solved the problem of large-scale software development:

It is widely acknowledged that coordination of large scale software development is an extremely difficult and persistent problem.

Source: “Splitting the Organization and Integrating the Code: Conway’s Law Revisited,” Herbsleb and Grinter, 1999 (PDF).

One of the most common antipatterns of commercial software development:

In this evil, but extremely common, mirror universe, developers branch to create features. This branch stays isolated for a long time. Meanwhile, other developers are creating other branches. When it comes close to release time, all the branches get merged into trunk.

At this point, with a couple of weeks to go, the entire testing team that has been basically twiddling their thumbs finding the odd bug on trunk suddenly has a whole release worth of integration and system-level bugs to discover, as well as all the feature-level bugs which have not yet been found because nobody bothered to have the testers check the branches properly before they got integrated.

Source: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Humble and Farley, 2010.

This view is too optimistic for me, given what I know about human nature and our sinful condition:

Technological optimists believe that technology makes life better. According to this view, we live longer, have more freedom, enjoy more leisure. Technology enriches us with artifacts, knowledge, and potential. Coupled with capitalism, technology has become this extraordinary tool for human development. At this point, it is central to mankind’s mission. While technology does bring some unintended consequences, innovation itself will see us through.

Source: “The Moral Character of Cryptographic Work,” Rogaway, 2015 (PDF).

This article was how I first came across the work of Erik Dietrich. Since then I’ve had a lot of fun reading his articles on software development and office politics.

In the sense of skills acquisition, one generally realizes arrested development and remains at a static skill level due to one of two reasons: maxing out on aptitude or some kind willingness to cease meaningful improvement. … [L]et’s discard the first possibility (since most professional programmers wouldn’t max out at or before bare minimum competence) and consider an interesting, specific instance of the second: voluntarily ceasing to improve because of a belief that expert status has been reached and thus further improvement is not possible. This opting into indefinite mediocrity is the entry into an oblique phase in skills acquisition that I will call “Expert Beginner.”

Source: “How Developers Stop Learning: Rise of the Expert Beginner,” Erik Dietrich.