Stories about Software


Performance Reviews Simplified

If you were to ask people in the corporate world about the most significant moments of their careers, a lot of them would probably talk about annual performance reviews. That’s a curious thing. Anyone who talks about performance reviews when asked this question is not talking about an idea they had that saved the company hundreds of thousands of dollars or about rescuing a project that had gone sideways. Instead, their careers were defined sitting in a room with their managers, going through a worksheet that purports to address how well they’ve matched up against the company’s ‘values.’


Read More


Programmer IS A Career Path, Thank You

If you’re a programmer, think back for a moment to the first time you hear the career question. You know the one I mean, even if you don’t recognize it as the question: “do you see yourself on the architect track or the management track?” Caught off guard, you panic momentarily as you feel that you have about 5 seconds to decide whether your long term future involves lots of UML diagrams and flow charts or whether it involves lots of Power Point presentations and demanding TPS reports from underlings. If you’re like most, and you were to answer honestly, you’d probably say, “neither, really, because I kind of like writing code.” But you don’t give that answer (I never did) because you’d effectively be responding to a career development question with, “I have no interest in career development.” But let’s put a pin in that for a moment.

Imagine a kid going to law school and graduating to go work at a law firm somewhere as an associate, doing whatever it is that associates do. Now imagine a conversation where a partner at the firm pulls this associate aside and says, “so, have you thought about your future? Do you see yourself as more of a partner in the firm, continuing to practice law, or do you see yourself as more of a lawyer-manager?” I imagine the response would be, “what on Earth are you talking about? I’m a lawyer. I want to practice law and be a partner. What else is there?”

Why is it okay (or would it be okay, since this conversation would never actually take place) for an ambitious lawyer to say, “I just want to be a lawyer” and not for an ambitious programmer to say, “I just want to be a programmer?” For the purposes of this post, I’m going to leave that question as rhetorical one. I’m actually going to answer it at length in the book that I’m starting to write, but until the publication date, I’ll leave the why as an exercise for the reader and just posit that it should also be okay for a programmer to say this.

I’d like to see a culture change, and I think it starts with our current generation of programmers. We need to make it okay to say, “I just want to be a programmer.” Right now, the only option is to ‘graduate’ from programming because failure to do so is widely construed as failure to advance in your career. If you become a line manager (or the diet version, project manager), you stop writing code and become the boss. If you become an architect, you kinda-sort-usually-mostly stop writing code and kinda-sort-sometimes-maybe become sorta like a boss. But however you slice it, organizational power and writing code have historically been mutually exclusive. You can play around with teh codez early in your career, but sooner or later, you have to grow up, take your hands off the keyboard, and become a boss. You have to graduate or risk being the metaphorical ‘drop-out’ with the title “Super Principal Fellow Engineer,” who looks great on paper but is generally ignored or smiled at indulgently.


That’s going to change sooner or later. As someone who has looked for work and looked to hire pretty steadily for a number of years, I’ve witnessed an increase in developer salary that is both sharp and sustained. As the average software developer’s wage starts to creep into 6 figure territory, it’s simply not possible to keep the pecking order intact by paying overhead personnel more and more ungodly sums of money. Just as it makes no sense for a law firm billing out at $500/hour to hire a “lawyer manager” as a 1 mil/year cost center, it eventually won’t make sense to pay a quarter million a year to a pointy-hair, when Scrum and basic market forces both offer the allure of a self-managed team. In both cases, overhead work still happens, but it reports to the talent rather than ordering it around and demanding status reports.

How quickly it changes is up to us, though. We can change this culture, and we can change it pretty quickly, I think. The first thing you can do is fix it in your mind that being an “architect” or “project manager” or “manager” isn’t a graduation and it isn’t a rite of passage. It’s an agreement to do something different than what you’re doing now. Nothing more, nothing less. The second thing you can do is vote with your feet.

I’m not advising that you do anything drastic, but rather that you take stock of your circumstances. Are you at an organization where programming is clearly viewed as how you bide time until you get promoted to a boss’s chair? If so, consider adding a new criterion to your next job search. Look for organizations that feature prominent industry figures, such as conference speakers, authors, or people with some “tech celebrity.” These are the organizations that are the “early adopters” of the lawyer/partner dynamic of “best at the trade calls the shots.” If you hook up with these organizations, nobody is going to ask you what “track” you see taking you out of programming. They’ll assume that you’re there because you’re deadly serious about programming as a profession, interested in learning from the best, and interested in subsequently becoming the best.

Sooner or later, we’ll hit some kind of critical mass with this approach. My hope for all of our sake is that it’s sooner. Because the sooner we hit critical mass, the sooner you’ll stop having to explain that doing what you love wasn’t a backup plan for failing to rise in the ranks.


Agile: False Hope and Real Promise

I went shopping for jeans last weekend, which was, as always, somewhat of an aggravating experience. It’s not just jeans, but, really, any wearable thing: shoes, work shirts, belts, even socks. The source of my irritation is the fact that I can’t simply replace items I have that are worn out because the thing you bought last time is always decommissioned. Strangely, major things like cars have better staying power than clothes. There’s a very simple use case missing: As a shoe wearer, given that I love a pair of shoes and thus wear them out in 2 years, I want to go back to the same store and buy the exact same pair of friggin’ shoes so that my life is not interrupted. And the software of life fails to perform.

The reason for this is the nebulous concept of fashion. Naturally, wearable manufacturers and retailers don’t want to be ‘stale’ so they churn things at a rate that prevents me from being pragmatic with my shopping and turns my trips into maddening treasure hunts instead of simple errands. So I contemplate fashion a bit with a natural bias toward annoyance, and this has informed a pretty cynical take on the subject. I have an ongoing hypothesis that the thing that drives fashion isn’t some guy sitting in Paris, saying “I’m going to make those idiots wear really tight jeans this year and then laugh at them.” Instead, its the shifting tectonic plates of poor people trying to look like rich people and rich people trying not to look like poor people.

By way of narrative, guy in Paris releases skinny jeans and charges $700 for them. They’re new and expensive, so rich people buy them so that they can be seen wearing new and expensive things — signaling their wealth and cosmopolitan tastes. Bulk clothing manufacturers start knocking off Paris designer and selling it to the masses for $39 a pair and they sell out like crazy as everyone wants to ape the A list celebrities and influencers wearing these things. Rich people get annoyed that they’re no longer distinguishable on sight and this demand drives Paris guy to dream up some new, weird thing that they can buy to look rich. Rinse, repeat.


This narrative isn’t limited to the arena of rich and poor people with clothes, however. It also extends to things like industry thought leadership and buzzwords. Crowd of cool kids starts doing something and succeeding/making money. They give it a name and everyone rushes to mimic their success, adopting this thing. Imitators adopt it en masse, bring mediocrity and misunderstanding to it, and the cool kids lament that everyone is getting it wrong and that it’s time for another industry shake-up. Queue the “Is {Insert Tech} Dead” link bait and search for the next great thing.

