I had a conversation recently about how much we, as software professionals, have to stay up to date with the ever-changing technology in our industry. We’re constantly learning new technologies and techniques to get products built and shipped to our customers.
Software development is a very fulfilling career for people who like to learn. However, learning the latest technology is a constant challenge and a problem to be solved.
How do developers learn new languages, libraries, and tools more effectively? There aren’t professional organizations telling software professionals what they must do and learn to keep a professional-level certification. Software is just open.
That means it’s on the individual to guide their own learning, which can be overwhelming considering everyone has a different way of learning. For us at Creative Mines, we found that the most effective method for people to learn is within their team framework. Teams are a useful resource for continuous learning because teams are made up of developers who have varying skill sets that can be shared with each other.
It’s similar to a university setting where students form study groups to prepare for their exams. Each student remembers different parts of the lecture and can share that retained knowledge with the group. If each student was to study on their own, they would miss out on the valuable knowledge sharing that takes place within the study group. A software team is like a study group where developers constantly work, learn, and put their skills to the test.
When we talk about teamwork, learning is one of the key values that come out of working as a team.
Building Software Teams to Achieve Success: T-shaped Skills
Let’s examine the importance of organizing teams to maximize opportunities for software professionals to learn and grow. The first step is to identify who’s on the team. Some may say the ideal team consists of senior-level members who have varying experiences, can work independently, and deliver products on time. But it’s hard to find those senior-level developers so teams must be built with a mix of experience levels and diversity within that experience.
In agile software development, we talk about developers with T-shaped skills. T-shaped skills describe a person having deep vertical expertise in a specific area and broad (but not very deep) skills in other relevant areas.
For example, let’s say we have a full-stack developer who has deep experience with React or UI development and just a little experience in Java, Node.js, Python, and DevOps. Having these varying experiences and skillsets is good because they can do work in any area. However, if they were required to build a CD pipeline, they probably can’t do that from scratch because they don’t have deep experience in that area.
When we have developers with T-shaped skillsets, we can put them together to compare different depths. If I’m building a full-stack team, I want someone who’s really deep in React, someone who’s really deep in the backend with Java or TypeScript, someone who’s good at DevOps, and maybe a generalist who’s not that deep in all the areas but has a lot of experience in each of the areas. When I put these developers together on a project, they start naturally learning from each other.
The person who’s really deep in Java is learning so much on the front end, and the person who’s really good at the front end is learning so much on the back end. These developers can quickly become deeper in certain areas because they’re working together.
Opportunities for Learning within the Software Team
On an individual interaction level, how does this knowledge actually get transferred?
In modern software development, we have several useful techniques and practices that transfer knowledge faster than ever. Some of my favorites are pull requests and code reviews.
When a developer submits a pull request for code review, another developer will look at that and identify areas for improvement or share best practices. Whenever work is done, it’s getting immediate feedback through that code review before it’s shipped. This process allows us to develop top-quality code and our developers are able to learn at the same time. When a new team is forming, it helps the developers learn best practices in the different areas of the technology stack.
Before we get to the code review stage, there are opportunities for pair programming. Pair programming is one of these very divisive practices. The first time I encountered it, it was extreme programming, Kent Beck’s model for doing software different in the early 2000s. I actually tried it and was absolutely blown away by it. Sitting next to someone and seeing how they actually develop software was a very visceral feeling. I got to see how they typed, what shortcuts they used, and how fast they can get software written out and built from scratch. That’s something that developers don’t get to experience on their own.
When developers work independently, they only learn what they’re driven to learn. But if they’re sitting next to another developer, then they’re able to see what else is possible.
That developer will become inspired to take the time to better understand their tools and be more effective. That relates to our blog on Craftsmanship: software teams that take the time to learn their tools create high-quality products.
There’s another concept called mobbing, where a whole team works together on one thing, compared to pair programming, where two people sit next to each other working on the same problem. Both of these are extremely effective for communicating and learning. It also creates opportunities for mentorship which is one of the best ways to teach junior-level developers new skills. And mentorship doesn’t even have to be senior to junior. Two seniors could be mentoring each other on a different technology or together explore new technologies they haven’t used before.
Mentorship Opportunities and Providing Slack for Software Teams
So what can individuals do to improve their ability to learn within the teams? They should start asking for mentorship opportunities. Before a new developer goes into code review, they should talk to a senior about expectations.
Each developer should feel empowered to ask questions about their tech stack and the ways they develop code. They should go out and ask if there are other options or better ways to do it. Technology moves fast so either new people need to be brought in to bring new ideas or the current developers need to take time to research, learn, and practice new technologies. By doing so, they’ll be able to bring that knowledge back into the team.
Another great way for teams to learn is to have some form of slack in the process. Slack (no, not the communication tool) is a book written by Tom DeMarco about giving teams the ability to have creative freedom, and not constantly having to hit deadlines. If developers are given some slack in the process, they’ll actually get better quality products because the output of that work is not being rushed to hit deadlines. Building some slack into the process gives developers time to clean up their code or try new technologies.
Even if developers don’t have a bucket of time to go do those things, their company will get a lot of value from giving them the authority to guide some of the work they’re doing. They’ll be able to experiment or take a few days to move over to a new software library. That may result in writing a lot less code in the long run.
Giving software teams the ability to actually control and experiment like that is going to lead to a lot better work product. At the end of the day, the product will be better and the individual is going to be a lot happier. Software teams and learning just go together. In our industry, developers have to learn constantly and a team is the best model for learning.
