Dress Code Wars Episode IV: The Suits Strike Back

Wow. What a bit of a crazy couple of days since my last rant on the absurdity of forcing developers to work under dress codes. It hit Proggit, Hacker News, was tweeted by some high-follower-count people, and had more page views than anything else I've done. For those of you new to the feed, welcome!

I've been following the conversation on as many sites as I've been aware of, to try to keep the conversation going, and I was quite chuffed when there were more words on the subject written by !Kirk as by me. Particularly given my verbose writing style, that to me is a sign of a good conversation, which was the primary reason for the rant.

I just wanted to take some time to address some of the common arguments that kept coming up.

Kirk, you're a pompous Prima Donna and you're really not that good, either. Just shut up.

Ahhh, Argumentum ad Hominem. Where would the internet be without you? Just for the record though, I don't claim I'm that good a developer, and while I've been accused in the past of being a Prima Donna, I really don't let it get to me. I think it's more telling about the accuser than the accused.

I like dressing nicely

Bully for you! I'm sure you look lovely in your bespoke suit and custom made shirt. I'm positive you're quite the looker, and are attractive to both genders. You're a straight shooter with Management Potential written all over you.

If you like dressing nicely so much, why are you worried about a lack of a dress code? Why not have no dress code and still wear a suit? If you're just saying that you like dressing well, why not stay dressing well without forcing your sartorial choices on others?

I like South-East Asian food a lot. I think you should like it. But I sure as heck wouldn't have a company cafeteria only sell Thai food, and force you to eat in it every day.

It's better for your career to dress well