“Agile” is probably the poster child for this sort of thing in the development world. Back around the turn of the millennium, various industry thinkers were experimenting with ways to move software development away from software development practices that mimicked construction and physical engineering since the results produced by this traditional, “waterfall” approach were spotty at best. A group of representatives of some of these experiments came together to find common ground and the result was called, “The Agile Manifesto.” In the interceding 13 years, the industry has come to accept that the Agile approach is “the right thing” while agreeing that, by and large, no one does it right.

Off the top, I’ve heard the following expressed recently (paraphrased from my recollection):

  • Agile is dead.
  • Scrum is a scam that makes grunts stand while they deliver their status reports.
  • If XP doesn’t work it’s because you’re doing it wrong.
  • Agile is stupid because you really can’t work sanely without comprehensive documentation and specs.
  • Agile is a marketing gimmick to create phony demand for meaningless certifications.

And yet, you’d be hard-pressed to find any non-agile shop that didn’t look down shamefacedly and mumble “yeah, we do waterfall.”  So, the reasonable conclusions from this are:

  • Waterfall (or pseudo-waterfall things like RUP) are really out of style.
  • Agile is mainstream, but the real fashionistas are so over it because everyone’s messing it up and ruining it.
  • Cool kids are looking for what’s next: a post-Agile world.

Agile, Distilled

I’m not certified in Scrum or XP or anything else. I have no project management credentials and no letters after my name. I certainly have experience in these methodologies and understand the ceremonies and the roles, but I’d hardly count myself an encyclopedia of how everything should operate. It’s always bemused me that arguments emerge over the finer points of the exact approaches to these methodologies and that people can actually be certified in exact adherence when the focus of the Agile Manifesto seems to me to be best summarized by the idea of bringing pragmatism and empirical experimentation to software development. But, opportunities for snark notwithstanding, it’s easy to see why people become disillusioned. Anytime there is some sort of process and any failures are blamed on a lack of true, absolute adherence, you have a recipe for quackery.

But at it’s core, I think Agile methodologies can be distilled to a single compound principle: tighten the feedback loop and improve the feedback. Think about the different things that are done in various flavors of agile: automated testing/TDD, short sprints, pair programming, retrospectives, big/visible charts, etc. All of it is about delivering feedback faster, delivering feedback more obviously, and acting quickly on the feedback. This is really, really non-controversial. The sooner you get feedback on what you’re working on, the sooner you can improve. So, where does everything go off the rails?

Is it that things don’t go well because people aren’t following the processes right? Is it that the processes themselves are broken? Is it that the processes are good, but a bunch of hucksters are peddling fools’ gold? Is it that people are just too entrenched in their ways to be compatible with these principles? Personally, I don’t think it’s any of this. I think that the fundamental problem is one of expectations (though some of the hucksters do nothing to mitigate this). Specifically, I think the main source of woe is the assumption that “going Agile” will cure what ails you because the only thing standing between the broken, over-budget pile of crap you’re about to ship and software nirvana is having a different set of meetings and adopting a different desk arrangement. The Agile promise isn’t realized by tweaking process; it’s realized by getting a scheme in place for receiving meaningful feedback and using that feedback, with a lot of practice, to get better at making software.

10,000 Hours

Wait, what? Practice? That doesn’t have anything to do with Kanban boards, swim lanes, stand-ups, and all of the other Agile stuff that gets so much focus. In the words of the esteemed Alan Iverson, “What are we talking about? Practice? We’re talking about practice, man.” The wide world is talking about the magic dust you can sprinkle on a team to make it crank out better software, faster, and I’m in here talking about practice.

During my semi-weekly drive to Detroit, I’ve been listening to audio books, including, most recently, Malcom Gladwell’s “Outliers.” Without offering up too much of a spoiler, one of the things that he talks about is that people like Bill Gates don’t reach the incredible levels of success that they do by being dominant in a vacuum, but rather they combine incredible fortune and opportunity with cleverness, ingenuity and a whole lot of really hard work. Bill Gates was born at a time where him being a teenager coincided with the very first machines that allowed for desktop based computing, rather than punch cards. He had the incredible good fortune of gaining access to such a computer in the late 60’s, as a teenager, when almost no adults or professionals on Earth had such access. Addicted to the fun of programming, he worked nights and weekends during his teenage years, programming, at a time when few others in the world had that opportunity. By the time he was an adult, ready to start Microsoft, he was one of the few people on Earth with 10,000 hours of experience programming this way.

The hypothesis for which the book is best known is that 10,000 hours of deliberate practice is the general average amount of time put in before a person acquires mastery of a field. As I understand it, there has been some corroboration of this hypothesis as well as some counter-evidence, but the broad point remains that achieving mastery requires a whole lot of deliberate work and concerted, sustained effort to improve. You know how you get really good at delivering software? Do it for years and years, constantly learning from your mistakes. You know how you don’t get really good at delivering software? By having slightly different meetings, shipping crap more frequently, and hoping for different results.

The way I see it, big A Agile, at its core, is not about fixing you or your software. It’s about making your practice more meaningful and efficient. To return to the basketball metaphor, Agile isn’t a weekend retreat that turns you into Michael Jordan. It’s a weekend retreat that shows you how to do a bunch of layup and dribbling drills that, after 10,000 hours of practice, will make you pretty good, as long as you keep challenging yourself. The great shame of Agile or any other kind of movement is that of false hope in easy fixes. Done well, it will expose your pain points more quickly, provide you with tools for removing obstacles, illuminate a path to improvement, and show you how to self-evaluate regularly. But it won’t make you awesome. Only practice and continuous learning will do that.


Asking Questions That Change The World (Or At Least Your Group)

I recently asked a semi-rhetorical question on Twitter about health insurance in the USA. Specifically, it seems deeply weird to me that health insurance is tied in with employment. I mean, your employer doesn’t subsidize your homeowner’s, auto, or renter’s insurance, so why health insurance? Someone answered that this was an end-run around salary caps and restrictions that just kind of stuck around. This rang a bell, and I looked it up. Here’s an explanation that details how caps on wages during WWII were circumvented by offering this perk and making it tax deductible, and so a long, nonsensical tradition was born, established, and worked into our culture to a degree where everyone thinks, “that’s just the way things work.”

Many people respond to hearing questions of “why do we do this, anyway,” with something like, “hey, yeah, that’s a good question!” Once it’s pointed out to them, they recognize that perhaps an entrenched practice is worth questioning. Others balk at the notion and prefer doing things that are traditional, well, just because we’ve always done it that way. There seems to be something about human nature that finds ritual deeply comforting even when the original reasoning behind it has long expired. White dresses on wedding days, “God bless you” after sneezes, using signatures to indicate official permission, and many more are things that we simply do because it’s what we know, and if someone asked you “why,” you’d probably say, “huh, I don’t know.”

