You Can’t Beat Passion!
Originally posted on LinkedIn January 13, 2020
I have been a software developer for more than 25 years, and I have worked with a lot of companies and a lot of other software developers. In fact for 12 years I owned a software dev shop in Calgary that my business partner and I started in 2003.
These days I am hearing more companies say “Oh, well we only hire more senior developers”. On top of that they say it as if I should totally understand, because it is obvious that any “real” work only can be done by someone at the senior level. That is simply not the case.
Essentially what these people think, is that because someone is at a senior level, they can “hit the ground running” and won’t bog the rest of the dev team down with all those pesky questions that inexperienced developers need to ask. After all, their existing dev team is way too busy building software to mentor anyone.
Unfortunately they are missing some valuable information. First of all, there is only a small percentage of software development that requires the “big guns”. In fact, no offence to any senior developers out there, I am one after all, but the longer you have been a developer, the more set you are in your ways. The more you want to do things the way you believe they should be done, and in many cases, the less passion you have for the craft. New developers, on the other hand, have bucket loads of passion. They have just spent a significant amount of time, and in some cases a lot of money, learning the skills and gaining the knowledge to go out in the world and build things. They are ready and excited to be a developer.
When I talk to people about software development I sometimes share my thoughts on what I call the software development skill pyramid. After being asked to create a LinkedIn post so this information can “get out there”, I figured it was time to share.
As I describe this, in your mind please scale accordingly based on the size of your organization. Also, not just scale, but multiply, because for large development teams you will need to look at multiple pyramids, with each one focused on a unique project or an area of development on a larger project.
At the top of the pyramid is your most senior developer. The one you trust to have all the pieces, and who understands the big picture of what you are trying to build. They are typically holding a title with something like senior software architect. That person gets to determine what technologies are used for the project, how things will be architected, commented, source code controlled, tested, rolled out, etc. From a development perspective, they are only going to be working on the really hard stuff and doing some proof of concept work. They will be making sure that everything in the project builds successfully and runs.
On the next level of the pyramid you will want a few of the more experienced, intermediate developers. They can help the software architect manage the structure and assist with the more complicated development work. These people would also help to mentor the junior developers if they get really really stuck.
At the bottom of the pyramid you have a multitude of junior developers. They are the base of the structure and are the most productive. They are also a lot less expensive that the intermediate and senior developers, so you they can work in pairs or teams to help the collective skill set grow. I would encourage shuffling as well so they get experience working with different people. Set boundaries so that they are encouraged to figure things out on their own. If they work on a problem for a specified amount of time and can’t make progress, even after working with the other junior developers, then they have earned the right to ask one of the intermediate developers for help. They will quickly become masters of searching the Internet and coming up with ideas and methods for solving problems. Of course direction can consistently and regularly flow down the pyramid so the entire team always has a path to follow and knows what is expected of them.
Why is this set up so powerful? Well, because it allows a company to optimize its spending for development resources and maintain a highly functional structure. In addition to that work items can be delegated to the team members that are most suited to the task. You don’t waste the time of a senior or intermediate developer working on some basic task that can be accomplished by a junior. The intermediate developers are focused on the more complex tasks that keep them engaged and challenge their minds. The junior developers are incredibly happy to have a spot on the team and are passionate and thrilled to come to work each day. They know that they can work together, which helps out with imposter syndrome, and they want to do a good job so that one day they can be an intermediate and eventually a senior. The intermediate devs get opportunities to mentor, which helps to solidify their own skill set. After all, the best way to learn is to teach!
Why am I so confident in this structure? That is because this is how I ran my company back in 2003. Our teams could program anything and they could do it quickly and well under budget. We proved this over and over again.
Perhaps this is a good point to add in that it also has to do with who you hire for the team. The usual important things like culture, and collaborative personality types make a big difference. Even more so than intelligence or measurable skills. When we hired, we gave each candidate a programming quiz to test their basic development knowledge. However, it is important to note that we didn’t base our hiring on the score they got on the quiz. Instead we looked at HOW they answered the questions. You can tell a lot about how people think, even if they don’t get the answers all correct. Ultimately we built a great team that I was quite proud of.
Thank you for taking the time to hear my thoughts on the topic. Happy developing!