Thanks for looking out for your fellow software engineers, and incidentally, I actually agree with this one (if you desire a management role, or a role where you're working very closely with the business on a daily basis, you should dress up a little). But it should be your choice.

This one is an arms race as well. The only way this works is if you dress just a little bit better than everybody else, no matter what they're wearing. Norm is jeans and T-shirt? You wear chinos and a shirt. Norm is slacks and a shirt? You wear a suit. Norm is a suit? You wear a bespoke suit and a custom-made shirt and Hermes tie. No matter what, you always have to dress just a little bit better. You should actually be the most in favor of loosening dress codes, because then you don't have to dress that well/expensively/uncomfortably to still stand out.

Without a dress code, chaos will ensue

"Dress Appropriately" is the most powerful dress code you can have, because it completely eliminates all these arguments:

• People will dress like ragamuffin street tramps. Someone goes too far and you think it affects others? Take them aside and say "that's inappropriate."
• People won't dress up for meetings where formal attire is required. I dress down when I code, but when I meet with investors or customers, I dress up. That's just common sense, and if you actually hire people with common sense, they'll use it.

Fundamentally, we're not children, we're professional software developers. Removing arbitrary rules won't result in a Lord of the Flies situation breaking out.

I don't like seeing your manky feet

Believe it or not, this came up several times. As long as women can wear open toed shoes or nice sandals or whatever, it's just a rubbish argument. You don't like seeing a bloke's feet because you don't usually see a bloke's feet. Believe it or not, there are whole countries where very few people of either gender wear shoes on a regular basis. Get over your foot phobia.

My family needs to eat

Look, I completely understand that your family needs to eat, and if, on balance, the best job on offer is one which dictates a dress code, and you're aware of the likely attitude of the firm based on the existence of said dress code, you should take it. I didn't want a job with a dress code when I took the contract with Big Bank B, but my family needed to eat as well. Pragmatism is the primary virtue of the successful professional software developer.

Just be aware that if the firm has a dress code, in my opinion, that signals many things about the firm and its relationship with its technical staff. Go into it with your eyes open. And in my opinion, if you have a choice between a job with no dress code, and a slightly higher-paid job with a dress code, you should pick the one without the dress code.

Software Developers Should Never Have Dress Codes

On Saturday, I visited my dry cleaner. [1] Normally this wouldn't be a particularly momentous occasion [2], except that it was the first time in three weeks that I had gone. Up until the end of August, I had to make sure that like clockwork, at least every 2 weeks my Better Half or I made the trek to the dry cleaners, to make sure that I had suitable attire for my Cash Money Day Job. But it hit me on Saturday that this was a thing of the past: I no longer work for a company foolish enough to have a dress code for its technical staff.

When I first joined Big Bank B on my 6-month contract, it was the first time I had ever in my life had to dress up for work. I'd managed to work full-time for over 10 years, inside financial services and technology firms, and never had a dress code. In fact, my previous company (Investment Bank A) was so notoriously dress-down for financial services that there was a catty reference in the New York Times regarding the fact that people would (gasp! shock! horror!) show up to meetings in shorts and flip flops. At Hedge Fund V (the previous employer), while traders would usually show up in business casual, nobody cared what the geeks wore. However, the week before I started at Big Bank B, I had to go out and shell out a few hundred pounds on all the things that I didn't have enough of: work shirts, proper shoes, non-denim trousers. All this just to go into an office and code all day.

There's no justification for a dress code policy in this day and age if you view the primary function of a software developer to be the development of software. Right now I'm wearing shorts, sandals, and a T-shirt. Can anyone argue that I'd be more productive (in quantity or quality of technical output) if I was wearing chinos and a blue shirt? Or, perish the thought, a suit and tie? Definitely not.

However, the big question is Why? Why in the world do people still persist with this gross stupidity in this day and age? And why is it that big banks, in particular, seem to be so obsessed with dress codes?

In The Trenches, Fighting Bugs

A few years ago, I interviewed with Lehman Brothers. I noticed that all the technologists interviewing me (and it was an all-tech interview process) were wearing suits. Some of them had ties on, some of them didn't. I didn't wear a suit to the interview, and felt a little self conscious about it. [3] I asked one of the guys there why in the world they were so dressed up to write code all day.

Apparently this had come up in the past, and one of the Really Big American Bosses justified the policy with a phrase that has stuck in my mind ever since: "When a soldier goes to war, he wears a uniform."

There are so many things wrong with that statement that I can't even enumerate them, but let's start with the most glaring: Programmers Are Not Soldiers. Soldiers go to boot camp, a process designed specifically to break down their sense of self and recraft the mentality of the individual to mindlessly obey orders, even unto death. Soldiers go to war; soldiers fight people with weapons; soldiers live in barracks and eat in mess halls and, you know, act like they're in the military.

That's not what I do as a software engineer/craftsman: I think; I discuss; I code; I maintain. I don't live in close quarters with my coworkers; I get to eat what I want when I want; and while whiteboard discussions may get pretty heated, they're seldom settled with bayonets. I don't write code while firing an automatic weapon, and I don't engage in hand-to-hand combat with bugs. How in the world does a standard set by a military organization apply to a private sector financial technology job? [4]

Developers Should Be Heard But Not Seen

Second justification that I've heard for these ridiculous policies actually came from the hiring manager at one of the firms that bought out the carcass of Lehman, maintaining the dress code insanity: "if you ever have to go to the trading floor, there might be customers on there, and we won't want them to see you dressed down." That's right, because someone might see a derivatives trading floor, and figure out that there are actual programmers who make the software that keeps the 8 LCD displays each of the traders have full of blinkenlights.

It reminds me of firms that I've heard of that actually have separate entrances for the IT staff: customers and well-dressed individuals in Door A, all the plebes in Door B (heaven forfend that the twain shall meet). Big Bank B effectively had this policy, in putting all customer-facing activities in one building, while putting all non-customer-facing activities (IT, Operations, Back-Office, Middle-Office) in a whole different building.[5]

Yet most firms that have the separate-door, or separate-building policy, have it in place specifically so that the staff that don't have to dress in a certain way to satisfy the sartorial requirements of outside customers/investors didn't have to. Big Bank B said "not only are we going to shield you from view, we're still going to make you dress uncomfortably."

The Replaceable Engineering Unit

So given that dress codes are a net negative for developers, what could really be behind the correlation between probability of dress codes and size of the firm?

Remember, Big Banks actively fight against entrepreneurial/independent-minded technical staff. And then they make them all dress alike. The two, I think, are inextricably linked by one factor: a desire to smooth out the inherent human differences in employees of a firm grown too big for its management structures to cope with.

The Mythical Man Month was written at a time when almost all developers were working in large institutions, and it speaks to the levels that managers at those institutions will go to try to view individual employees as nothing but entries in a Gantt Chart. It doesn't work, because technologists have different skill levels, different interests, different speeds. But big organizations plan at very senior levels, where the people who are making decisions are unable to even conceptualize the differences between the people underneath them (because they're past the 150-person soft limit on social group sizing).