In this manner, software engineering resembles life. Within a group, things that originally had some purpose, reasonable or misguided, eventually become part of some unquestioned routine. I’ve seen shops where everyone was forced to use the same diff tool, where try-catch blocks were required in every single method, where every class had to implement IDisposable, and more, for reasons no one could remember. Obviously, this isn’t good. In life, tradition probably has an anthropologically stabilizing role about which I won’t speculate here, but in a software group, there’s really no upside.

Accordingly, I don’t want to team up with people that blindly follow cargo cult processes. It’s bad for the team. But who do I want on a team? It isn’t just people that are willing to forgo routines and rituals when they’re called into question and evaluated. I want people that think to do the questioning in the first place.

Don’t get me wrong. I’m not looking for iconoclasts that question everything whether or not there’s reason to question it or that rail against everything that others want to do. I’m looking for people that take no assumptions on faith and are constantly using data and objective metrics to reevaluate the validity of everything that they’re doing, even when those things are regarded as “no-brainers.” I want people that get creative when solving problems, expanding their thinking beyond obvious approaches and into the realm of saying “what if we could do it without doing this thing that we ‘have’ to do?”

It’s this kind of thinking that gave rise to NoSQL; what if a relational database weren’t required for every application? It’s this kind of thinking that turned the internet from a way to view documents into an application medium; what if there were applications that didn’t require CDs and installers? It’s this kind of thinking that changes the world, in software and in life. I want people on my team that wonder why their employer pays for their insurance, anyway.


The Value of Failure

Over the course of time leading people and teams, I’ve learned various lessons. I’ve learned that leading by example is more powerful than leading by other attempts at motivation. I’ve learned that trust is important and that deferring to the expertise of others goes a lot further than pretending that you’re some kind of all-knowing guru. I’ve learned that listening to people and valuing their contributions is vital to keeping morale up, which, in turn, is vital to success. But probably the most important thing that I’ve learned is that you have to let people fail.

My reasoning here isn’t the standard “you learn a lot by failing” notion that you probably hear a lot. In fact, I’m not really sure that I buy this. I think you tend to learn better by doing things correctly and having them “click” than by learning what not to do. After all, there is an infinite number of ways to screw something up, whereas precious few paths lead to success. The real benefit of failure is that you often discover that your misguided attempt to solve one problem solves another problem or that your digression into a blind alley exposes you to new things you wouldn’t otherwise have seen.

If you run a team and penalize failure, the team will optimize for caution. They’ll learn to double and triple check their work, not because the situation calls for it but because you, as a leader, make them paranoid. If you’re performing a high risk deployment of some kind, then double and triple checking is certainly necessary, but in most situations, this level of paranoia is counter-productive in the same way it is to indulge an OCD tendency to check three times to see if you locked your front door. You don’t want your team paralyzed this way.

A paranoid team is a team with low morale and often a stifled sense of enjoying what it does. Programming ceases to be an opportunity to explore ideas and solve brain teasers and becomes a high-pressure gauntlet instead. Productivity decreases predictably because of second-guessing and pointless double checking of work, but it’s also adversely affected by the lack of cross-pollination of ideas resulting from the aforementioned blind alleys and misses. Developers in a high pressure shop don’t tend to be the ones happily solving problems in the shower, stumbling across interesting new techniques and having unexpected eureka moments. And those types of things are invaluable in a profession underpinned by creativity.

So let your team fail. Let them flail at things and miss and figure them out. Let them check in some bad code and live with the consequences during a sprint. Heck, let it go to production for a while, as long as it’s just technical debt and not a detriment to the customer. Set up walled gardens in which they can fail and be relatively shielded from adverse consequences but are forced to live with their decisions and be the ones to correct them. It’s easy to harp on about the evils of code duplication, but learning how enormously tedious it is to track down a bug pasted in 45 different places in your code base provides the experience that code reuse reduces pain. Out of the blind alley of writing WET code, developers discover the value of DRY.

The walled garden aspect is important. If you just let them do anything at all, that’s called chaos, and you’re setting them up to fail. You have to provide some ground rules that stave off disaster and then within those boundaries you have to discipline yourself to keep your hands off the petri dish in order to see what grows. It may involve some short term ickiness and it might be difficult to do, but the rewards in the end are worth it — a happy, productive, and self-sufficient team.


I’m Hiring, So Here’s a Job Description

Let me start off by saying that I actually want to hire someone. This isn’t a drill nor is it some kind of hypothetical exercise. I have a real, actual need for .NET software developers and if you are interested in such a job and think that it could be a good fit, please let me know (more details to follow). I think that the pool of people that keeps up with software blogs is the best pool of people there is from which to draw candidates, and I’d go ahead and extend this to the people who run in your circles as well. If you care enough to follow blogs about software, you’re probably the kind of person with whom I’d like to work.

So, the first thing I did was to go and see what was going on at CareerBuilder, Dice, et al. so that I could get some ideas for writing up a job description. I was literally on the second one when I remembered how awkward and silly I find most job descriptions. This bad boy was what confronted me:


I was reminded of Blazing Saddles.

Hedley: Qulifications?
Company: NoSQL, Communication Skills, Scala, Communication Skills
Hedley: You said “communication skills” twice.
Company: I like communication skills.

But notwithstanding the double-ups and rambling nature of this and the fact that probably only Horse Recruiter could write it, the ideal candidate has, by my quick count, 27 line items of 1 or more properties. That’s quite a wish list. I’d rather describe what I need like a human being talking to another human being. And, because I’d rather talk like a human being to other human beings, what I’ll start off by doing is describing what we have to offer first, and then what I’m asking in exchange. I think “what we offer” is far too frequently overlooked, and omitting it creates the impression that I think I’m on the Princeton admissions panel for undergraduates, rather than a guy on a team that needs to grow to handle the amount of work we have.

What We Are and What We Offer

Given that this is my personal blog and not affiliated with my 9-5 work, I’m not going to go into a lot of detail about the company, per se. I’ll supply that detail if requested, and you can always look at my Linked In profile — it’s no secret what I do or for whom. Instead, I’ll talk about the group and list out what I think makes it appealing.

We’re a small, agile team and a close knit group. We work exclusively in the .NET space, with a mix of database, application and client side code. Working with us, you would definitely touch Winforms, ASP Webforms, and ASP MVC. We are actively porting Winforms/Webforms functionality to an MVC application. Here are some benefits to working here, as I see them:

  • We follow Scrum (not Scrum-but — actual Scrum)
  • We have MSDN licenses, and we upgrade to the latest developer tools as they are released.
  • You will have creative freedom — we’re too busy for micromanagement.
  • There are definitely growth opportunities for those of you looking to go from developer to senior developer or senior developer to architect.
  • We have nice tooling for Visual Studio development, including NCrunch and CodeRush.
  • Everyone on the team gets a Pluralsight subscription because we believe in the value of personal growth and development.
  • Along the same lines, we have bi-weekly lunch and learns.
  • We have core hours and you can flex your schedule around them.
  • There is no bureaucracy here.  You will never have to write 6 design documents to be approved by 4 committees before you start writing useful code.
  • We practice continuous integration and deployment (the latter to a staging environment)
  • We are at a 10.5 on the Joel Test and climbing.
  • Not software related, but we’re located in Chicago within walking distance from a train stop.

