Don’t let junior programmers cowboy code.
This is a new series that I will be starting, called “Don’t do this”. Basically it is a spin on another series I started called “Learn this”, but it is more of an observation of things that I have had to learn a lesson from.
In this article, I want to discuss the dangers of allowing junior developers to “cowboy code“, or do whatever they feel is right. The junior programmer does not know what “right” is, or better yet, has not shown you what right is. A lot of people might think this is common sense, but it isn’t. I have seen it too many times and lately I have been trying to become more aware of it. Ignoring this is not only bad for the code base, but it is bad for you, the client and the actual junior employee.
Greenhorns first day
Today is the day that your eager new junior developer starts. He comes in all bright eyed and ready to go. After showing him the ropes of the office and what he will be working on, you give him his first assignment. Nothing big, just something to get his feet wet. Maybe it takes him roughly a day or so to do it, about as long as it would have taken you. When he is done, he reports to you. You check it out and say “Hey hey! It works! Great!”. You give him a good job, a pat on the back, tell him to check it in and you give him another assignment to start on. This is EXACTLY where YOU went wrong.
At no point did you look at the code. You might think it is rude, but hey, guess what? You ignoring this may cost you and the rest of the development team months of agony trying to undo the damage that has been done. Why would you assume he did a good job? You shouldn’t. This is Junior’s first professional assignment. Junior makes mistakes. It is as simple as that. I have caught untold amounts of horrid code simply by saying ‘show me your work’. There is nothing wrong with doubting someones code. The sooner he or she knows that what they did is bad, the less of a chance you have of seeing it again.
Does this mean you now have have a child to watch after? YES! THAT’S WHAT IT MEANS. If you are going to hire someone right out of college without any professional experience, you better have the resources to manage this person. You cannot expect good code after dropping someone in a new environment without any prior experience. The same goes for anything. If you have a child, you teach it right from wrong as soon as possible. If you get a new puppy, you will be quick to point out the mistake he left on the rug. The same thing needs to happen here.
Shouldn’t this person be learning things on their own outside of work? Yes they certainly should. That does not mean they are. Unfortunately, all the greenhorn hears are praises from you on how good of a job they have been doing. Why would they bother learning more? I am not referring to ‘hey go learn the new X framework’. I am referring to RIGHT and WRONG. It is not hard to tell the new guy
“I know you had to change the parents color in this state, but doing this.parent.parent.parent.parent.color = “red” isnt the best way to handle that” or “Well, this works, check out how much cleaner it is when we use an interface”.
Okay, so you have come to the realization that your greenhorn is green and not some amazing cowboy programmer you were hoping for. Now what? Here are a short list of things I try to do in order to stop bad coding practices whenever I am in a lead position with “a new guy”.
- At the beginning of the project, tell him/her to ASK QUESTIONS! You do not care of little they are. If they don’t know, they need to ask. Try to be friendly about it. Don’t scare them out of wanting to ask questions. Remind them that you know its a big project/framework/whatever they are working with and lots of questions are bound to come up.
- Second, daily meetings. These should not be longer than 10 minutes. All you care about is ‘what was worked on yesterday, what will be worked on today, and what hurdles they might have run into. This obviously works better with smaller teams, but it will help keep them focused. It also helps bring any issues they might have to light before its too far into development to handle it properly.
- Quick code reviews. This is something you are going to do before the code is checked in. Just ask ‘Explain the task real quick. Explain what all the large methods are doing’. This is one of the most important things you can do because you will now be looking at his work before he decides to check in that 600 line method with repeated code everywhere.
- When you do these quick reviews, do not just fix it for them. You can help them. Guide them. Get them them started. DO NOT cry on the inside and fix it behind their back. We all know it is quicker if you fix it, but you will become the power source that they will always go back to so you can fix their mistakes again.
- For the love of god, RECOMMEND BOOKS! When I first started, I tried reading books on programming. The downside was I could not pick out a good book if it slapped me in the face. Hopefully your company has an internal library, then you can just toss them a book.
New guy advice
Now, if there are any junior programmers reading this, here are a list of things you can do.
- Do not take offense when someone looks at your code, that code you clocked in extra hours to get it working properly, and they just RIPS IT to shreds. Even to this day, I want people to look at my code and tell me how I did it wrong. If I am doing something wrong, I *WANT* someone to tell me.
- Next, stop acting like you know everything. This may sound harsh, but straight out of college with zero professional experience, you are bound to have questions about things you do not understand. Do not just yes and nod people to death. While it is important to ask ‘how to do something’, it is even MORE important to ask “why?’. Asking how they would do it gives you the answer, but it does not answer fundamental problem at hand. When your mentor says “use interfaces here like it was done in X”, are you going to understand WHY you are using the interfaces, or are you just going to blindly follow his example in similar situations?
- If they do not offer you one, as for a recommendation for a good book. A good programmer should have a small line up of books that they should consider ‘required reading’. Not only will asking help you, but it will also cast that impression of trust that you are looking for so much since they wont stop breathing down your neck.
New programmers need to be treated like children. I don’t care if they run to you with a 4.0 GPA all throughout college. Zero experience = Greenhorn. You CANNOT let them cowboy off on their own. When they screw up, it is YOUR FAULT. Why? Because you allowed it to happen. The longer you allow them to cowboy code, the deeper loads of possible errors are going to get. Instead, make them earn your trust. Make them get used to be questioned as a junior programmer. Make sure they learn from their mistakes.
It is tough to teach an old dog new tricks. Unfortunately, that old dog was allowed to code without anyone watching after him, and he isnt learning anything new anytime soon. Also the boss says he is on your team and you are stuck with him. Good luck.
Have any other bits of advice for junior programmers or anyone that might be working with junior programmers? Disagree with me? Feel free to comment.