When faced with the requirement that you manage people beyond your cognitive limits, you can respond in one of two ways:

• Decentralize, and give massive autonomy to the people underneath you whose organizational unit size is within Dunbar's Number; or
• Standardize, and try to force individualism out of the equation.

Let's go back to Lehman Brothers. I think it's actually a telling example, because military units inevitably combine attempts at minimizing individual differences with organizational units that are below Dunbar's Number. So boot camp attempts to minimize individualism at the level of individual troops, but many decisions are made at the level of cognitive limits of social size.

The only way to combine the two though is to have senior executives/military officers making broad-sweep policy decisions ("we're going to start trading Convertible Bonds," "we're going to centralize all treasury activities," "we're going to invade Iraq"), but defer all decisions that rely on the individual skills and proclivities of individuals to the level of managers that actually understand the staff that they have. While many financial technology organizations claim to be applying that principle, ask yourself the following questions:

• Are individual line-level technical leads able to chose the major technologies that go into their software, or is there a central group that specifies the technologies that must be used?
• Are individual line-level managers free to determine the set of methodologies that work best for the team, or is there one over-arching set of methodologies that must be followed?
• Are individual teams able to determine their own deployment strategies based on their technology and the needs of the business, or is there a single policy that determines how software is going to be deployed?
• Do individuals have control over their programming environment (including hardware and software choices, and customization of everything they need), or is there a single image and single standard set of hardware that all developers get?
• Can people choose their attire, when there isn't a valid business reason to dress beyond the comfort level, or is there a dress code that must be adhered to?

My Advice To You

If you ever interview with a firm that has a dress code for techies, don't take the job. And more importantly, tell HR that this is part of the reason you're turning down the job. Because if you are able to find a firm that has reasonable pay, and doesn't have a dress code, that tells you a lot about its relationship with its technical staff. The dress code, on the other hand, is a very clear bright-line test to see an organization that undervalues the individualism that makes strong technologists as valuable as they are.

Plus, working in shorts and a T-shirt is pretty darn cool. Particularly when you get off at Bank or Canary Wharf station and everybody else is dressed up and already sweating at 8:30am.

Footnotes:

[1]: Not the best choice around actually. They're good, but Go Gay just a couple blocks up has a better reputation. However, as I don't drive, the extra couple of blocks I'd have to walk loaded down with lots of dry cleaning trumps an arguably better quality of service.
[2]: I can't/don't iron. When I was growing up, having shirts professionally cleaned and pressed cost so little that there wasn't a point in my parents doing it, and thus they never taught me to. And professionals do a much better job than your house cleaner does (if you're one of the people who has your cleaner do your ironing for you), so the cost really isn't much of an issue.
[3]: Seriously, whoever came up with that whole "dress your best for an interview" advice never had to nip out "for a Doctor's appointment" to interview. I mean, if you're actually gainfully employed, and you don't dress up in your current gig, dressing up is a dead giveaway you're interviewing. So if you do show up extremely well dressed for something that isn't a whole-day interview, it basically says "I'm unemployed."
[4]: I mean, while we're at it, you know who else wears uniforms? Ninjas. And while it's completely Awesome to imagine that we're all ninjas, we're not. If we were, we'd be too busy fighting pirates to get any software written.
[5]: Yep, that means that if you wanted to talk to the people using the software you built, you actually had to go to a whole different building a 5-10 minute walk away. Not that I ever did, mind you.

What Type of Software Engineer Do You Aspire To Be?

This is the opening part in a series of blog posts I'm writing in helping my nephew, who's in secondary (high to the North Americans reading) school, who wants to go into software as a vocation. I've decided to experiment with a semi-didactic conversation.

If you're planning on getting started in a career in software engineering, the first thing you have to ask yourself is what type of software you're most interested in:

Pure Software Development

I classify this as working with relatively low-level systems and algorithms, and working to such a degree that satisfying business requirements (while extremely important) aren't the primary consideration of the majority of actual work you do. Rather, technical constraints factor in often enough that you are forced to innovate from a technological perspective on a regular basis.

Vocational Software Development

I classify this as working on systems where the primary consideration is the efficient encoding of business rules, where off-the-shelf frameworks/products/systems are able to satisfy virtually all the technical requirements.

