Programming On Your Own.

I’ll call him Mark. He was sixteen years old when I met him. He was the older brother of one of my daughter’s friends in elementary school and he wanted to meet me because he heard that I was a programmer.

He walked into my home office and we chatted a bit. I was impressed. The guy was working on an OS shell that he’d written himself. I showed him some code I was working on and we talked about programming, testing and design. I mentioned a few techniques and he was very clear about what worked for him and what didn’t and why he would or wouldn’t ever program in a specific way.

He was young, obsessed with programming, and entirely self-taught. Moreover, he had scars to prove it. I forget now, what techniques we discussed but I remember his strong will. When he found a way of writing software that got him into trouble, he resolved never to do it again. We planned to stay in touch, and I gave him a spare copy of Martin Fowler’s Refactoring book that I had hanging around, but I could see the path in front of him. He had a lot learning to do and a lot of unlearning, but he had passion for the work and an unbounded sense of ambition. It was invigorating just talking to him.

The fact is, I used to know a lot of guys like Mark. When I was younger, I used to hang around with a guy worked on FidoNet. He worked on it alone and he never seemed to do anything else. I’ll never forget, he had an optimization switch named full_tilt_boogie_mode in his code and he was very proud of it. I used to go over to his house with some other friends and we used to go over to his house and talk the right way to work in C. He had his quirks too. Battle scars.. things he would never do again. And, like all of us at the time, he worked alone.

I don’t know about you, but sometimes I forget just how hard programming is. I’ve gotten used to its difficulty. If you enjoy it, you don’t think about the hard work. As your skill grows, you start to have a sense of flow. Sure, you work on hard problems, but they are challenges and you enjoy finishing them. But for the beginner, it’s hard. It’s very hard. Moreover, it’s daunting once you finally understand the nature of programming, and anyone who as taught themselves programming will get it eventually: Programming is hard because it is one of the most unforgiving human activities imaginable. When you program, you can’t blame anyone else if there is a problem. And if, heaven help you, you are ambitious and you attempt a very large program yourself, after a month or so you’ll see the blind alleys, the places where your mistakes glow through the crevices and you’ll know it was you. Programming is a giant mirror. It shows us our limitations. It shows us the way that we are rather than the way that we should be. Look at the code you wrote six months ago. It’s a part of you, your thoughts crystallized.

If we know this, it’s easy to understand why some young programmers get nearly neurotic about their practices. They paint themselves into wicked corners and then they analyze. They try to figure out they did that made it all go bad. When they think they have the answer they resolve never to do it again. It’s a painful process, and there is the danger of going too far, throwing the baby out with the bathwater. But I think it’s a useful exercise. Often we only resolve to get better when we know what the stakes are, and when we know that we are fallible.

One of the hallmarks of agile practice is collective code ownership. Programmers work together on projects and there is no “my code” and “your code.” It’s all “our code.” With many teams I see it work out well. Other teams struggle to avoid the tragedy of the commons. In the latter cases, the culprit usually team culture and organizational culture, but I also notice that there are some people who just aren’t quite ready for collective code ownership. They haven’t had the feedback that a personal code base provides. A good supportive team can bring beginners into the fold and help them grow their skill, but, well, maybe I’m being a hard-ass. I think that somewhere, someplace - in school, or on their own, programmers need to spend some time, early in their career, working by themselves, so that they can confront the challenges of the work and build that personal feedback loop. As programmers, we need to fail on our own, abjectly a few times to know that we can. We need to struggle with practice and learn a few rules too well, and then give ourselves a chance to unlearn them.

Becoming a programmer this way can be hazardous. There is always the chance people will become anti-social, unable to work on teams, or they can end up with crazy self-defeating ideas because they’ve learned lessons too well, but it doesn’t have to be that way. If you know a guy like Mark, talk to him, pair with him, help him, but let him find some answers himself. Let him feel personal responsibility for something large and help him nurture that personal sense of perfection, that spiral to excellence.

I think that some programmers need an incubation period, a time when they learn how not to be harmful to themselves and others, a time when they learn the discipline they need for team play. I think that beginners need this time and they and the teams they eventually join are better for it.




!commentForm