Programmers, keep your wits about you and Code Mindfully
I was talking with Patrick Cauldwell the other day about what makes a "Good Developer." We talked about a number of different characteristics.
My intent was to write up a list of good personality characteristics that describe effective programmers, but Patrick said, "The real problem with most developers is that they don't keep their wits about themselves."
This was like a slap in the face to me. I realized when I was going through the Programmer Phases of Grief that I hadn't kept my wits about me.
You ever have the very frightening experience when you're driving along, perhaps lost in thought, and next thing you know, you've driven two miles and you don't remember the driving process that got you there?
Many of us who've been programming for a long time, or folks who are very gifted and take get from A to C while skipping B, can have these fugue states while programming. I don't literally mean that one blacks out while coding, but rather one goes "running down a one-way dead-end street." A lot of time is wasted before we realize that some original assumption was wrong.
I think one can be a more effective programmer if they can avoid not-thinking. Call it Mindful Coding if you will. The act of actually thinking while writing code is challenging, especially when your mind is jumping to the next idea or if you're writing code you've written a dozen times before.
Sometimes I'll catch myself asking a question of someone around here, and halfway though the question I'll realize that I haven't really THOUGHT about the problem space. For me, and my learning style, this might involve explaining it to someone (often my wife, who nods in all the right places, but cares not about such things) or drawing a picture.
For many, analytical thinking isn't a passive thing. Often just making the decision to "sleep on it" can be all that's needed to break through a hard problem.
"If you can keep your wits about you while all others are losing theirs, and blaming you. . . . The world will be yours and everything in it, what's more, you'll be a man, my son." - Rudyard Kipling
So, I say, programmers, keep your wits about you. Code Mindfully. I vow to try harder.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hey, like the new look!
I read a story a little while ago, but I can't remember the link. The basics of the story were... some CS department had a stuffed bear outside the door. If you wanted to ask the CS department a question, you had to explain it to the bear.
90%+ of the students had their problems solved by explaining it to the bear.
Moral of the story? If your wife isn't helpful, explain the problem to the bear. :)
For some that's as hard as pulling over to a gas station and asking for directions, but it's one of the best things you can do.
A level-headed developer definitely stands out from the crowd. PMs notice them right away and tend to promote them to tech leads. Tech leads who are moving on to another job tend to recommend level-headed developers to their PMs as their replacements.
I hope you don't misquote your strings as badly as you misquote Kipling!
If you can keep your head when all about you are losing theirs and blaming it on you ... Yours is the Earth and everything that's in it, and - which is more - you'll be a Man my son!
What I mean is, there are some things that developers shouldn't have to think about as long as the architects have thought about them already. Let the architects to the long hard thinking about which interfaces your classes inherit from. I don't belief that developers on a large project should be expected to go from the 10,000ft view to the 1ft view instantly and if you're on a smaller project then hopefully you don't have to fly as high as 10,000ft.
After all, developer context switches take time just like OS context switches take time.
However, within your flying zone, whether it be the 10,00ft zone or the 1ft zone, you do need to be aware of where you're going.
Isn't code decoupling about developer decoupling anyway?
Nice redesign by the way. I like the clean, simple, Zen look.
At the same time it's not easy. So it can be hard to do initially. But when you've got a good partner you can stay on focus and get higher quality code much more quickly.
Also, you do have to watch out for backseat driving in pair programming.
One thing I have learned over time: As an architect / lead developer I face problems that are really hard to solve. Some of these problems are so complex that I may spend days figuring out a solution. Pitching the problem against other architects is often useful and is an important step in problem solving.
However, when you find yourself lost - out of options (i.e. google didn't help, your wife went shopping or your colleagues left for lunch), parking the problem for a few days actually makes it every time.
The good ol' saying "let's sleep on it" really works every time (atleast for me).
The only problem is that as the complexity of the problems increase, you keep finding yourself shouting "I'll never figure this out". And so history repeats itself ..
Comments are closed.
That being said, I wish I'd not spent an hour of my flight back from London on monday fighting a CSS/HTML combo that refused to show a background graphic when I spotted, 60mins and 10seconds later a missing semi-colon.
I'd already moved the CSS into and out of the html several times, linked to a static css, moved the files, recreated the virtual directory, tried several different jpegs and sworn at the machine several times.
At least I had nothing else to do but watch the movie I suppose!