Wizard is a typical term we like to throw around when thinking about developers. The parallels are plenty if you think about it wizards are thoughtful, have long beards and are generally considered to be the wisest of the bunch. They also are considered to be cryptic, hard to understand and quite irritable. Of course not all developers are like wizards but it is something we can talk about.
When I started working I saw architects the most developer-y developers there are. They held complex models of the systems we built in their heads, they had technical knowledge that they could summon on demand and they had nice fancy offices with good views. They also weren’t a part of any team, instead they were individual contributors who we’d call to for help or they would come down from their office to lead technical meetings, talk to lead developers then disappear until they’re needed again. That for me was what it meant to reach the pinnacle of being a developer. I spent my first few years trying to be like them, I focused solely on my technical growth, I kept reading, studying and experimenting. Like the architects I knew I developed a “they’re not technical they won’t get it” mentality and I was quite productive.. until I wasn’t.
Apparently it didn’t matter how fast and well I could finish coding things if it wasn’t tested and deployed. I always spoke in technical terms to be more wizardly and it helped me impress my more tenured developer peers but it made me less approachable to everyone else. I realized things had to change I couldn’t be a wizard but I could become a squire.
Squires have a funny reputation, they train in sword fighting but they also do anything and everything their knight requires. They feed the horses, pitch the tents, cook dinner, polish the armor and train in sword fighting. That’s what I needed to do to be a better developer. Coding is my sword fighting, I had to get better at that and I would continue to practice that but it wasn’t my only concern. I also had to work with testers, project managers, designers and requirements analysts. I shifted my focus from trying to be a wizard to doing everything and anything the team needed. I’d talk to testers to learn about how they do and organize tests and I’d sit down with designers to see what they were working on. In time I learned a little bit from everyone and I started being able to help out in things that didn’t involve writing code. Little did I know that what I was doing back then would be what pushes my career forward.
Since then the teams I was on would often do well. It turns out having the ability to talk to and relate to the different roles people had on the team was pretty useful. I could talk about tests with the product owner then switch hats and refine requirements with our product owner. I still grew as a developer but being on teams that did well also did wonders for my career.
Several years later I still consider myself a squire. I’ve discovered that doing whatever my team needed (whether it required me coding or not) was actually the secret sauce to being successful in my career as a developer. See not everyone will have the sheer intellect, grit and ability to become a wizard in the way that we like to imagine the wizard level developers to be. Not all of us will be working on the bleeding edge of technology and research where solving the unsolvable problems is the most important thing. What most of us will be doing are working on products and projects with teams of different team members and that’s when being a squire is most useful. That’s the advice I give to everyone starting out in their career. Stop trying to be a wizard, instead be a squire.