in New guy Management Getting Started Lazy Developer SimpleThings backup side projects productivity ~ read.

Why the new guy, even if they are a junior, matters

We have all been juniors at some stage. You enter the job market full of hope that you will change the world and that your programming skills are next level. Within about 5 days of your first job you get cut down to size and you realise that your programming skills are nothing short of sub-standard.

It's not all doom and gloom, hopefully you will be working at a company that has a rough idea how to make you effective and pair you with a mentor.They will take you under their wing and protect you. You, at this stage, think this is just a slight bump in the road and you can still change the world. 6 months later you are confident enough to propose your own idea to the team. More often than not, in my experience, you get shot down. We all have a story.

My story is as follows; I started at a large development house straight out of university filled with cockiness and attitude. I was put on a team that was developing a regulatory reporting system for one of the big banks in South Africa. The team was based in Cape Town and the Product manager was in Johannesburg. It was in maintenance mode and nothing exciting was being developed. It was very Stored Procedure heavy and involved deploying batches of SQL update scripts in a certain order.

We often had to revert our test database back a few batches and re-run the scripts with a new batch of scripts or changes to a batch of scripts. This was a manual process and involved somebody restoring the backup and then kicking off each batch of database scripts one at a time. After a successful batch had run the database needed to be backed up. It could take a good 45 minute to do the whole deployment including the restore. It was great for the rest of us as we would happily go and make coffee and play a bit of pool while we waited. It was not so fun for the one team member who had to kick the next batch off.

If the process errored out in one of the scripts we would fix it and roll back to the last backup. Enter me, the young junior developer, who was full of ideas and had not had his soul destroyed by corporate life. I decided in my spare time write a little application that automated the whole process. The application allowed to revert to any version and then apply the scripts in any order you wished. It did the restoring and backing up of the database at each step.

I asked the technical lead on my team, Roshan Oozer, to run through my code and it was not up to scratch and he provided a good few pointers on how I could improve code. After improving my code and passing the code review I proudly showed the application to the rest of the team who, seemed to me atleast, suitably impressed. After trying it out a few times and verifying the results were the same and we were happy to try it out in the main development process. It seemed to work fine and saved us a lot of time when rebuilding the databases. More importantly the whole team could go play pool and wait.

Our product manager came down from Johannesburg and we showed him the application. He listened to the explanation and then said "oh ok, great but lets stick to the old process". Most the team were surprised by the response but couldn't do much. His lack of a suitable explanation as to why we shouldn't be using it was disheartening

To say this was like being kicked in the face was understating it a bit. I was very despondent after that and felt like my spirit had been broken. I then understood why everyone did the bare minimum. Trying new things were not rewarded but rather frowned upon. I shortly left the company afterwards to start my own thing and even if I had not I would have still looked to move to another company.

At Tranzact,my last job, I was brought in as a junior and there the environment was one of fostering new ideas. I excelled in this role and the company derived great benefit from allowing me to fly and not clipping my wings. I delivered some spectacular things some of which I have blogged about. That doesn't mean I was not shut down a few times, I was, but the manner in which it was conducted was professional. It was explained to me why my idea was an awful one or I was told what needed to be improved.

The two experiences were very different and the results for the team showed the effects. New people to your team are going to bring a different perspective and have the ability to inject freshness into the project. Juniors will have stupid ideas and one or two great ones. It is important for the team to nurture them and more importantly get the good ideas out of them. If their idea or implementation is not correct take the time to explain why and how it could be corrected.

Essentially be a mentor, its not hard nor is it a waste of time. Spend the time listening to the new guy even if he is the junior on the team he might just have the next great idea that will add huge value.