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”.
Now what?
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.
spoken like someone recently promoted to intermediate. Being junior doesn’t automatically make someone incompotent, just like having a senior title doesn’t necessairly make you brilliant.
I interned for a top software company last summer, and I’m returning for a full-time job in about three months. This seems like really good advice. When my superiors are telling me what’s wrong in a certain area or how to do something, I tend to nod and say yes, taking note of what they say but not bothering to find out why. I never really considered it before, but after reading it here, I’m going to try to fight the urge to nod. Thanks a bunch.
@cb
I agree 100%. It can be dangerous to think all the senior people at your place are correct. The old dog/new tricks idea applies to them as well. I realize I might have come off a bit harsh with the idea that new guy = wrong. However, it is rare to see someone out of college with no professional experience to do well right off the bat. Some juniors might shine shortly after starting, others may not. But you will never know without checking up on them.
@cb: do you have any other ridiculous and completely irrelevant non sequiturs up your sleeve? How about “just because a function is 600 lines long doesn’t mean it should be factored” or “maybe the law of demeter doesn’t apply because we are at the end of a chain of anonymous objects”
The nuance is that you *assume* they’re incompetent until they prove otherwise. Which might be a week, or it might be a year.
You are a junior developer. And a douchebag.
First rule of thumb for any new employee, junior or senior, is to check their work. Before hiring you should have seen samples of their work to begin with.
A serior can screw things up just as bad as a junior. Seniors have the tendancy to be stuck in their ways, wanting things done there way or no way.
I totally agree with this article. Looking back to my 1 year experience as a junior programmer, I can say that my mentor and I did eveything right. Always being a “why-guy”, even then on the half way I realized that this whole process is a big accelerator that helps a junior programmer become a part of a team as intermediate developer.
Nothing to add to the article. The big key is asking “why” questions.
I guess, the next article will be about careless and arrogant seniors
I agree 100%. However people get offended and they shouldn’t. Just like when someone is learning to ride a bike he sometimes is taught new things so to hear. But you must be careful in correcting him… Don’t scream saying WTF!!! ask him why he didn’t do it another way. Maybe he didn’t think of it or he has a reason…
Absolutely priceless advice and article! These words will help managers train more competent programmers. I am looking forward to your upcoming issues in this series.
There is nothing wrong with doubting someone’s English.
Learn how to use apostrophes and get someone to proof read your work.
Otherwise, fair point. There’s nothing wrong with stating the obvious. The obvious needs stating.
@bob: So far the only douche here is you.
You sound like a moron who needs to get kicked to balls. Fucking loser
@JP
What management style is this again? I think I have been on the business end of it before.
I agree with article as it goes right to the root of a problem
http://elegantcode.com/2008/12/27/thinking-only-of-the-junior-developer/
I think code review is a valid tool, no matter what level of programmer you are.
Wat if you are the JR that happens to have the opportunity to get a peak at some of your “superiors” code. I wrote a custom print DLL for my boss at the time, packaged it along with a basic “test form” that showed how to call the print methods and sent it along. Expecting him to include the DLL and just call the print methods as documented.
I recieve an email & a few phone calls that this print method wouldn’t work! I asked to view the code… egads it was scary.
Nope, instead he created the “test” form hidden from view, populated the text boxes and programattically called the “On Click” event of the print button.
I worry less about the cowboys rookies than I do about the manager that thinks he can code.
It’s called code reviews.
They should be S.O.P for a reason.
Spoken like a know-it-all junior programmer. Code review is your friend. Don’t fight it.
Speaking as someone who was recently junior somewhere and decided he didn’t want it anymore:
What about when you feel like everyone around you is cowboying code and it makes your head hurt just reading their code, let alone having to refactor it because you simply can’t stand looking at something so hideous?
The problem I have is when “senior” people (simple people who have been working longer at a company), are immature and condescending.
The thing to keep in mind, if you are a senior, that when you graduate from high school, or university, you are now in the professional work force. You cannot bully, belittle, or condescend to anyone simply because they are junior.
I find that code suffers the most when there are assholes running the show. Who wants to write good code, or even try, when your seniors are jerks? It is demoralizing and breeds the “yes, yes, nod, nod”, dampens question asking, and douses initiative.
After 12 years in the trenches, I agree that checking up on a junior programmer’s code is a must.
After a certain point, it is expected that they have picked up most of the good habits one would expect to find in a senior programmer. Submitting code for peer review is one of those good habits.
Starting a junior programmer off in the right direction is just plain good sense, and just as you wouldn’t blindly trust the designs of a junior structural engineer, you shouldn’t blindly trust the work of a junior software engineer. Measure twice, cut once.
One can always find examples of bad senior programmers and managers, but this just serves to further reinforce the importance of proper mentoring.
Marcel, great advice there!
I like it especially when you point out the two-way traffic. It takes two to clap, and I sure am grateful for the years in R&D and consulting when the senior staffs showed me the ropes.
I do find that kids these days are harder and harder to mentor. They have the “let’s question everything for the sake of questioning” attitude.
One more important tip for the junior dev, *coding discipline*. It is basically about knowing when to stop. I gradually learn to pull myself out of coding a module to death, and see the project as a whole. Sometimes optimizing for performance or mem size is good, other times it is not. For the senior dev, know when to tell your junior dev to stop. Observe the feature freeze and code freeze timeline; don’t let them overshoot because they want to squeeze in one more feature or 100ms from the code. Just don’t. I remember how my project lead would tell me to “just go away, have a drink, disappear” when my module was done.
Code reviews should happen to EVERY member of the development team regardless of experience.
Kudos to Snappy’s comment. I’d say that he/she provided the most accurate description of any ambitious junior programmer. Learn where to stop. Regardless of seniority, code reviews are essential and help to maintain consistency throughout a particular project, however just because a person has been deemed ’senior’ does not give them superior problem-solving abilities.
While there is good advice here, new programmers do not need to be treated like children. Douche.
Very good points touched there. New programmers must first use a sandbox to experiment and then they can go on more serious stuff
@balls: Treated like children in a literal sense? No, they don’t have to be treated like children in a literal sense.
Taught and trained like children? Yes, they do have to be taught and trained like children.
That easily translates to being treated like a child, in a non-literal sense.
You really do sound like one of the junior-programmers in question.
All code should be reviewed for style, clarity, and correctness before making it into the tree.
@Ardent
Word to Ardent.
@JP
or licked. pure genius.
I would take this one step further. DO NOT LETE ANYONE( including the most senior dev ) COWBOY ANY CODE.
Code reviews are useful for everyone. They help even the best programmer avoid being lazy and doing the easy way out instead of the right way. They help you write and word your code so that the next guy to work on it knows what it does. And at worst your best programmer in the world and you can use your code review to help someone else learn why you did things and why your way is so much better.
Yes, even 20 year senior devs can write better code with a second set of eyes even from the worst programmer.
Its a team enviroment in software these days and there is no I in team.. chain is only strong as its weakest link etc etc…
@Ben: Thanks for the thumbs up!
Wouldn’t have known or be where I am if not for the mentors I had, and for that I’m eternally … ok, very grateful for at least this life. Next life, I would be grateful if I can remember … but I digress … :p
I have to also second once more code reviews mentioned by many others. It is always helpful to reduce “programmer’s blindness”. A bug can be elusive to the original coder but glaring to the reviewer.
Further, I find two-way code reviews useful for projects and growth for the individuals. A senior reviewing the junior’s code helps lend experience to the junior and can help align the junior’s coding in terms of “cleaniness”. A junior reviewing a senior’s code can bring new dynamism to the group while the junior can learn first hand best practices from the senior as an individual and as part of the group’s coding practices.
I’d change the title to “Don’t let programmers cowboy code”. It does not matter if your junior or not. I’ve seen junior making better code than seniors. And Senior coding with all the resources of the language in the most complicated way possible…
If your mind and concepts are right, your code will be right as well.
Hey All,
I work for a 5 person company, of which only 2 can program, myself included. The ’senior developer’ if you will, while having run a business between he and his wife for around 20 years, is a 100% self taught coder. He has never been to college or taken any classes. While he claims he is slowly learning OOA&D, his code does not reflect it in any way shape or form. For example, many of his classes have hundreds of redundant properties and methods, and the only abstract classes I’ve seen in his code is that generated from XML binding programs. He also does not understand design. He will put his nose to the grindstone and code for hours. Questions about functionality are asked when he discovers them, and he then reworks his code over and over. The result is a spaghetti mess, with a lot of redundancy and in many cases, unused code. Oh yeah, and I forgot, he doesn’t comment ANYTHING.
I myself have been coding for only 2 years. I have a strong desire to put good design methods into practice: developing requirements, assuring that our plans meet our customers needs, making assessments for design, and THEN putting it to code. I have appealed to him time and time again to step back and ask more questions ahead of time, but he absolutely refuses to see my point. As a result he spends 35-40 hours a week coding with minimal results. Oh, and I should point out, those 35-40 hours a week are hours he works AFTER his normal 40 hours as a Delphi contractor.
Does anybody out there have any advice on how to curb such a careless programmer?
You are so correct! The senior systems architects must code review all of the junior hires. You should also be skeptical of the term “senior” until you see the proof. I design database schemas, algorithms, and object models for associates more “senior” than myself in years. They do excellent work with the right balance of guidance and freedom.
If you put a junior level developer in charge of a major piece of work, you will end up rewriting it. Adding features will be torture, and changes will cause new problems in unrelated feature points. This is a six to seven digit cost in dollars for a company of my size. If the end result is extensible, scalable, acceptably performing, and well-tested, then the programmer is no longer “junior”. Some are gifted right from the start, but like the vast majority of code slingers, I definitely started out junior.
I have been coding for fifteen years, and I partly agree. The fact of the matter is that there are no standards (well globally) in this constantly changing industry and that makes everyone a greenhorn. There is no right or wrong with programming. There is only the spec, and if it is met then the work is correct. I have met coders who have risen through the ranks of particular companies only to come out the other side with (IMHO) rediculous methodologies. Do your own homework and question everything.
To all.
I think the best solution is use the framework. Whether the juniors write wrong or not, if it run correctly, it means that he/she (the junior) follow all the instructions. Especially when they using Struts. Even there is a lots of work. If they are NOT following the procedure using the framework(for example, bind the ActionForm, Controller and forward request at the struts-config.xml), there is no way they will success run the code.
@WeaponsTheyFear
Yups! And we need to provide a test.
I truly agree that people should not let others drive the code which may end up in a mess.
People should not feel offended when they are taught or guided by the experts (which generally are their superiors). Nice article, thanks for sharing.
@WeaponsTheyFear
I strongly agree. They feel like they know everything, and it’s either their way or the highway.
I tend to have had almost exactly the opposite experiences as you have. In my experience, it has generally been the ’senior’ developers that write the most disgusting and unmaintainable code. And the real problem is, they have no idea how awful they are at their jobs.
The reason for this, and this is where I agree with you, is most of these ’senior’ programmers have spent little time maintaining others’ code, have rarely, if ever, had their own code reviewed by peers, and have likely never jointly coded projects. In fact, the only consulting with others has been in the months of meetings before a small to medium sized project begins ‘designing’ the ’system’, with everyone attempting to assert their prowess in theoretical algorithm design (no math, no psuedocode, noting pertaining to the problem at hand, only gibberish and nonsense).
And the worst thing? The managers have not written code in 25 years yet consider themselves to be excellent programmers. They’ve never seen any of the code their current or past programmers have written, and are shocked to hear that all of the code in that has been written on their watch is unmaintainable spaghetti, because hey, it worked, right? Well, it sort of worked anyways. Except that’s only because the ‘junior’ programmers have been fixing the myriad MAJOR bugs in these systems for all these years, while the senior programmers worked on their next ‘masterpiece’.
While I am more experienced than anyone I currently work with, and more experienced than most that I have worked with in my life, I again find myself in the ‘junior’ programmer position, as the newest programmer at the healthcare institution I have now been with for a year. It is extremely frustrating trying to deal with old fogies who really and truly believe they are some of the best programmers in the world, yet cannot seem to grasp why when using an object oriented language, 2500 lines of code that do 30 different things should not be stuffed into one method, and maybe that shouldn’t be the only method in the class, and maybe your display logic and your data access logic and your business rules logic shouldn’t be all mixed up in the blender that is your code, but I digress.
You are spot on regarding code reviews, though in my experience they are generally of more benefit to the ’senior’ citizens, I mean developers. The idea should always be knowledge exchange. Learning from the mistakes of others, seeing how they use code, and sharing your expertise, that is what makes developers better, and that is what makes a strong, maintainable code base.
For the last 10 years I have been in the enterprise, so that may explain the difference in our experiences. It is no place for those of us that really care about code. I would guess that you may work at a software company, and your story would ring far truer in that world. That world, unfortunately, is one that I only get to experience evenings and weekends. Not too much longer though, I hope. As is evident in this comment, it is sucking the life out of me.
I would like to add another thing – New programmers should run programs in Debug mode to understand everything step by step and getting the heck of behind-the-scene scenarios which is not possible to understand by simply running the program and jumping around. Every problem has two solutions and the third one works…so always be ready to improvise the baby-face code you write at first sight
No wonder you are a consultant my friend. You are biased and utterly wrong.