A lot has been talked about how to become a great developer. They are all good ideas. I think that as a manager it is our job to grow our team and create great developers. I talked about creating challenges to do this, in a previous post. But what exactly are those challenges?
Here is a summary of what others say:
- Migael posts 15 tips to becoming a better programmer.
- Andrew says that we have to become a software engineer
- Oren Ellenbogen has 10 rules to become a great developer
- Ayende talks about a big leap and then about doing stuff
- Phil talks about programming better
- Jeff says that you have to stop programming and “Learn about your users. Learn about the industry. Learn about your business.”
- Joannes Vermorel talks about being smart and getting things done.
So how as a manager do we create better programmers? I don’t think that having a list of tips is the correct answer, I don’t think that as a manager you should give a list of tips. I think it is deeper and Ayende’s “doing stuff” and Phil “programming better” are on the correct path.
I found a great post on how to become an expert from the Creating Passionate Users blog. (the graph is from that post)
Most of us want to practice the things we’re already good at, and avoid the things we suck at. We stay average or intermediate amateurs forever.
Phils references Scientific Americans “The Expert Mind” Study.
In this study they take chess players and research how to become an expert player. It comes down to the fact that both a professional and a non-professional player do the same amount of analysis (how many future moves are calculated) and they both spend the same amount of time playing – so they practiced the same. It is just that the expert always raised the bar and practiced harder and harder games.
The bottom line, is that we must leave our comfort zone. We are comfortable avoiding the things we suck at. We must tackling those parts. As a manager we must notice the places where developers are avoiding and challenge them to do them.
If they avoid writing the help, they must practice doing it until they get good at it. If they avoid a complex module, they must practice doing just that module. If they avoid helping the QA people, they must start helping the QA people. If they avoid understanding your users, start interacting with the users.
The developer will NOT like this at first, but only by trying, by raising the bar and by practicing will your developers become experts. Even if your developers are satisfied with where they are, as a manager your can’t afford to let them be stuck, you should push them to become experts
“The bottom line, is that we must leave our comfort zone.”
True for every discipline.
I play guitar. I am constantly reminded how similar the quest is to become a good software developer; how it is so much like the quest to become a good guitar player.
As a guitar player the “raising the bar” part of the equation is much more obvious. I practice a difficult passage with a metronome. I keep practicing until I am proficient at that speed. Then I increase the speed of the metronome. I practice again – periodically stopping to analyze what I am doing – until I am proficient at the new speed. I keep repeating these steps until I reach the target speed of the passage. When I feel like I’m an “expert” at that particular passage, I find a harder one and start the process over.
Maybe all software developers should take up an instrument…
Yup,
I also play guitar and it does take a lot of practice.
With guitar it is easy, practice the same song again and again and again, and then move to something else and practice that too.
How would you translate that into practicing software development? Write the same code again and again? Use the same patterns again and again?
I think it is tackling those parts that you hate doing. Write the help files, write those unit tests, get ready for deployment, change the database, learn what is important for your users and so forth.
As managers, we have to try and spot these weak spots.
“I think it is tackling those parts that you hate doing.”
I would probably phrase it differently. I would probably say it is tackling the parts that are hard.
I know for me, playing the guitar, there isn’t anything I really “hate” doing. I love all of it. I enjoy playing chords as much as arpeggios; playing rhythm as much as soloing. I would say I can play 90% of the songs I know really well. The other 10% have something difficult in their makeup; a difficult sequence of chords, or a difficult solo passage. Those are the parts I have to actively “practice” to get better at.
So for me, practice comes in three flavors (well, two really). The first kind of practice is the “fun” practice – I play songs I know really well. These are fun to play because I’m already an expert, so there’s no need to deal with failure; to perform analysis on the failure and to practice with a heightened and analytical awareness.
The second type of practice is when I have to repeat a specific part of a song over and over; I have to train my muscles to remember the pattern, and I have to analyze my playing to figure out why I am not progressing. This sort of practice is “less fun” – it’s more work. But the payoff is that someday (hopefully) I play the part perfectly.
The third type of practice is kindred to the second type – it is doing “exercises” over and over. Practicing things that don’t have any context within a song, but they help train your fingers, muscles and your mind. This is stuff like scale practice, technique practice, etc. This stuff is usually really boring, but done with an active awareness and a routine, it helps your become a better player. It makes it easier to do the first to kinds of practice.
To relate it to software development, I would say you have to do two things.
First, you have to do the stuff that you find difficult. The hard stuff. You can’t shy away from it, or pass it off to a coworker because they’re better at it than you. You have to face that stuff. Face failure. When you face the stuff that’s hard, then you have to be critical with yourself and figure out why you’re bad at it. You have to analyze yourself. You have to then take steps to become better (practice). Read books, blogs, talk to colleagues, write prototypes, and take on projects at work that force you to face the hard stuff. This is just another way of saying, ” Leave your comfort zone.”
An example: for me, it’s threaded code. I’m weak with delegates, background threads, semaphores, waithandles, and updating the UI thread in a multithreaded environment. I recently had to work on a project where I had to do a lot of that. It was fun; I learned a lot. And I had to face my fear of getting it wrong.
The second thing I think you have to do as a software developer is repetition of practices until they become second nature. As an example, I like to think of unit testing and TDD. It’s been my experience that developers who learn unit testing don’t always stick to TDD when left to their own devices (I am guilty myself). It’s a practice that isn’t second nature yet. A software developer who wants to improve needs to treat TDD like a guitar player who knows a difficult passage, but can’t play it perfectly every time. It requires repeated practice until they can play it perfectly every time. A software developer has to practice TDD every time, until the day when they don’t even think about it – they just do it automatically.
“Use the same patterns again and again?”
Yes – this is a big one, I think. For instance, I know the visitor pattern. But I am not “comfortable” with it. I’ve used it once in my professional career. During the implementation I had to constantly refer to examples on the internet (like having sheet music in front of you). I could implement it today and I’d probably still need sheet music to complete it.
Other patters I am more familiar with. I can implement those from memory.