Culture Shock: Programming for the Enterprise

As a disclaimer, this is my experience, and not a broad generalization about enterprise work environments, or the software industry as a whole.

Background.

Some background about myself will probably help you understand where I’m coming from, so here’s the skinny: I’ve been developing software for a decade, and contributing to open source projects for about eight of those ten years. Just recently (about six months ago), I graduated from a prominent public university with a bachelors degree in mathematics (I took my time). Right before I graduated came the usual job hunt (there was a brief affair with the idea of going to grad school). Now, myself being a huge proponent of open source software, I directed my job hunt towards companies with a vested interest in the open source community: Rackspace, RedHat, Mozilla, Novell, Intel, Nokia, and others—what I would consider “the usual suspects” if you’d like to wind up with a job hacking on an open source project all day. All my efforts towards finding an “open source job” fell through for one reason or another: most companies seemed to flat-out reject my applications on account of my recent-grad status (and we can have an entire debate about seniority/experience, but that’s probably best left to another post), many required a very large amount of prior dedication or contributions to a particular project (i.e., they wanted to hire from “within the project,” and that’s understandable), and others just simply didn’t respond at all. Ever. I suppose it could have been worse.

So I felt the heavy hand of fate pushing me to expand my search into the proprietary and enterprise spaces (or in some cases, to stop emphasizing my open source preferences), where I had much better luck. The tech giants quickly set me up with onsite interviews, where I went through the usual rigmarole (some funneled me through their university recruiting programs, some didn’t—there wasn’t much of a difference). The smaller local (to my state) companies and startups that gave me offers couldn’t compete with the medium/large corporations in terms of pay nor perks (and many of them were solving the same problems, just with a different toolset; it’s funny how often that happens). In the end, however, I received a rather substantial offer with killer benefits from a medium-sized local company that I had interned with a year prior—I’d get to stay close to my family and friends, continue my education, and live a comfortable lifestyle (rather lavish compared to a students’). So what was the catch? The job was writing enterprise code using an almost-pure Microsoft technology stack.

Since I had already spent a summer at the company, I wasn’t entirely ignorant of Microsoft technologies, albeit, I spent the majority of my internship writing a responsive mobile site and avoiding Visual Studio like the plague. You know those poor sods who use emacs on Windows? Yeah, that was me. As it turns out, I was to be hired into a DevOps position (more on that later), so I wouldn’t be forced to drown in the Kool-Aid, but to just bathe in it. Now it’s been about six months since I started my job, and I want to share a couple of my experiences and opinions thus far.

Fuck meetings.

No, seriously. Fuck. Meetings. Short of stand-ups and code reviews, I genuinely cannot recall a single productive meeting that I’ve been involved in at my job or any job I’ve held in the past. Ever.

Time is really the only capital that any human being has and the thing that he can least afford to waste or lose… — Thomas Edison

I can think of no bigger time-sucking, boredom-inducing, soul-crushing way to spend my time than to sit in on another meeting where my presence is somehow required, yet quietly ignored. There’s some really great advice out there about meetings that no one seems to be paying any attention to. Now, to quell some of your possible suspicions: I do not consider myself, in any capacity, a misanthrope, nor socially deficient. Working on a team is fantastic, and I feel that I have a good rapport with not only my teammates but my managers as well. I simply loathe meetings with the burning passion of a thousand dying suns.

Perhaps it’s only my experience, but I have never been in a meeting with the right number of people. The Goldilocks zone for meetings in general seems virtually microscopic — probably only hit occasionally and by sheer luck. Either there are too many people present, and discussion rapidly spirals downward into the inescapable abyss of bikeshedding, or there are too little people, and conjecture flies like shit, everywhere, because no one is sufficiently competent on the subject at hand to offer a detail-oriented solution (or the only person(s) who can approve a solution are absent).

Successful meetings not only have goals, but a well-defined roadmap of how to achieve them, and only include those people absolutely necessary (e.g., stand-up and code reviews). Please, think before you meet.

Know thy buzzwords.

Do you know what the three pillars of object-oriented programming are? How about the three A’s of unit testing? And the difference between a simple factory and a factory method? There seems to be a large amount of pressure in the enterprise world, both throughout the interview process and on the job, to be familiar with sundry buzzwords. In some cases, interviews can feel like a terrifying childhood nightmare where ridiculous mnemonics and acronyms are slowly, question by question, crushing your hopes and dreams of a bohemian lifestyle. (The ridiculous state of interviews at tech companies is yet another entirely different post.) I’ve been subjected to numerous lectures on topics with which I am already intimately familiar due to my lack of expertise in buzz-tastic nomenclature, like a half-hour summary on software test phases and methodologies because “3A” meant nothing to me.

The proliferation of this buzzword culture genuinely perplexes me, as it has been my experience that excessive use of buzzwords usually correlates negatively to a person’s knowledge on a particular subject. That is, they’re regurgitating words they’ve memorized on the topic (or heard commonly in conjunction with the topic) because they lack the sufficient understanding in order to approach the subject using concepts with which they’re already familiar. Sometimes it’s easy to spot, sometimes it’s not.

On the bright side, however, some buzzwords adored by management seem to have improved the quality of code (at least at a superficial level). For example, it appears that every technical recruiter/manager loves to brag about the use of agile methodologies (especially the use of pair programming), and test-driven development (or more specifically, behavior-driven development) nowadays. Even if the implementation of these concepts is poor or dysfunctional, the door has been open for improvement and refinement.