Who Would Be a Good Fit?

Let me preface this with the important distinction that there is no “ideal software engineer” and there is no concept of “good enough” or anything silly like that. We need to ship code and do it quickly and well, and I’m going to look at a bunch of resumes and talk to a bunch of people and then I’m going to take a leap of faith on a person or couple of people that I think will best compliment the team in its goal of shipping code. That’s really all there is to it. You may be the best developer of all time, and I might get this process and wrong and whiff on you as a candidate, and it’s no shortcoming of yours if that happens. I will certainly try my best not to do that, however.

Senior Software Engineer

So, I will now describe the what I think would make someone the best fit for our group. First of all, I’ll describe what we’re looking for in terms of a more experienced, “senior level” candidate, and I’ll describe it quite simply in terms of what I’d be thrilled if I had someone reporting to me doing and doing well.

  • Contribute immediately to a set of different .NET solutions.
  • Can explain sophisticated concepts to less experienced team members, such as generics, lambda expressions, reflection, closures, etc.
  • Lead by example in terms of writing clean code and explaining principles of writing clean code to other developers.
  • Understand Software Craftsmanship principles like SOLID, unit testing/TDD, good abstractions, DRY, etc, well enough to explain to less experienced developers.
  • Versed in different architectural patterns, such as layered and “onion” architectures, as well as Domain Driven Design (DDD).
  • Taking responsibility for and improving our build, ALM setup, source control policies (TFS), and deployment procedures.  We have a good start, but there’s so much more we can do!
  • Can write ASP and the C# to support it in Webforms or MVC, but prefers MVC philosophically.
  • Understands client-server architecture and how to work within that paradigm well enough to explain it to developers that don’t.
  • Is comfortable with or can quickly get up to speed with REST web services and SOAP services, if the latter is necessary.
  • Is comfortable with SQL Server tables, schema, views, and stored procedures.
  • Knows and likes Entity Framework or is willing to pick it up quickly.

Software Engineer (Web)

The other profile of a candidate that I’ll describe is a software engineer with a web background. Again, same description context — if I had someone doing these things for me, I’d be very happy.

  • Come in and immediately start on work that’s piled up with CSS and client-side scripting (jQuery, Javascript) that improves the site experience for some of our sites.
  • Understands C# and server side coding well enough to implement run of the mill features with normal language constructs without asking for help.
  • Good at hunting down and isolating issues that may crop up when there are lots of moving parts.
  • Is aware of or is willing to learn about and explain various model binding paradigms both on the server (MVC) and client (various javascript frameworks).
  • Has a flare for design and could help occasionally with custom branding and the UX of websites.
  • Not a huge fan of Winforms, but willing to roll up your sleeves and get dirty if the team needs help with legacy desktop applications on some sprints.
  • Up for picking up and running with a more specialized skill to help out, such as working with T4 templates, customizing TFS workflows, experimenting with and leveraging something like Signal R, etc.
  • Some experience with or else interest in learning unit testing/TDD as well as clean coding/decoupling practices in general.

Logistical Details and Whatnot

So therein are the details of what I’m looking for. It seems like I’m flying in the face of billions of job ads and thousands of horse recruiters with this approach, and far better minds than mine have probably dedicated a lot of consideration to how to solicit candidates to come interview and how to put together the right set of questions about O notation runtime of quicksort and whatnot. But still, I feel like there’s something humanizing to this approach: this is what we have to offer, this is what would benefit our group, and perhaps we could work together.

In terms of location, I prefer to consider people local to the Chicagoland area or those who are willing to relocate here, but telecommute situations are not ipso facto dealbreakers. If you’re interested in one of these positions or someone you know is interested, please send me or have them send me an email at erik at daedtech, and we’ll take it from there. I’m not exactly sure when I’ll start interviewing, as there are still some internal details to hammer out, but I definitely wanted to give the blog-reading set of developers and people I know the first bite of the apple before I started going through the more common and frustrating channels.

And, also, in a more broad philosophical sense, I wanted to try to put my money where my mouth is a bit. After taking potshots in previous posts at job descriptions and interview processes, I thought it’d be the least I could do to put my own approach out there so as not to be the negative guy who identifies problems and offers no solutions.


Notes On Job Hopping: You Should Probably Job Hop

Last week, in a post that either broke the Google+ counter mechanism or blew up there in very isolated fashion, I talked about job hopping and meandered my way to my own personal conclusion as to whether it might be construed as unethical. I don’t think it is. Today I’d like to talk a bit about practical ramifications for the individual, as promised at the end of that post.

The title of this sounds like link bait, but that’s not really more my goal. I wrote the post without giving it a title and then reread it. This title was the only thing that I could think to call it, as I realized, “wow, I guess I’m recommending that people job hop.”

A Scarlet J

Conventional wisdom holds that there is some kind of sliding scale between loyal employee and job hopper and that you get into a bit of a danger zone if you move around too much. Everyone can really imagine the scenario: you’re in an interview and the interviewer awkwardly asks, “since you seem to switch jobs a lot, how do I know you’d stay here long enough for the hire to be worthwhile?” And you’d fire a blank at this point, you job hopper, you. You’d be unable to convince this hiring authority to take a chance on you. And what’s worse is that this would be a common reaction, getting you turned down in interviews and probably even tossed from a number of resume piles in the first place. You have a scarlet J on your chest, and nothing but time will remove it.


If, on the other hand, you opt for the loyalty route and keep the number of job changes pretty minimal, you’ll have no trouble finding your next job. Without that scarlet J, the townsfolk are more than happy to give you an offer letter. They figure that if you’ve spent a decade at Initech, you’re likely to spend the next decade working for them. And, really, what could be better for them? Everyone knows that turnover is expensive. There are training periods and natural inefficiencies to that concept; it’s just a question of how bad. If Bob and all of his tribal knowledge walk out the door, it can be a real problem for a group. So companies look for unfaithful employees, but not employees that are unfaithful too often — otherwise the awkward question arises: “if he’ll cheat on his old company with me, how do I know he won’t cheat on me with Initrode?”

Apparently, there’s a line to straddle here if your eye starts wandering. Job transitions are a finite resource, so you’d better make them count. But that’s not exactly a reason not to job hop, but a reason not to do it too often. It’s the difference between having a few cold ones on the weekend and being Kieth Richards, and I’ll come back to this point later. But, in the meantime, let’s look at some reasons not to change jobs.

Should I Stay…

One of the biggest reasons people stay at a job is simple inertia. I’m listing that first because I suspect it’s probably the most common reason. Even though a lot of people don’t exactly love their jobs, looking for a new job is a hassle. You have to go through the interview process, which can be absurd in and of itself. On top of that, it typically means awkward absences from work, fibbing to an employer, getting dressed up, keeping weird hours and putting in a lot of work. Job searching can be a full-time job in and of itself, and the prospective job seeker already has a full time job. And if job searching weren’t enough of a hassle, there’s a whole slew of other issues as well. You’re trading what you know and feel comfortable with (often) for the unfamiliar. You’re leaving behind a crew of friends and associates. You’re giving up your seniority to become the new guy. And none of that is easy. Even if you decide in the abstract that you’re willing to do all of that in the abstract, it’s likely that you’ll put it off a few more weeks/months — and keep putting it off.

