The story goes that there were two men, Joe and Frank, who were camping out in the woods when a bear showed up in the camp. Terrified, they decided the best they could do would be to stay perfectly still until the bear left. Hopefully, the bear wouldn’t notice them. As the bear was poking around, Joe says to Frank, “What are we going to do if this doesn’t work?” Frank says, “Run!” Joe says, “You really think we can out run a bear?” Frank says, “I don’t need to out run the bear. I only need to out run you.”
For years I have used this story to encourage my kids to be better than their peers. Right now, most people are so “out of shape” that “running faster” than the competition is easy. By comparison, my kids look awesome when by any other measure, they are probably only doing the bare minimum necessary. This is not to say they aren’t REALLY good at what they do but, there is always room for improvement.
Average Programmers
And then there are conversations I have with other programmers. So many think they are great when they are only slightly better than the people they are working with. The lack of desire to learn more, to be any better than adequate, is appalling. And this is to say nothing of the programmers who never make the cut. The ones I never work with because the people I work with and for won’t hire them. I’ve been a part of some of those interviews.
People who can’t answer the most basic of C#, ASP.NET, or JavaScript questions. This is to say nothing of people who believe knowing concepts trumps knowing the terms that specify them.
Average Organizations
And then there are the organizations who settle for frameworks that provide “Silver Bullet” answers to problems. Not because this is technically, the best solutions, but because this is the solution the requires the least from the developers they have working for them. The problem with this approach is that it doesn’t demand excellence from the programming team that works for them. And don’t get me started on managers who think they are “doing Agile” who obviously don’t even recognize that “Agile” is not a noun.
The problem with comparing ourselves to our peers is that you can always find someone worse than yourself. Not only is this true because you will always find someone who just doesn’t care, but even if we all cared, there will always be someone, who for any number of reasons, can’t be as good as you are.
Be Awesome
But we can all strive to be the best.
As programmers, what if we all decided to make as our goal code so bug free that no one could find problems with the code we wrote? Maybe there is some part of the language you program in, or the framework that you use, that you’ve never tried. How about learning it? Is there a tool you could start using that would help you program better? Maybe you’ve exhausted everything there is to learn about the language or framework that you use. Maybe it is time to learn some other language.
Who do you want to be? What do you want to be known for? These are interesting questions because they cause us to focus. Do you want to be known as mediocre? Keep coasting. Do you want to be the person who gets the challenging problems because you are the only person who is reliable enough to give the project to? The problem with out-running your peers is that eventually, the bear will be the only thing behind you. Where will you be?
Action Steps
OK, fine. How do we get from mediocre to awesome?
1. Decide to Master a Skill
I don’t care who you are or how good you are, there is still something you don’t know. The great thing about being a programmer is that there is always something to master. Do some sort of self-evaluation on your skills and determine to master some skill.
Just by way of example, here are some possible skills you might learn.
- Test Driven Development
- Deep Dive a Language you “Know”
- Learn a Language You Don’t Know
- Design Patterns
2. Teach
The best way to learn a topic is to teach the topic. There are at least two reasons for this. First, preparing to teach makes you organize all of those scattered bits of information in your brain in a way that someone else can grasp. Second, it will raise questions you didn’t even know you should ask. I can’t tell you how many times I’ve explained something and the person I am teaching ask a question I’ve never considered before. If you don’t know the answer, find the answer. You obviously don’t know your subject as well as you think you do.
Here are some possible ways to teach.
- Host a “Lunch and Learn”
- Start a Blog
- Write a Book
- Mentor a Younger Programmer
- Present Something at a Users Group or Meet-up.
3. Track Progress
In the business world, they say, “what you measure, grows.” So, measure:
- Decrease in bugs reported.
- Elapse time from start of project to bug free code.
- Cyclomatic complexity of your methods.
4. Interview for a New Job
One of the things I’ve found that interviewing for new gigs does for me is that it reveals things I should know. I find out quickly what I should know that I don’t. And don’t be the guy who says, “If my 30 years of experience isn’t good enough for you, I don’t want your stinking job.” Answer the questions, not matter how much experience you have. You might just learn something. If you don’t know the answer, after the interview, go find the answer. Don’t be like, “why should I keep that in my brain?” I mean, that might be true, but go find the answer too.
I had one of those interviews. I wrote a whole post about it that I deleted. They had me doing something I was unable to do and that I felt the rest of my knowledge and skills more than compensated for. But, after the interview, I went and found out how to do what they had asked.
5. Change Jobs
This probably sounds like odd advice, but as a contract programmer, I’ve been on assignments that have lasted as long as 8 years and I’ve been on assignments that were as short as 4 months. What I’ve learned is that the longer I stay on an assignment, the staler my skills become. That 8-year gig nearly made me unmarketable. Why? Because I never had to learn something new. The only reason I am still marketable is because I started learning newer stuff toward then end of that gig. When the gig was changing every 2 years or so, I was a lot more capable of moving into a new position. Now, I’m learning all the time. Learning what I think will make me more marketable as well as what I would really like to be doing next. Some of that makes its way into what I’m doing today. Some of it will have to wait. But it is all experience and it is all valuable. The point is, don’t get stuck knowing what you know. Switching jobs is the fast way to achieve that.
6. Ask for a Code Review
To be clear, what you are asking for is a review of your code, not how pretty it is. Although, depending on how much experience you have, there may be some benefit in having your code reviewed for formatting as well as clarity.
What I would hope you would get out of this exercise is several, “Have you considered doing it this way…” kind of comments. If you can’t get someone to review your code, there are some great code cop kind of tools available for every language that you can have review your code for common mistakes. But even better if you can get another human to look at your code.
It is interesting, I’ve been coding for 28 years and I’ve lost track of how many companies I’ve worked for. There was only one company that I’ve ever worked for that did code reviews.
7. Change Your Body Language
This probably seems like really odd advice so let me explain. Or maybe you’ve already seen the Ted talk by Amy Cuddy that says the research shows that if you assume a body position that says, “I’m awesome” you are more likely to feel awesome. But you may wonder what feeling awesome has to do with BEING awesome.
Well, in my experience, you end up being who you believe yourself to be. One way of hacking yourself into being awesome is to convince yourself that you are. The best way to do that is to assume body positions that communicate that you are.
Don’t think this is possible? I grew up walking toe out. At some point in High School or College, I read that it was more efficient to walk with my feet parallel to each other. I started concentrating on changing how I walk. Now I no longer think about it. I haven’t thought about it for years.
I’ve done the same thing with my body position. Not as hard a modification, but I’ve noticed that it DOES work.
8. Don’t Brag
The other thing that changing your body language will do is that it will communicate that you are confident and you’ll never have to say a word. I believe I’m pretty good at what I do, but my general practice is to let what I know be discovered. As I’ve observed my peers, I’ve found that the more they proclaim how great they are, the less confident they are that they really are, and generally, they aren’t. You don’t want to be that person. You want to portray confidence to be confident, but you want to be discovered. “Even a fool, when he is silent, is considered wise.” and “Better to be silent and be thought a fool than to open your mouth and remove all doubt.”
9. Focus On One Thing
The temptation, if you are motivated at all, is to try to improve in every area all at once. That is a recipe for disaster. Focus on one thing. I didn’t change how I walked and how I talked and how I ran and how I sat and… you get the picture. I focused on how I walked. Sometime later I focused on how I sat. I learned how to code well and then how to do Test Driven Development. I’m often asked how I learned all I know. It is easy, I learned one thing at a time.