On-Boarding New Team Members
Effective software architecture sketches can help you move faster
Last year I wrote a blog entry called Presentation vs solution that talked about how not being able to communicate your software design in an effective and efficient way has the potential to slow you down. Diagrams are a great way to do this but I've observed, first hand from my training sessions, that communicating a software design through pictures is a skill that many people no longer have.
If you can communicate your software system in an effective and efficient way, you'll shortcut all of the conversation about what the pictures mean from a syntactic point of view and start to focus on the technical aspects of the solution. In other words, you'll start to have more meaningful conversations focussed on what's really important.
While the ability to share information and ideas through visual communication is obviously important throughout the entirety of the software development lifecycle, it's incredibly useful to do this when you're on-boarding somebody new onto your team. In Guiding newbie toward productivity, Nick talks about how he's recently worked with a new team member to get them productive. There are a couple of points of note here. First is the use of simple high-level software architecture diagrams to provide an overview of the software system before diving into the detail, and the second is the way in which Nick led the newbie through the process by letting him drive at his own pace.
My opinion is that the wax-on, wax-off – aka sit and watch me – is not a very good strategy for integrating new team members. I don’t think it provides a good level of business value either.
An interesting read, particularly since Nick's team already does a lot of pair programming, which is also a great way to get people up to speed. Nick's post is certainly one to come back to the next time you're on-boarding somebody new into your software development team.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)