A while back we discussed the unique career path architects have to travel. We wrote that article for developers who want to advance their careers and aren’t sure which way to go. Let’s revisit that path and talk about how you, as a manager or architect, can help developers along the way.
The whole “tabs versus spaces” thing occupies sort of an iconic position in the programmer world. It represents the impossibility of winning arguments that are unwinnable by their very nature. These are so-called religious wars — our techie version of The Butter Battle Book but without the Cold War overtones.
But this and arguments like it rarely actually play out in team rooms and offices. At least, that’s always been my experience. I’ve only ever witnessed live “tabs versus spaces” arguments happen ironically.
Actual Arguments in the Programmer World
So here’s how it really goes down.
You take a job with a company, excited about the new office, the shorter commute, and the bump in pay. You’re riding high. But then the onboarding starts with the codebase.
Greg, the most senior member of the group, walks you through the codebase with a slightly smug affect of obvious pride. The codebase has everything you could ever want, according to Greg. To your mounting horror, this includes
- Inheritance hierarchies that are inscrutable, dark, and deep (with miles to go before you sleep).
- A generous portion of global state.
- Liberal use of reflection, often for no discernible reason.
- And, of course, an extensive, homegrown “framework.”
Greg finishes with a flourish: “So, anytime you need to add a new feature, you just open GodClass.cs, scroll down to line 12,423, add another method, and get started!”
You’re new, and you’re not entirely sure that this isn’t an elaborate prank, so you swallow and say, “Oh…great!” while already planning the lengthy suggestions document that you’re going to put together. And so the stage is set for what will become a never-ending string of arguments of variable politeness about the codebase.
Swap my hypothetical specifics for yours, but the formula is the same. Someone is asking you to exist in a codebase that you have philosophical reservations about, which will force you to write code you don’t like.
Winning Arguments: How Does One Define This?
I’ve now set the stage, but what does it actually mean to “win” an argument? This is pretty hard to define in a lot of contexts, such as people arguing on Facebook about politics or fighting at dinner. Is it the one who got the last word in? The one who was louder? The one who didn’t simply give up?
Luckily, in your quest to de-Greg your new company’s codebase, “winning” is easier to define (if admittedly something of a loaded term). You win if, by mutual consent, however grudging, the thing you think should happen winds up immortalized in the team’s source control. And the mutual consent part matters. Just slamming something into source control and being forced to revert later by an angry Greg doesn’t count.
You win when your argument carries the day and results in concrete action. So let’s look at some techniques for making that more likely.
“I love me some me!”
Yes, there’s more than just an ounce of truth in that statement said by the great NFL receiver Terrell Owens. Terrell loved some Terrell. In fact, if you knew one thing about the man, it’s that he loved himself. Most of us can hide it a little bit better than Terrell, but we’ve all been guilty of this sentiment at one time or another. We suffer from pride and do our best to counteract it with humility. I’ll admit it—as a software developer, after I write a solid, beautiful piece of code, my pride gets a first-class ride on the ego train!
Why start an article about delegation with an eccentric statement about ego? The truth is we’re all good at what we do. We spend time honing our craft, studying our industry, and trying to better ourselves. Eventually, through experience, we’re able to understand and execute on things that less senior developers just can’t. Our peers and managers recognize this, so we begin the journey to the role of leader. And that leadership role doesn’t just entail learning all of the new frameworks and extensions. It also means learning a new set of skills. One of those skills is delegation.
The Quandary of Leadership
When I was first recognized as a leader on my team, the recognition was extremely rewarding. I had worked hard as a developer on this team and naturally stepped into some very minor leadership roles along the way. I was honored to be selected as the team lead, and soon the team was coming to me for direction while the boss was looking to me for updates on how the team was performing.
Rather quickly, I found myself thrust into a lonely middle ground. Management expected me to keep my team on task, and I was also trying to meet my standard deliverables. It was obvious that keeping the team running and efficient required some new skills, and these skills weren’t the kind of things I could obtain by entering commands on my keyboard and getting results.
These were skills that required—gulp—talking to people and finding out what makes them tick. Oh, and guess what? These skills had no tangible output. There was no rewarding pull request with a peer review after finding out that Jack needs a little more help with CSS and could use some training there. There was no successful build notification after discovering that Diane had some issues going on at home and it was starting to impact her work output. While I spent time building relationships with my team members, guess what I was NOT doing? Producing!
All my career to this point was spent producing. Talking and relationships were a side gig that never got much attention, but they unknowingly got me much further along in my career than I like to admit. I always liked to think that I would be promoted on technical merit, but it seems that managers are always looking for the next manager, and the technical merit is just expected.
This transition from producer to leader presented me with a new skill set to learn and start putting into practice.
I can recall a certain day in my career with remarkable clarity.
I say remarkable because this happened well over a decade ago, when I was a relatively fresh-faced software engineer. My manager had called me in for a chat — quarterly review or some such. He said something that stopped me in my tracks.
“Do you want to follow the technical track or the management track in your career?”
I remember panicking. On an otherwise unremarkable morning, I had unexpectedly come to a crossroads in my career. Did I want the organizational clout and higher paychecks of management? Or would I stick with the technical stuff that I so loved?
Of course, this turned out to be a comical overreaction on my part. My answer didn’t, in any way, bind me for life. And the whole thing was something of a false dichotomy anyway.
But it did get me thinking about what I would later regard as the software architecture career path.
And the software architecture career path is what we’ll talk about in this post. This is an interesting and surprisingly complex topic, simply because you have so many flavors of software architect. Let’s take a look at those flavors and their implications for your career.
Download the NDepend trial for free to get feedback on the quality of your code and to help you visualize your codebase.
The Software Architecture Career Path
I certainly wasn’t alone in my confusion over what becomes of programmers as they advance in their careers. Some continue programming indefinitely, while others, eagerly or reluctantly, become managers and climb the corporate ladder.
But the software architecture career path splits the difference in a confusing variety of ways.
I challenge you to find a job title with as much variance as “software architect.” The title itself has many different flavors:
- Software architect
- Application architect
- Technical architect
- Solutions architect
- Enterprise architect
You get the idea.
But beyond the title variance, you also see wide diversity in responsibilities.
- Some architects are literally just programmers with developmental job titles.
- Others are highly technical, mentoring developers and approving of solutions.
- Still others are more like project managers or business analysts. It really varies.
And in this variance lies opportunity. You can take the opportunity to find a role that suits you well in terms of responsibilities while also advancing your career.
For the rest of this post, I’m going to talk about how to take advantage of this opportunity. What skills do you need, and how do you find success?
Bear in mind, I’m also going to describe the different flavors of architects in somewhat broad strokes. The industry doesn’t have a great consensus on what each of these roles really means, so I’m basing this on my own experience.
Whatever you call the different flavors of architect is less important than what they do in their roles and whether the role might suit you.