All hail the career programmer.

We’ve all seen them. The ones who never coded in school outside of assignments. I always told myself that they’d probably never get hired as developers, since their skills and knowledge were so far behind the kids working in the research labs on campus, going to hackathons, going to language user groups, interning at (or working at or founding) startups, and contributing to various open source projects. Hell, their skills were behind most hobbyist programmers that I knew. Sure, that may seem like a mean or arrogant or pompous thing to say, but software engineering is an extremely competitive discipline, and hiring practices, on the surface, appear to be geared towards weeding out the incompetent (which is why, more often than not, they’re basically day-long computer science exams).

But I see an analogous group in my workplace, and I have to wonder whether they’re born from the same collection of individuals. These are the people who view programming as “just a job,” rather than as a profession. That’s not to say that they don’t work longer than prescribed or eat, sleep, and breathe their responsibilities at the company (I’m very much against both), but that they lack the passion and drive necessary in order to excel at what they do. They don’t strive to refine their capabilities (inside or out of work), nor do they maintain an interest in the advancements of their profession. They treat coding as if it were janitorial work. In fact, their knowledge of software engineering and computer science is almost entirely limited to the problem domain that they work within, as they have no desire to venture out. They learn new things because they have to, not because they want to. They ignore established best practices within a language in favor of maintaining familiarity (e.g., writing C#-style code in JavaScript, or trying to implement interfaces in Python whilst utilizing conventions that would make the contributors to PEP 8 play the wrist violin). They refuse to adopt new tools or processes aside from those imposed upon them (e.g., a senior coworker of mine preferred to debug combined+minified JavaScript in Visual Studio rather than use Chrome with source maps because he felt that development should be able to be done with one tool). They’re just no fun to work with.

When in doubt, add fear and uncertainty.

A large number of my coworkers seem absolutely terrified of open source code. Given my background, it’s incredibly surreal to hear their stern objections. Projects hailing from development powerhouses, such as Google (e.g., Angular, Karma), and the most popular of open source libraries (e.g., jQuery) are with some, but relatively little effort, openly accepted for use, but smaller less-well-known libraries (in one particular example, RequireJS, in another, DataTables) are thoroughly questioned, sometimes to the point of meetings being scheduled to discuss whether it would be more appropriate to avoid their use entirely or re-implement them in-house. I can appreciate being wary of the dependencies you include, as it’s an integral decision on the part of any project, open source or closed, but in my experience, the hang-ups around these technologies seem to stem from other, deeper, problems.

Give them nothing, but take from them everything. — King Leonidas, 300

First, open source projects which are blessed on high to be used are often forked with a complete disconnect from upstream. No patches are shared. No friendly, “this product uses XYZ” messages are displayed. The code is just forked and used. Yes, this is well-within the terms of the license, but I feel like some courtesy is expected when using someone else’s hard work. This is analogous to tipping a waitress—sure, you don’t have to, however, it is the courteous thing to do. I think this stems from the fear that by admitting you didn’t do all of the work, you will somehow devalue your product.

Sheer ignorance about the open source world appears to be another reason. Several of my teammates have never even used a flavor of Linux (not even Ubuntu). Nor have they ever contributed to any open source projects. They don’t understand how open source development works at all. In an extreme example, a friend’s boss at another enterprise company prohibited the use of libbzip2 because he thought it was coded by a kid in their parents’ basement and thus was unsuitable for use within enterprise-level software. Yes, I’m serious. I can’t make this shit up. Thankfully, my experiences have yet to reach such a painful low. Unfamiliarity with open source licenses is also, unsurprisingly, pervasive. The exception being teammates who view the GPL licenses as the ebola viruses of the software world—I’ve had teammates incite arguments over MIT licensed code because it “might reference or use AGPLed code”.

Thankfully this doesn’t seem to describe where I currently work, but I do feel that some organizations place way too little value on open source experience. When I interviewed for Microsoft, the head of the team that I was interviewing for asked me about one of my open source projects (looking back, probably in an attempt to break the ice). As I was explaining to him the premise of the project (which required a little background), he cut me off and said, “what I really want to hear about is your real work,” referring to my meager three month internship (in comparison to the two years that I diligently worked on the aforementioned project before it was merged into a larger project).

So pro.

I feel that working in enterprise software has given me a much stronger sense of professionalism. My ability to consider the implications of changes to projects has been extended beyond the scope of the projects themselves (i.e., a developer’s perspective), and into the realm of the individual/business that utilizes them (i.e., a user’s perspective). That is, the end user, and not the project itself, has become my key focus when writing software. It may seem like something silly to say, but when you code for fun, the project exists primarily for the purpose of being hacked on. Sure, I wanted people to use my projects, and I wanted them to be robust, and well-designed, but more than any of that, I just wanted to have fun and learn new things while working on them.

THE USER DOESN’T CARE. — Linus Torvalds

Moreover, being placed in various adversarial situations (such as, being asked to defend your design decisions), has helped sharpen both my tactfulness (the above post excluded) and my ability to communicate my ideas and reasoning more clearly under pressure. Both are helpful in improving an environment that is slow to both accept and adopt change, like most enterprises.

Overall my experience feels a bit like visiting a foreign country for the first time. Some customs are bewildering and strikingly foreign, yet most are uncanny. In the end though, there’s no place like home.