Early in my software development career, I spent significant time and effort attempting to just figure things out. My degree program wasn’t specific to software development and was fairly new at my university. For some reason, in my Java class, we spent about half our time learning about how the cpu worked instead of focusing on Java. When I did start my first development position, the only developer that offered to mentor me quit in a fairly short time frame. These experiences have shaped my entire career and outlook on IT in general.
I am at the point now where I can walk into an organization and be fairly effective almost immediately. I’ve cycled through enough companies and enough industries that I’ve seen much of what the IT world has to offer and how it is organized. I’m now in management and spend some of my time thinking of how I can take a new developer and avoid all the painful mistakes I made. I have three ideas that I believe are critically important. I’m going to use “he” as a pronoun for brevity. I have known many wonderful female software developers. Please take no offense.
There must be a good mentor in the picture. When a jr. developer is hired into an organization, it’s an entirely new world. Not only must he gain skills in software development and architecture, but he must learn the software product ecosystem and how the business is organized and operates. That’s a pretty tall order. Without some guidance, the new developer will spend untold amounts of hours and money just trying to figure everything out. However, if you have a willing senior level developer (with experience both in software development and the business) to answer questions and guide our intrepid beginner, they will ramp up much more quickly. It’s important to assign a mentor that has a genuine interest in both the company’s success and a need to give back by sharing. The mentor also has to have some serious development chops. It’s worth it to make this choice carefully.
My second suggestion is that the new developer spend some time in another group. That group is devops specifically. Most of us grizzled old software developers have had to spend some time in server administration. We usually spend just enough time to make sure our product works. However, we had some skin in the game and knew how our code got from point A to point B. Most of us have likely automated a deployment process or two. With the rise of the DevOps department, many newer developers never get that chance. If the code runs well on his machine, he ships it and that’s the end of it. Most of the time, these developers end up with a couple of deficiencies.
- He doesn’t consider infrastructure when developing. He needs to be thinking, “How will my code affect the network? How will it affect the database? How will it affect any intermediate services?”
- He makes a poor troubleshooter. Knowing little about the infrastructure, he doesn’t know what could possibly be wrong and can’t be a contributor.
New developers should spend 3-6 months working with devops. He should do deployments as well as learn how to troubleshoot production issues. He should be part of the on call rotation if you have one. He should have the opportunity to configure a new server and learn how your particular virtualization system works. He’ll go back to development with a much different outlook.
My last suggestion is that a new developer also spend some time with your QA group, act least 3-6 months as well. This will be covered more in depth at another time, but if you’re not developing and running automated tests, you should be. Your new developer should have a chance to do everything in the QA group. He should work with the business or developers to gather enough requirements to write a test plan. He should practice writing test plans and getting used to your documentation system. Most importantly, he should write automated tests as well as some unit tests. He should learn the difference between unit, integration, and UI tests. Armed with this knowledge when he goes back to development, his unit tests will be written with quality in mind and not dropped even when the pressure is on to just get the project “done.”
If you take some time and invest in this way with your new developers, they’ll grow quickly and know how to consider the important things when making decisions. They’ll be some of the most effective developers there are down the road.