While some astute readers may expect me to follow with some pithy comment about the relative quality/skills/intelligence/worthiness of people who work in one of the two areas, I won't. I actually don't fundamentally view the two as mutually exclusive, and I think assigning normative judgement isn't meaningful or helpful.

If you're going to pursue a Pure Software Development career track, you should expect:

• You will need to go to a top-track computer science university [1], particularly one which (historically) taught SICP. [2]
• You will need to work at said university harder than you expect, go beyond your expertise, and generally be humbled at every stage, because you will run into people who are smarter/harder working/better programmers than you.
• You will have to decide to live in one of a few job markets in the US [3], because there's really only jobs that require that type of development in a few places [4]
• You will find the vast majority of software engineering jobs completely boring, and more importantly, if you take a purely vocational job, you will constantly look for technical problems where there are none, to your detriment as a craftsman.
• You will get to advance the state of the art, work with cool technologies, and generally maximize your geek nature on the job.

Perhaps most importantly, however, you will view your career through the eyes of technology.

However, if you're going to pursue a Vocational Software Development career track, you should expect:

• You won't have to go to quite as rarified university, and you might actually properly enjoy your undergraduate years.
• You will be able to live and work pretty much anywhere, and make choices based on you and your family's best interests rather than having to live in an extremely expensive housing market due to a pretty limited set of career opportunities outside those markets.
• You will never find intellectual stimulation in your job, except where you add it to your detriment as a craftsman.
• If you are good, you will never find it particularly difficult to find a job, because people who can efficiently apply technology to solve business problems are always in demand. [5]
• You will never get to advance the state of the art, work with particularly cool technologies, and will require external stimulation to maximize your geek nature.

Perhaps most importantly, however, you will view your career through the eyes of solving business problems.

Note that saying "I want to work in Industry X" doesn't determine which of these tracks you have to go down. You can pursue either track and work in many industries:

• Oil/Gas/Materials Exploration require loads of people who can work with 3d visualization and computational farms and GPGPUs and loads of other super-cool stuff I'm making up because I've never worked in that industry. They also require loads of people who can build systems to handle the business of pumping oil/petrol/gas/coal/gold/coltan out of the ground and into productive use.
• Finance requires loads of people who can work with low-latency market data systems and computational farms and GPGPUs and huge risk data warehouses and loads of other super-cool stuff I can't discuss due to NDAs. It also requires loads of people who can build systems to handle moving data in between mainframes and databases and workflow engines.
• Startups require loads of people who can generically push the state of the art in technology to assist end-users and other technologists. They also require loads of people good at building web applications that don't push the state of the art technologically at all.

Can you combine the two? Of course you can. 37Signals is a great example. They build applications that really don't push any boundaries technologically in any way: they're about more efficient ways of doing things, web-enabled, with excellent design. But they also built Ruby on Rails as a way of achieving those aims better. Financial systems are, at their heart, a way to enable a group of traders to maximize revenue subject to the needs of the business. But most of them require a massive application of technology to be able to satisfy those needs, and so require significant applications of pure technology in order to be successful.

In fact, in my mind, the best software engineers are ones who can handle both the pure technology and business vocational requirements simultaneously. They're rare, though, and most of the ones that I know start from one side and realize that they're still interested in the other, and grow their mentality to be able to simultaneously achieve both technology and business zen. You have to get to grips with what really moves you first, and then work on everything else from that perspective.

So which is it? Pure Technology Track, or Vocational Technology Track?

Footnotes

[1]: Go Bears.
[2]: If you didn't go to one of those schools, and you're getting hot and bothered at this stage, seriously, why are you reading my blog in the first place? Regardless, keep reading, as you'll find I'm not capping on your alma mater in any way.
[3]: In North America: San Francisco Bay Area, Chicago, North Carolina Research Triangle, Salt Lake City, New York, Seattle, Vancouver, Boston, Austin. Yes, there are outlier organizations everywhere, but in general, you better plan on spending the first part of your career one of those places.
[4]: Network effects in play here. You need a certain number of these people before the development team can work, and that means you have to have quite a few to draw on, and such they all flock together.
[5]: Particularly if you and your family are willing to change locations. Hiring for this type of engineer tends to follow cyclical hiring paths, and North America tends to have regional cyclical trends.