Another common and more uplifting reason to stay at a position is due to a high rate of job satisfaction. I think this is less common than simple inertia, but it’s certainly out there. Perhaps you spent the early part of your career doing help desk support and all you ever wanted was a shot at uninterrupted programming in a R&D outfit, and now you have that. Maybe you’ve always wanted to work for Microsoft or Facebook or something, and now you’re there. You’d pass on more lucrative offers or offers of more responsibility simply because you really want to be doing what you’re doing, day in and day out. Genuinely loving one’s job and the work there is certainly a reason not to job hop.

I think that a decreasingly common reason for staying put is loyalty to a company. I observe this to a degree in the boomer set, but it’s not common among gen-Xers and is nearly nonexistent among millennials. This is a desire to stick it out and do right by a company instead of leaving it high and dry. It may take on the form of the abstract loyalty to the company itself, or it may be loyalty to a boss and/or coworkers. (“I’d hate to leave now, they’d be so screwed if I took off that I can’t do it to them.”) I personally view this as a noble, albeit somewhat quixotic, sentiment, tinged with a form of spotlight effect bias. I think we tend to radically overvalue how high and dry an organization would be without our services. Businesses are remarkably good at lurching along for a while, even when understaffed or piloted by incompetents.

Rounding out the field of reasons that I’ll mention is a more specialized and less sympathetic form of inertial (and perhaps even loving your job), which is the golden handcuffs. You’re an Expert Beginner or the “residue” in the Dead Sea Effect, and your company drastically overvalues you both in terms of responsibility and pay. To put it bluntly, you stay because you have no choice — you have a relatively toxic codependent relationship with your employer.

There are certainly other conceivable reasons to stay at a job, but I think that you might loosely categorize them into these four buckets and cover the vast majority of rationales that people would cite. So if these are the reasons to stay, what are the reasons to go? Why does jumping from job to job make sense?

Or Should I Go?

First off, let’s talk money. If you stay in place at a run-of-the-mill job, what probably happens is that every year you get some kind of three percent-ish COLA. Every five years or so, you get a promotion and a nice kick, like five to ten percent. If, on the other hand, you move jobs, you get that five to ten percent kick (at least) each time you move. So let’s follow the trajectory of two people that start out making 40K per year out of college as programmers: one who hops every two years and one who stays loyal. Let’s assume that the hopper doesn’t get COLAs because of when he’s hired at each position. We’ll just give him ten percent kicks every two years, while his loyal peer gets three percent COLAs every year as well as the ten percent kicks. The loyal guy is making 61.3K at the end of ten years, while his job-hopping friend is making 64.4K. If we were to add in the COLAs for the hopper, because he timed it right, that balloons to 74.7, which is almost 25% more than his friend. Neither of those salaries may seem huge, especially given all of the turmoil in the hopper’s life, but consider that for the rest of your career, there’s no bigger determining factor of your salary than your previous salary, and consider the principle of compound interest. Even assuming that after year ten both people in this thought experiment make the exact same career moves, the difference between their salaries and net worth will only continue to widen for the rest of their lives. It pays to job hop. Literally.

In fact, I might argue that the case I just made above is actually somewhat muted because of another job-hopping-related consideration: career advancement. Before, we were just talking about what probably amounts to token promotions — the loyal guy was “software engineer III” after ten years, while his hopper friend was now “software engineer V.” But here’s another thing that happens when you hop: you tend to accumulate more impressive-sounding titles, kicking off a chicken-egg kind of scenario about qualification and title. What I mean is that you don’t just number positions like job shifts, but you start to rack up qualifiers for title like “senior” or “lead” or “principal.” So now our two subjects are a software engineer making 60K and a lead software engineer making 75K, respectively. Which one of these do you think is likely to get promoted to management or architect first? Done right, job hopping earns you better pay and better titles, which earn you still more pay.

Related to this skipping around for better circumstances is the middling corporate narrative that the job hopper is escaping — specifically one of “dues paying.” For a bit of background on this concept as it relates to programmers, take a read through section 5, “Career Development,” in Michael O. Chruch’s post about what programmers want. Dues-paying cultures are ones in which advancement is determined not by merit but by some kind of predetermined average and set of canned expectations. For instance, if you hear things from companies like, “we don’t hire lead architects — we only promote from within to that position,” or, “we don’t offer development promotions more than once every three years,” you have a dues-paying culture on your hand. Call it what you will, but this is essentially a policy designed to prevent the mediocre, tenured natives from getting restless. It seems insanely childish and petty, yes. But I have personally witnessed plenty of cases where person X with ten years of time with a company had a hissy fit because someone got to engineer level IV in three years when it took person X four years to get there. Enough tantrums like that and promotion governors are slapped on the engine of advancement at the company, and dues-paying periods become official.

But this need not concern the job hopper, who won’t be around long enough to play this game anyway. This is a win on two fronts for him. It’s an obvious win because he promotes himself within a year or two instead of waiting three or four for the HR matrix to catch up. He also avoids the endowment effect of earning his way past the dues-paying rope. In other words, if he did stay around long enough to ‘earn’ the coveted lead architect title, he’d overvalue it and stick around even longer to savor it because he’d be thinking subconsciously, “being a lead architect at this awesome company is truly amazing or else I wouldn’t have twiddled my thumbs all these years waiting for it.” He’d be a lot more likely to stick around for the even more coveted (at that organization) “super lead architect” position that one can only ‘earn’ after another four years.

Speaking of empty titles, there is another powerful argument in favor of job hopping: avoiding and minimizing interaction with Expert Beginners. On the more obvious front, jumping around helps you avoid becoming an Expert Beginner since you can’t build seniority capital of questionable value to use in lieu of well-reasoned arguments or genuine skill. If you’re bouncing around every year or two, you can’t start arguments with “I’ve been here for 20 years, and blah, blah, blah.” But a willingness to job hop also provides you with an exit strategy for being confronted with Expert Beginners. If you start at a place and find some weird internal framework or a nasty, amorphous blob of architecture and the ranking ‘experts’ don’t seem to see it as a problem, you can just move on. Your stays will be longer at places that lack Expert Beginnerism in their cultures and shorter at places with particularly nasty or dense Expert Beginners. But whatever the case may be, you as a job hopper will be the water evaporating in Bruce Webster’s metaphor, refusing to put up with organizational stupidity.

