DaedTech

Stories about Software

Aug
19

By

Notes On Job Hopping: You Should Probably Job Hop

Category: The Life of a Programmer Tags: , , | 13 Comments

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 for Job Hopping

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.

ScarletJ

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.

Inertia Makes You Want to 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. And 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.

Job Satisfaction Also Keeps You Around

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.

And, Maybe Company Loyalty, But Probably Not These Days

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.

And Then, There Are the Golden Handcuffs To Keep You Around

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?  Let’s First Talk Money

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.

Career Advancement is Also Better for Job Hopping

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.

Job Hopping Lets You Control Improvement of Your Circumstances

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[since deleted] 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.

Job Hoppers Don’t Have to Deal as Much or as Long with Expert Beginners

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 Job Hoppers Avoid Stagnation

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.

A Recap of the Pros and Cons

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.

The Stigma Doesn’t Really Matter

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, Should You Job Hop?

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? And 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.

By the way, if you liked this post and you're new here, check out this page as a good place to start for more content that you might enjoy.

Jul
29

By

Seeing the Value in Absolutes

Category: Reasoning About Code Tags: , |

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.”

PitOfSuccess

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.

Jun
5

By

Why Are Public Fields No Good, Again?

Category: .NET Tags: , | 3 Comments

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:

public class Address
{
    public string Street1;
    public string Street2;
    public string City;
    public string State;
    public string Zip;
}

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

public class Address
{
    public string Street1 { get; set; }
    public string Street2 { get; set; }
    public string City { get; set; }
    public string State { get; set; }
    public string Zip { get; set; }
}

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.

AnimalFarm_1stEd

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.

Jun
2

By

The Dirty Work for Software Architects

Category: The Life of a Programmer Tags: , | 6 Comments

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.
OLYMPUS DIGITAL CAMERA

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.

May
10

By

Is He Technical?

Category: The Life of a Programmer Tags: , , | 1 Comment

A short post today–I’m still sort of in frantic mode and switching gears in a variety of ways, but I didn’t want to go the whole week with just the one post.

Some time back, I observed some people working on a project in which the team consisted of some developers of varying experience levels and skill sets. There was also a project manager assigned to the project, but he definitely wanted to put the “manager” in “project manager.” Rather than Gantt charts and status reports, he insisted on being part of every technical decision, however coarse or fine grained. It was hard to tell, from my outsider perspective, whether his inputs (orders) made any sense or whether he was just wasting time and clouding the issue when he could have been focusing on logistics, communication, and removing obstacles from the path of the developers, as one might expect from a pure project manager.

It appeared to me that he wasn’t just failing to remove obstacles, but that he was an obstacle. This was confirmed by a conversation that I later overheard among a few of the developers in the form of a simple but profound and damning question. My understanding of this project manager’s background was that he was the sort of PM who had cut his teeth as a developer for a number of years and ‘graduated’ to project management. The unintentionally damning question from one of the developers was a simple, frustrated, “is he even technical?”

That might not seem like it matters at first blush, but that’s the kind of thing where, if you let it wash over you, there’s something important and fundamentally bad happening. The PM either has a technical background or not, and the badness is present either way. If he does not have a technical background, the obvious question is “why is he attempting to stick his nose in development and design discussions?” But if he is technical…ouch.

If he is technical, he’s communicating so poorly or getting concepts so wrong during the course of (micro) management that the developers are genuinely unclear on whether or not he has a programming background. Unintentionally damning. They’re not accusing him of anything or gossiping or anything along those lines–they’re so underwhelmed by his contributions that they think he doesn’t even possess table stakes, bare-minimum competence in the field.

The “duh” lesson here is not to blather on or bark orders when you don’t know what you’re talking about, but that’s really kind of an edge case. I’d say the take-away for the readership here is to ask yourself, assuming you’re in a position of authority, whether anyone would quietly wonder if you’re technical. Maybe it’s because you’ve been doing too much delegating or are busy with other things, but still, don’t let this be said about you. I’ve touched on this subject before in the context of a team lead, but this is a broader concern. As you go along working with others, take inventory from time to time, asking yourself whether anyone might be wondering skeptically how you came to be in a position of authority. If you think they might be, don’t blow that off and think it’s not worth proving. It is. Responsibility without respect is empty, so remember to earn yourself some respect from time to time.

« Older Posts
Newer Posts »