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.

5 comments to Culture Shock: Programming for the Enterprise

  • Two parts of this post really hit home with my experience as well: the bit on the “career programmer” and the bit on open source software.

    When I worked in enterprise software, I got to be on a smaller team and we had a lot of slack in the decisions we could make for the software we were building.

    I was absolutely excited about this project. There were so many facets of programming that could get touched. There were so many areas of software that we could learn about, like databases, efficient real-time image processing, operating systems, updating mechanisms, etc. Best of all, we were fortunate that bureaucracy was minimized. People within two degrees of bureaucratic separation usually kept their noses out of it, and it worked out well.

    The trouble was: both of my project team mates were Career Programmers™, in the worst possible way. We were using a programming language that allowed a variety of paradigms. Often, the functional paradigm was both idiomatic and clearer. However, both of my team mates had never touched FP. They were previously C programmers. So they thought it would be best to code in this language as if it was C.

    This was horrible. I tried to politely suggest different avenues of programming and a few tools they could learn from, but that’s “not part of the job.” There was no interest in learning something beyond what they knew because it wasn’t part of the job description.

    That’s bad, but it’s even worse that they actively didn’t improve their style of coding. They hadn’t used object oriented programming either it seems. Or structs before. So what did they do when they wanted to pass around state? They made global variables.

    Most of the GUI code was a sloppy mishmash of global variables to communicate between different components. It was awful. But it worked for them in the past, surely it’ll continue working.

    When we ran into bugs as a result of it, they didn’t think twice that the style of programming could be the source of the issues. Instead, they viewed it as an error in the way their “local logic”, and just slapped a bandage over it assuming that’d fix everything in the future.

    In all, they just came to work everyday because it was a job. There was no excitement about what they have been doing outside of work, there was no passion for the subject one of them got a masters degree in.

    Open source was another huge issue, albeit mostly moral. We essentially stole open source code left and right in order to accelerate the development of our business. I wanted to add a note somewhere in our project describing the open source projects we used, and even more, open source some completely decoupled infrastructure to our main product.

    But in the bureaucratic hierarchy, up about 3 levels, there was fear of it. We actually had to sneak in open source software, because if we brought it up in a meeting, their response would be negative. Open source software was supposedly low quality, and if it was worth anything, they’d be charging for it.

    When we did convince them to let us use an open source library, we weren’t allowed to send patches upstream. “We aren’t working for free.” This was absolutely mind boggling. They gave us software for free, the least we can do is send improvements.

    Lastly, and I think the article puts it best:

    I think this stems from the fear that by admitting you didn’t do all of the work, you will somehow devalue your product.

    This was absolutely true. If shareholders or board members see a message in our product saying “we happily used X, Y, and Z”, management implies we would be seen as inferior, because we (supposedly) needed crutches to program. This very often led to reinventing libraries. The worst was when we greenspunned an entire database system.

    The kind of behavior these people demonstrated, a merciless scavenge for software to accelerate the business, a desire to pilfer and not share, really make things like GPL3 look charming.

    Through working at a few of these kinds of places, I now try to figure out during an interview if the companies are of this type. When I asked pointed questions about these things, I’ve actually been rejected because I was not “enterprise enough”. On the flip side, I’ve rejected offers precisely because I knew my work would be dominated by enterprise styles and systems, and more likely than not, I’d have coworkers who revel in—no, tolerate—that environment. So far, it has worked out well.

    (I originally posted this comment on Hacker News and reproduced it here for posterity.)

  • Scott Mitting

    While I admire that you think of the world as this good and happy place, I get a strong feeling that you will not be working in the big corporate world for very much longer, and you’ll find that the higher pay and fancy benefits are not going to be worth the soul crushing deafening brain drain you will continue to experience. Over time, you will be experiencing more meetings in your career if you would for big companies, not less. You will not be allowed to hold on to your programmer-minded ideals in that environment.

    I’m really sorry to tell you this. I left the corporate world long ago and never looked back. I had a feeling you were going to say a lot of the things you said as soon as you said you tried to avoid Visual Studio like the plague. That’s a little bit like a taxi driver saying he avoids the color yellow. You really don’t get a say in that matter.

    Let me give you a little perspective that will explain your concerns about large corporations not contributing back to open source libraries and not giving credit to them. What exactly does the corporation get directly from doing so? You can’t talk about lofty goals and improving the community… that’s just not a valid answer. Wish it was. Sorry. If you cannot say how doing so will immediately make them more money, there is no way you can expect any corporation to do these sorts of things. (In fact in America there is court precedence for publicly traded corporations to be strictly forbidden from doing things that can only be justified by “the common good” rather than the bottom line, but that’s another sad, sad discussion.) You’re actually very lucky if your corporation isn’t directly violating licensing requirements when using open source code. At more than one employer I have been handed obviously pirated software to work with. Yes, someone eventually called the BSA, and one of those companies paid fines… but fines that were much less than the licenses they avoided. I doubt they’ve changed their ways.

    Still, I admire your spirit. However, I don’t believe you’re going to find happiness working with any company that has more than 25 people, including non-technical staff.

  • OhMy

    I can understand the frustration. So you come from open source and worship it, great. But now it’s time to learn propriety tools and software, go for it. If you are as experienced as you claim you are, then this should not be a problem.

    This entire post is just an opinion of an extremely bitter individual.

    • Steve

      Being able to learn the tools is one thing. But actually enjoying the use of them is another.

      I’m sad that you see someone pointing out flaws in an organization’s culture as simply “being bitter”. It means you’re the type of person who’s going to stand in the way of that culture evolving.

  • The day I decided to leave Enterprise IT was when I was asked to design and implement a communication protocol between two servers (our server and a customers server) because TCP “was an unreliable non-deterministic protocol”. This insight was kindly provided to my boss at the time courtesy of one of those CEO magazine articles you see from time to time. I duly did the job (read: reimplemented TCP exactly on-top of UDP) before hightailing it out of there for the startup world. Sure, they remuneration isn’t as great (it does have the potential to be much better though) but what price can you put on your sanity?

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you post, please prove you are sentient.

what is 2 plus 3?