And putting up with organizational stupidity is, in fact, something of a career hazard. Job hopping gives you a sort of career cross-pollination that hanging around at the same place for 20 years does not, which makes you a lot more marketable. If you work somewhere that has the “Enterprise Framework,” it’s likely you’ll spend years getting to know and understand how some weird, proprietary, tangled mess of code works in an incredible amount of detail. But in the market at large, this knowledge is nearly useless. It only holds value internally within that organization. And, what’s more, if you have a sunk intellectual property cost at an organization in some gargantuan system written in, say, Java, you’re going to be pretty unlikely to pick up new languages and frameworks as they come along. Your career will be frozen in amber while you work at such a place. There are certain types of organizations, such as consultancies, where this is minimized. But if you doubt the effect, ask yourself how many people out there are cranking out stuff in Winforms or even VB6.

What To Do?

We can summarize the pro arguments for job hopping as money; advancement; avoiding mediocre, dues-paying cultures; avoiding Expert Beginners and organizational stupidity; and being marketable. On the other side, we can summarize the con arguments for job hopping by tagging them as inertia, satisfaction, loyalty and golden handcuffs. You’ll notice that I didn’t mention the stigma in either category, even though that’s ostensibly a clear negative. (I will return once again to the stigma angle in the third and final post in this series that addresses the future of job hopping). This is because I view the stigma as neutral and a simple matter of market realpolitik.

When are you most likely to be branded with the scarlet J — scratch that — when is the only time that you’ll be branded with that scarlet J? Obviously, while you’re applying and interviewing. You’ll be working at Initech and considering a switch to Initrode, and Initrode takes a pass on you because you seem to skip around too much. So you just keep working at Initech and put in another year or two to let the stigma fade. As long as you don’t quit (or get laid off) without something else lined up, the job-hopper stigma really doesn’t matter. It happens when it happens, and you actually have a peek-ahead option to find out that it’s about to happen but without dire consequences (again, assuming you aren’t laid off and are generally competent).

And really, this makes a certain kind of sense. I have, in the past, been told to stay put in a situation I didn’t like for fear of acquiring a scarlet J. People were advising me to stay in a situation in which I was unhappy because if I got out of that situation I might later be unhappy again and this time unable to move. Or, in other words, I should remain definitely unhappy now to avoid possibly being unhappy later. That strikes me as like sitting at home with a 105 degree fever because the ambulance might crash on the way to the hospital and put my health in jeopardy. The stigma argument seems actually to be something of a non-starter since, if it happens, you can just wait it out.

So, on to the million dollar question: should you job hop? Unless you’re happy where you are, I don’t see how the answer can be anything but “yes.” The “no” arguments all involve personal valuations — with the exception of “golden handcuffs,” which really just means that job hopping is impossible because you missed that boat. Are you too busy with family to conduct a job search? Do you really like your coworkers and working environment? Do you love the work that you’re doing right now? Do you really love the company? I can’t lobby for personal decisions like that in people’s lives, and there is certainly more to life than career advancement, money, and responsibility.

But in terms of objective considerations like money, position and title, there’s really no argument. Job hopping will advance you more quickly through the ranks to better titles, paychecks, and career opportunities in general. You will have more breadth of experience, more industry contacts, more marketable skills, and more frank and honest valuations of the worth of your labor. Companies are generally optimized to minimize turnover, and if you want a path that differs from steady, slow, measured advancement, staying in one place isn’t in your best interests. Should you job hop? I say absolutely — as often as your personal life and happiness will allow, and as long as you manage to avoid the scarlet J. I’d imagine that at some points in your career you’ll settle in for a longer stay than others, and perhaps eventually you’ll find a calling to ride out the rest of your career in a place. But I think that you ought to spend your career always ready to trade up or to change your scenery as often as necessary to keep you moving toward your goals, whatever they may be.


Seeing the Value in Absolutes

The other day, I told a developer on my team that I wouldn’t write methods with more than three parameters. I said this in a context where many people would say, “don’t write code with more than three parameters in a method,” in that I am the project architect and coding decisions are mine to make. However, I feel that the way you phrase things has a powerful impact on people, and I believe code reviews that feature orders to change items in the code are creativity-killing and soul-sucking. So, as I’ve explained to people on any number of occasions, my feedback consists neither of statements like “that’s wrong” nor statements like “take that out.” I specifically and always say, “that’s not what I would do.” I’ve found that people listen to this the overwhelming majority of the time and, when they don’t, they often have a good reason I hadn’t considered. No barking of orders necessary.

But back to what I said a few days ago. I basically stated the opinion that methods should never have more than three parameters. And right after I had stated this, I was reminded of the way I’ve seen countless conversations go in person, on help sites like Stack Overflow, and in blog comments. Does this look familiar?

John: You should never have more than three parameters in a method call.
Jane: Blanket statements like that tend to be problematic. Three method parameters is really, technically, more of a “code smell” than necessarily a problem. It’s often a problem, but it might not be.
John: I think it’s necessarily a problem. I can’t think of a situation where that’s desirable.
Jane: How about when someone is holding a gun to your head and telling you to write a method that takes four parameters.
John: (Rolls his eyes)
Jane: Look, there’s probably a better example. All I’m saying is you should never use absolutes, because you never know.
John: “You should never use absolutes” is totally an absolute! You’re a hypocrite!
Both: (Devolves into pointless bickering)

A lot of times during debates, particularly when you have smart and/or exacting participants, the conversation is derailed by a sort of “gotcha” game of one-upsmanship. It’s as though they are at an impasse as to the crux of the matter, so the two begin sniping at one another about tangentially-related or totally non-related minutiae until someone makes a slip, and this somehow settles the debate. Of course, it’s an exercise in futility because both sides think their opponent is the first to slip up. Jane thinks she’s won this argument because John used an absolute qualifier and she pointed out some (incredibly preposterous and contrived) counter-example, and John thinks he won with his ad hominem right before the end about Jane’s hypocrisy.

In this debate, they both lose, in my opinion. I agree with John’s premise but not his justification, and the difference matters. And Jane’s semantic nitpicking doesn’t get us to the right justification (counter or pro), either. Prescriptive matters of canon when it comes to programming are troubling for the same reason that absolutes are often troubling in our day-to-day lives. Even the most clear-cut seeming things, like “it’s morally reprehensible to kill people,” wind up having many loopholes in their application (“it’s morally reprehensible to kill people — unless, of course, it’s war, self-defense, certain kinds of revenge for really bad things, accidental, state-sanctioned execution, etc., etc.”). So for non-important stuff like the number of parameters to a method, aren’t we kind of hosed and thus stuck in a relativistic quagmire?

I’d argue not, and furthermore, I’d argue that the fact of the rules is more important than the rules themselves. It’s more important to have a restriction like “don’t have more than three parameters to a method” than it is to have that specific restriction. If it were “don’t have more than two method parameters” or “don’t have more than four method parameters,” we’d still be sitting pretty. Why, you ask? Well, a man named Barry Schwartz coined this phrase: “the paradox of choice: why more is less.” Restrictions limit choice, which is merciful

Developers are smart, and they want to solve problems — often hard problems. But, really, they want to solve directed problems efficiently. To understand what I mean, ask yourself which of these propositions is more appealing to you: (1) make a website that does anything in any programming language with any framework or (2) use F# to parse a large text file and have the running process use no more than 1 gig of memory. The first proposition makes your head hurt while the second gets your mental juices flowing as you decide whether to try to solve the problem algorithmically or to cheat and write interim results to disk.

