Save a New Dev, Review His Code

If you read my last post, you would know that I spent a lot of time last month developing for Android. One of the projects is a simple stock widget that uses Google’s deprecated finance API to pull the user’s financial portfolio and display stock data.

To start, the project was pretty simple and not unusual from most of my other projects. This all changed when I ended working with a very new developer that had recently gotten an entry level Java development position with my client. The other developer and I decided that it would be best to split the project in half, since he was pretty comfortable with UI work but didn’t feel as comfortable working with Google’s API.

The project started well enough. I saw some early screens that the dev had created using Eclipse’s UI editor and they looked great. We had a detailed screens doc and my work was ahead of schedule and was on track to be delivered early. In short, it looked like we were going to knock it out of the park. Of course, I am always happy when project goes as well as this one seemed to be going, but I was especially happy for the junior developer, since my first gig was a death march Angry Birds clone and I know how demoralizing a failed first project can be.

There was only one small hiccup. My client’s organization did not have a culture that encouraged code reviews, so I was not permitted to bill for reviewing the other dev’s code, so I naturally didn’t do it; I truly regret this now. Nevertheless, It came time to link up the UI and the business logic. Disaster struck. My poor mentor-less dev had done all of his work with tables. Yup, tables. If you have ever worked on an Android widget, then you know what happened next. The entire UI got thrown out. The client ended up having to go over budget paying me and another dev to get the project done on time. And, the junior developer was fired from his first job after only three weeks of being with the company.

It is easy to say that the developer should have known about the widget table gotcha; after all, he got the job by showing an Android app he done, but isn’t his employer also to blame? Isn’t leaving a junior developer on a project unsupervised for weeks, not allowing his code to be reviewed, and being unwilling to incur the expense required to have him trained by either a more senior employee or the outside contractor on the project with him unreasonable?

The one silver lining in this story is that my client is beginning to hash out some kind of code review policy.

What does your organization do with junior developers? Do they get any sort of training period or are they thrown to the wolves? As always, your feedback is welcome and I can be reached on Twitter and Google+.

Comments are closed.