Thinking like a programmer

So, a while ago, I asked some programmers who were learning English from me what people least understood about programming. (Because, who cares what they could learn from me, I’m about what I can learn from them!)

The answer I got surprised me. They said that people just didn’t get how well you had to understand a subject to write a good program to support it. In their cases, they wrote software to automate some parts of a civil engineer’s job and felt burdened by what they’d learned about civil engineering. “I was never interested in it,” on of them said, “and now, whenever I pull onto the autobahn, I check if the on ramp is banked the way it should be. Because that’s the part of the code I wrote.”

Coding, for them, wound up being like teaching English for me: learning about all kind of interesting things that you wouldn’t have otherwise learned, but not always completely content with the list of things they were learning.

“And it changes the way you think.” Quickly followed that example. “You start seeing everything in algorithms, in steps. And making things efficient.”

“I can’t watch my wife work at home.” The other chimed in, “she does things wrong.” When I gave him a quizzical look, he said “she adds steps to things that she doesn’t need to add steps to, like cooking.”

The conversation that followed was wide-ranging, from three guys in a room talking about their wives (we didn’t say anything bad, honey, I swear!) to the actual topic at hand. My takeaway, though, was that they were so obsessed with brevity and efficiency in their work, that it started leaking out into their day-to-day life.

The idea is simple: they were writing code that had to be executed in ‘real time’ (the user shouldn’t feel like she ever had to wait) and so it had to be as few steps as possible. After all, a lot of what they did was write stuff that would be applied to a lot of different data points. So, if you can skip two or three steps — in a process that’s going to be repeated a thousand or more times each time the user alters her plans — you’re reducing the risk of the software seeming laggy.

So, naturally, opening the coffee and putting the open container next to the coffee maker seemed like an extra step to them: why wouldn’t you first get the filter ready and then skip the steps of putting down and picking up the coffee? If you were making a thousand pots of coffee per morning, you probably would.

I’ve spent quite a bit of time in my Python playground of late, and I’ve enjoyed most of it. In case you’re wondering, I haven’t reached the point in my programming life where my obsession with speed leaves me criticizing my wife. It’s just lead me to the point where I can barely stand to see myself work.

I don’t pretend to be able to point to any recording of the words in quotes above. And nothing said in the conversation I’m writing about would have been said in especially good English. I’m just going for the gist. I doubt that either of the programmers, were they to read this, would feel misrepresented.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s