Well, the same thing happens with a lot of the “best practice” rules that surround us in software development. Don’t make your classes too big. Don’t make your methods too big. Don’t have too many parameters. Don’t repeat your code. While they can seem like (and be, if you don’t understand the purpose behind them) cargo-cult mandates if you simply focus on the matter of relativism vs absolutes, they’re really about removing (generally bad) options so that you can be creative within the context remaining, as well as productive and happy. Developers who practice DRY and who write small classes with small methods and small method signatures don’t have to spend time thinking “how many parameters should this method have” or “is this class getting too long?” Maybe this sounds restrictive or draconian to you, but think of how many options have been removed from you by others: “does the code have to compile,” or “is the code allowed to wipe out our production data?” If you’re writing code for any sort of business purposes, the number of things you can’t do dwarfs the number of things you can.

Of course, just having rules for the sake of rules is the epitome of dumb cargo cult activity. The restrictions have to be ones that contribute overall to a better code base. And while there may be some debate about this, I doubt that anyone would really argue with statements like “favor small methods over large ones” and “favor simple signatures over complex ones.” Architects (or self-organizing teams) need to identify general goals like these and turn them into liberating restrictions that remove paralysis by analysis while keeping the code base clean. I’ve been of the opinion for a while now that one of the core goals of an architect should be providing a framework that prevents ‘wrong’ decisions so that the developers can focus on being creative and solving problems rather than avoiding pitfalls. I often see this described as “making sure people fall into the pit of success.”


Going back to the “maximum of three parameters rule,” it’s important to realize that the question isn’t “is that right 99% of the time or 100% of the time?” While Jane and John argue over that one percent, developers on their team are establishing patterns and designs predicated upon methods with 20 parameters. Who cares if there’s some API somewhere that really, truly, honestly makes it better to user four parameters in that one specific case? I mean, great — you proved that on a long enough timeline, weird aberrations happen. But you’re missing out on the productivity-harnessing power of imposing good restrictions. The developers in the group might agree, or they might be skeptical. But if they care enough to be skeptical, it probably means that they care about their craft and enjoy a challenge. So when you present it to them as a challenge (in the same way speeding up runtime or reducing memory footprint is a challenge), they’ll probably warm to it.


Why Are Public Fields No Good, Again?

Today, a developer on my team, relatively new to C# and some of the finer points of OO, asked me to take a look at his code. I saw this:

How would you react to this in my shoes? I bet like I did–with a quick “ooh, no good…try this:”

Busy and pleased with myself for imparting this bit of wisdom, I started to move on. But then I realized that I was failing at mentoring. Nothing annoyed me more as a junior developer than hearing something like, “That’s just the way you do it.” And there I was saying it.

The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which.


I stopped at this point and forced myself to talk about this–to come up with a reason. Obviously, I hadn’t been thinking about the subject of why public fields are icky, so slick terms like “encapsulation” and “breaking change” weren’t on the tip of my tongue. Instead, I found myself talking sort of obliquely and clumsily explaining encapsulation in terms of an example. Strangely, the first thing that popped into my head was threading and locking the field to make it thread-safe. So I said something along the lines of this:

With a public field, you simply have a variable that can be retrieved and set. With a property, you’re really hiding that variable behind a little method, and you have the ability to centralize operations on that variable as needed rather than forcing them on everyone who uses your code. So imagine that you want to make these fields thread-safe. In your version, you force all client code that uses your class to deal with this problem. In the property version, you can handle that for your clients so that they needn’t bother.

Yeah, things are always more awkward off the cuff. So I ruminated on this a bit and thought I’d offer it up in blog post format. Why not have public fields (aside from random thoughts about threading)?

The Basic Consideration: Encapsulation

As amused by my off-the-cuff threading example as I am, it does drive at a fundamental tenet of OOP, which is class-level encapsulation. If I’m writing a class, I want to expose a set of public functionality (methods and properties) that describe what an instance of the class will do while hiding how it will do it. If the address class is in some other assembly and I don’t decompile or anything, as a client, I have no idea if the City property is auto-implemented, if it wraps a simple property, or if all kinds of magic happens behind the scenes.

I know (hopefully) that if I set the City property to some value and then read it back, I get that value. But beyond that, I dunno. Maybe it implements lazy loading from some persistence store. Maybe it tracks all of the things you’ve set City to throughout its entire lifetime. I don’t know, and I don’t want to know if it isn’t part of the public API.

If you use public fields, you can’t offer consumers of your code that blissful ignorance. They know, ipso facto. And, worse, if they want any of the cool stuff I mentioned, like lazy loading or tracking previous values, they have to implement it themselves. When you don’t encapsulate, you fail to provide any kind of useful abstraction to me. If all you’re giving me is a field-bag, what use do I have for an instance of your class in mine? I can just have my own string variables, thank you very much, and I will hide them from my clients.

The Intermediate Consideration: Breaking Changes

There’s a more subtle problem at play here as well. Specifically, public properties and public fields look and seem pretty similar, if not identical, but they’re really not. Under the hood, a property is a method. A field is, well, a field. If you have a property and you decide you want to change its internal representation (going from something complex to simple property or automatic property), no harm done. If you want to switch between a field and a property though, even the trivial switch I showed above, there be dragons–especially going from field to property.

It seems like a pretty obvious case of YAGNI to start out with a field and move to a property if you need it, but things start to go wrong. Weird and subtle things. And they go wrong on you when you least expect them. Maybe you’re using the public members of the Address class as part of some kind of reflection. Well, now things are broken because properties and fields are completely different here. Perhaps you have a field that you were using as an out parameter somewhere. Oops. And, perhaps most insidiously of all, just changing a field to a property will cause runtime exceptions in dependent assemblies unless recompiled.

Let me put that another, scarier way. Let’s say that I write something called Erik’s Awesome DLL and I distribute it to to the world, where it gains wide adoption. Let’s also say that I created a bunch of public fields that the world uses as part of my DLL’s API. And finally, let’s say that in vNext, I decide that I want some encapsulation after all. Maybe I want to implement thread-safety. I implement and publish vNext to Nuget, and you update accordingly. The next time you hit F5, your application will blow up, and it will continue to blow up until you recompile. It may not sound like a big deal, but you’re definitely going to annoy users of your code with stuff like this.

So beware that you’re casting the die here more quickly and strongly than you might think. In most cases, YAGNI applies, but in this case, I’d say that you should assume you are going to need it. (And anything that stops people from using out parameters is good in my book)

The Advanced Consideration: Tell, Don’t Ask

I’ll leave off with a more controversial and definitely the most philosophical point. Here’s some interesting reading from the Pragmatic Bookshelf, and the quote I’m most interested in here describes the concept of “Tell, Don’t Ask.”

