Zen And The Art Of Programming: Beginner’s Mind | Hacker News Reader

Zen And The Art Of Programming: Beginner’s Mind

agillo.net

25 pointscfontes10 comments

Neat advice for programmers from an application writing perspective, but it made me consider something else that I think might have value as well.

I'm one of those people who started out writing code but ended up taking on more of a management role. I like to think of myself as being cut from the same cloth as Rands (randsinrepose.com), in that I'm reflective of the programmer's point of view when I engage in management practice.

One thing I've noticed in the HN community, and the technical community at large, is that "idea" people are often dismissed out of hand. Don't get me wrong, the vast majority of ideas that "beginners" pitch are ill-informed or naive to the point that the idea is just unusable, but occasionally, you'll come across a rare gem contains some insight that is outside the reach of a master.

The key is that the beginner very rarely frames their ideas in the language of the programmer, so we have a tendency to simply check out of the conversation. I like to engage idea people and use them as a springboard for ideas. They're often so excited to talk to someone who they know can make their idea happen that they'll take direction from you. Then again, they're sometimes completely hard headed and stuck in their idea rut. As the master, you get to decide who you want to engage and who you don't.

I've worked hard on building my skills at gaining trust and guiding the conversation with idea people. I find that if you open your mind and listen, you can extract the valuable parts from their ideas, reframe them in the language of the programmer, and become a facilitator of great ideas that otherwise wouldn't get traction.

First, 'beginners' do worry. I worried a LOT more before I had the experience to know what would work and what wouldn't. When I come across new things, I worry like crazy until I've tried them.

As for camel case preventing you from being your best... Really? -sigh-

And as for the enterprise-y way of doing things in Java, sure, you could do it some other way first, but you'll likely end up changing it anyhow... It's much quicker to just do it that way from the start.

I'm all for improving things and doing things better, but railing against things just because they're -always- done like that is worse than pointless.

Also, don't think I'm defending Java. That isn't what this is about.

I think you are sort of missing the point here. The idea is that when you are the 3rd of 4th person down the line of "do it like $THIS, it's the best way", the $THIS has usually morphed. Most of the time that morphing is going from a generalized, loose rule to a strict procedure. But it can also take the form of dogma (goto is always bad, vs the original goto is bad except those few cases where it is the RightThing). Sometimes it is good to challenge the status quo for just that reason, the original good ideas may be lost in the noise, or the initial assumptions may have become invalid. So the point is that beginners don't know that this stuff is "always good" or "always bad", allowing them to look at it from a fresh perspective. This often allows for breakthroughs.

As for the worry thing, I submit to you this:

1. The Beginner is an ideal beginner. As such, this Beginner is expected to make mistakes, as it is part of the learning process. (S)He is expected to struggle while grasping the difficult concepts -- they are difficult. (S)He is expected to wander down "wrong" paths, as exploration is part of the road to mastery.

2. Worry almost always comes down to some underlying fear. Usually a fear of something being taken away, be it a job or a possession or something else tangible, or something less tangible like a reputation or a status, perhaps this is tied to one's personal estimation of self worth.

3. An expert has to fear his expert status, or at least his respect as such, being taken away. This is the worry aboyt mistakes that the article was talking about, an expert who makes mistakes is not long for being expert.

Given these, I am of two minds on this thing you said. First, perhaps the beginner worry comes from not understanding the role of beginner, that mistakes are expected and should probably be encouraged. Second, perhaps the beginner on one thing is an expert in a related thing, and thus is worried about losing status all along. For instance, if a child is the expert at school, he worries about losing his wunderkind status, even when facing his first maths class. If a programmer is really good with Java and and has a rep for being fast a picking up new languages, but has only faced down basic OO stuff, perhaps Haskell would cause a big worry in him?

Everyone makes mistakes, but they should never be encouraged. Beginners should be encouraged to explore, though.

I disagree about fear being only of something being taken away. I don't fear for my job because I know I am good enough.

Instead, I fear what repercussions my mistakes will have on others, such as the company I work for. I suppose you could argue that it's still somehow something being taken away, but it's much less tangible and I can't put it into words if that's so.

I also worry that I'll spend more time and effort on something than it deserves. It's rather a silly worry, but it does keep me efficient at my job, so it turns out to be useful after all. (Unlike my fear of heights and water which haven't helped me at all so far.)

I agree that third-hand "That's bad!" is often misleading, but I think those things are great for beginners. It lets them avoid the most troublesome mistakes while they learn. After they learn the basics, they can start breaking those rules. Art is much the same way.

Mistakes should be encouraged, then when they are made, they should be presented as learning opportunities. As in: "this is incorrect, here are some things you can do instead, lets look at why you thought this, and how we can get you to a different frame of mind".

Please re-read my statement number 2. I said worry is usually rooted in fear of something being taken away. I never said anything regarding the nature of fear, either its causes or effects.

I'll try to put those repercussion fears into words for you: you are afraid that your mistakes will have the company go out of business and your job will be taken, that your friends and colleagues will no longer associate and respect you as a result (taking away those relationships), that future employment will be harder to find (taking away security). Is this on the right track? I have those fears too, I just try not to let them rule my life.

As for the other side of this why worry about inefficiency? Are you afraid you might have your reputation for no-nonsense constant work taken away? Do you fear you won't get enough money? Whats the big deal about learning something that takes a bunch of time but doesn't return as well as you'd hoped? Why worry about it? Sometimes inefficiency in the small leads to gains in the large, and vice-versa.

As for 3rd-hand "thats bad": I have yet to meet anyone who is both good at something and blindly accepts these "truisms". The good ones question it from the get-go, they may end up agreeing to the principle, but they don't just blindly accept and move on, instead they try to understand it. This is different than the dogma and hard rules I was talking about.

edit: When I say mistakes should be encouraged I don't mean saying "yay you made a mistake! Here is a gold star." Or "Johnny you didn't make a mistake, no star for you". Instead I mean students should be told "It's ok to make mistakes, learn from them, it is a natural result as you gain understanding" Because in the end, humans learn by experience, both positive and negative.

In my previous company we experimented with "promiscuous pairing". The idea is that you swap partners every hour and a half or so. You would spend 2 time slots on each partnership, in the first you were the beginner, the second the teacher. We found this had a profound effect on both morale and velocity. We'd already beenp pairing up until this point but the partnerships tended to last for as long as it took to implement a story. In practice there were favoured partnerships and differences of opinion that had become engrained. By swapping partnerships frequently there was always someone in beginners mind. Because the top level business case was always the first thing people asked it forced people to justify every decision in that context. We found this prevented people from going down "rabbit holes" which in turn led to the dramatic increase in velocity. There's obviously other benefits such as knowledge sharing e.g. a new key shortcus would be found and round the team within hours.

If you want to know more about promiscuous programming and the beginners mind I recommend taking a look at http://mitchlacey.com/docs/XR4PromiscuousPairingandBeginners....

I'm trying to do this right now, by taking lessons from Clojure and applying them in regular Java code. The result is something I'd never expect to see in Java, but makes for better and cleaner code. Stuff like:

    schedule(this, "doStuffRegularly", 1000);

Which starts a thread that runs this.doStuffRegularly() every 10 seconds

How surprised would you be if that stuff ran every second?

If it's milisecs it sure does

Actually, I have a counter in doStuff which only executes it once every 10 times. Meh, you got me.

Reply on news.ycombinator.com