ArticleS. MichaelFeathers.
ProgrammingOnYourOwn [add child]

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



 Tue, 24 Jan 2006 12:37:02, Ron Jeffries, on your own ...
What bad things would happen if programmers never experience abject failure, owing to working always with people who kept them from such failures?
 Tue, 24 Jan 2006 12:46:31, Travis Griggs,
Michael, your blog reads well. Lots of moments of "yep, so true". You seem to hint at a point of transcendence which I'm not sure I agree with. Maybe it wasn't intended. As read though, it basically reads like a path of maturity. You have to spend some time on yourself, coming to grips with the reality of programming, and then you can go out and program socially. Young people code alone; Old people code together. I think alone programming time is always valuable. For any age. For the reasons you cite. And I think pair (social) programming is always valuable, for the inexperienced as well as the experienced.

- Travis, I agree. I think the thing that I notice is that I do run into some programmers who seem not to have tried something large on their own. There is a lot to learn in that work, just as there is in pairing and working collaboratively. I didn't mean to denigrate the latter, but rather to point out that I think that the benefits of the former are underappreciated at times. -- mf
 Tue, 24 Jan 2006 13:04:52, Michael Feathers,
Ron, you ask that as if occasional abject failure were a bad thing. Do you think it is?
 Tue, 24 Jan 2006 13:42:47, Zorkerman, back to the wall
There is a powerful moment that can only come when you are the only developer on a project. You come to a place, where you just don't know how to solve something... Perhaps it is some interaction with a third party tool in which case you've got message boards. But only when you are alone, staring at a screen at 3am knowing that if you don't figure out something, no one will.

And when the solution comes....

It's programmer nerdvana.
 Tue, 24 Jan 2006 16:11:47, Keith, ,,,
I think it is important to experience failure and the difficulty of programming various things. I don't think people fully appreciate how to create good working software unless they experience this. I've noticed when we have brought in grads and paired them they tend to gloss over some of the important subtle details they never fully go "A-ha!" because their pair is cushioning any pain they would feel by not letting them make painful mistakes. What I try to do these days is find the newbies an internal project to work on by themselves.
 Tue, 24 Jan 2006 20:01:13, Chiaroscuro, Introspection
Thanks for the post Michael. it's amazing how much this resonates with my own experience. With your mirror metaphor you describe well that feeling of transcendence that seems to take hold of some of us. Is it strange that I find modern philosophy to be very close to development? I have often noticed that a certain attitude towards practicing a certain art (or sport or craft) always leads different people to come up with similar conclusions about themselves and the world. Do you have a name for this mystic quality that is born out of the obsessive need to refine a perfect strategy to achieve your goals?