[You] should endeavor to tell objects what you want them to do; do not ask them questions about their state, make a decision, and then tell them what to do.

I’m calling this controversial because the context in which I’m mentioning it here is a bit strained. Address, above, is essentially a data transfer object whose only purpose is to store data. It will probably be bubbled up from somewhere like a database and make its way onto something like a form, with perhaps no actual plumbing code that ever does ask it anything. But then again, maybe not, so I’m mentioning it here.

Public fields are the epitome of “ask.” There’s no telling but not asking–they’re all “ask and tell.” Auto-properties are hardly different, but they’re a slight and important step in the right direction. Because with a property, awkward as it may be, we could get rid of the getter and leave only the setter. This would be a step toward factoring to a (less awkward) implementation in which we had a method that was setting something on the object, and suddenly we’re telling only and asking nothing.

“Tell, don’t ask” is really not about setting data properties and never reading them (which is inherently useless), but about a shift in thinking. So in this example, we’d probably need one more step to get from telling Address what its various fields are only to telling some other object to do something with that information. This is getting a little indirect, so I won’t belabor the point. But suffice it to say that code riddled with public fields tends to be about as far from “tell, don’t ask” as you can get. It’s a system design in which one piece of code sets things so that another can read it rather than a system design in which components communicate via instructions and commands.

So I feel clean and refreshed now. I didn’t shove off with “I’m in charge and I say so” or “because that’s just a best practice.” I took time to construct a carefully reasoned argument, which served double duty of keeping me in the practice of justifying my designs and decisions and staying sharp with my understanding of language and design principles.


The Dirty Work for Software Architects

Last week, I spent some time in two Egyptian cities: Alexandria and Cairo. I enjoyed this a lot. The Egyptian people were very friendly and good-natured, and there were some truly fascinating sites to see. Beyond just the obvious trip to the Pyramids, I saw Greco-Roman ruins, an incredible library in Alexandria, forts constructed during the Middle Ages, etc. These cities were very much alive and had distinct and enjoyable personalities.

One thing that really struck me, on the negative side of the ledger, however, was how much garbage there was everywhere. It looked as though it was trash day for the entire city and some kind of low-grade typhoon passed through, leaving the buildings intact and scattering trash everywhere. The problem was so bad that, in the canals feeding off the Nile, the government had actually started to fill them in with dirt, stopping the flow of water to prevent local children from playing in what had essentially become open sewage.

One might chalk this up to some kind of cultural difference or something, but that didn’t seem right to me. As I made my way around, I saw shopkeepers sweeping up their floors, people scrubbing their windows, occupants picking up debris from the sidewalks. Residents clearly cared about the conditions of their surroundings. This struck me as some kind of logistical problem, and a little googling around upon my return seemed to confirm this suspicion. Apparently, since the overthrow of Mubarak, public works suffered and the programs implemented by Morsi haven’t sufficiently addressed the problem. In Egypt, more garbage is currently generated than is hauled away–to the dismay of the locals, I’d imagine.

On the long, long flight home a few days later, my mind wandered between the trip I had just experienced and the work to which I was returning. I thought about the role of architect on a project and how in some ways it’s like a role of governance. In realpolitik context such as discussed in my post about job titles, it’s like government in that the role comes with a lot of perks that people tend to take for granted, at times to the extent of forgetting what they’re really supposed to be doing. This gives rise to the classic jokes about supervision being a role that involves doing nothing.

But in a less cynical context, the role of the architect is one of vision, persuasion, balancing concerns and understanding business needs such as keeping costs down. And this is very similar to government as it’s meant to be undertaken. It’s not all slush funds, lobbyist-bought dinners, and cigars–you need to get things done. Some of that work may leave your stamp on the world (or at least the group for which you’re the architect), allowing you to tout that you introduced continuous integration or forged ahead with a new, distributed architecture. But sometimes, you just have to pick up the garbage, even when you want to build pyramids.

Architect as Trash Collector

I’ve seen a lot of different code bases and approaches over the years. Sometimes you see well curated, organized code bases being maintained by conscientious developers, but this is probably the least common scenario because it’s hard and requires training and practice. The most common scenario tends to be that a rather rotten code base is being maintained by developers whose attitudes range from checked out and indifferent to interested but frustrated. Code bases tend toward entropy, and the longer they’ve existed, often the more run-down they are. The garbage starts to pile up in the streets.

But surprisingly, I’ve found that a scenario you see more than you’d expect is one where the code base is in a sorry state but the developers are conscientious and hard working. And this is what my mind kept coming back to as I reflected on my tour through parts of Egypt–hardworking people in a frustrating and often futile struggle to be clean in an unclean world too big for them to control. The developers do their best with new code and improve legacy code when they can, following the Boy Scout rule, but improvement is slow and painful, if not at a standstill.

How would you fix this as architect? Start over with a complete, grand rewrite? Good luck with that because, if you’ll recall, one of the things that the architect should do, like the government, is understand value tradeoffs and budgets. Rewriting the software is sort of like saying, “Well, retirees, sorry, but paying your social Social Security is really dragging us down…” It’s a non-starter. Do you order some pyramids built–some introduction of an impressive, slick piece of latest and greatest framework, design pattern, or tool? Hmm… I’m reminded of Percy Shelley’s Ozymandias–terrible in your greatness and power, all that will remain of your architecture when you’re five years gone from the company is dust and the occasional, cryptic comment in the code about the great things you were going to do. “I am Ozymandias, Architect of architects–look on my code generation ye Mighty, and despair!”

Governed agencies that succeed are built on good infrastructure and logistics. Non-glamorous things like those are what governance is really all about. Building impressive, shiny things is a luxury and a thing that governments built to last only do when the lifeblood of the government is healthy and flowing and the foundation is strong. When communication fails and rubbish piles up in the streets, that has to be addressed first. So what does a good, governing architect do? Well, he rolls up his sleeves and takes out the trash.

You Have to Get Your Hands Dirty

You do drudgery clean-up. You methodically go through the code base breaking apart 1000 line methods into 200 line ones. You break those into 40 line ones and those into 5-10 line ones. You get rid of copy-paste jobs in the same way, and you add automation to your builds, tests, and process as you go. People laugh at first and think you’re crazy. They tell you that the architect should be meeting with the department heads and executives, drawing massive UML diagrams and entity-relationship models. They’re right–you have to do those things and this too. So you chip away in the hour before you leave but after everyone else has taken off. You remote in on weekends. You make progress and build sweat equity. People stop laughing at you and join you, appreciating that you work as hard as they do when you don’t have to anymore and that you’re rolling your sleeves to take the trash out. It’s infectious, and you start to fix the problems in earnest and make the infrastructure hum as improvements are noticeable.

I think that this is what an architect ought to be. You do all of the planning and technical lead work, making decisions, mentoring developers, strategizing and scheming, but you lead the way in the trenches, too. You work hard making life better for the developers on the team, ensuring their code base stays clean and easy to work with. You keep the potholes filled, the crime down, and the garbage out of the street.

Acknowledgements | Contact | About | Social Media