Programming at a Big Company

October 14th 2019

A few years back while working as a programmer at a big company I wrote this random story after an excruciatingly frustrating conference call. I thought better about posting it then, but the other day I stumbled across it and figured why not...maybe it'll resonate for someone out there..

You're an avid marathon runner, and are pretty fast to boot. It's your first race as part of a new running club, and you're excited. The club is big and, some say, impersonal, but you were lured by its longevity and reputation...and of course the kick-ass benefits - massages, gear, the works.

Anyway, it's the morning of the race, and you show up at the course. You head over to the club's meeting spot, and the first person who spots you is the health specialist. "Nice that they care so much about my health to have a dedicated specialist", you think.

After a friendly introduction, the health specialist says, "We need you to wear this backpack while you run, for your safety".

"Seriously?" you ask. "Won't it slow me down?"

"Well, it might, but it's really important because it has all types of essentials in it: bandaids, wraps, braces, ice packs, and a book of medical conditions. All our runners wear them, so it shouldn't be a big deal."

"Ok", you say reluctantly, "if you say so", and you strap on your backpack. The thing must way 15 pounds.

At that moment, the club's race coordinator ambles over. "Hey-o", he greets you warmly. "It's really important to know where all our runners are during the race, so we'd like you to strap on this ankle bracelet tracking device".

Again, you push back a little, "Won't this rub on my ankle and give me a blister? And can't I just use my phone?"

"Nope, I'm sorry", he says, "club policy."

As you finish attaching the bracelet to your ankle, you look up, and are met by the club's gear specialist. She hands you a new pair of shoes. "We like that all our runners wear the same shoes, just for consistency."

"But, this isn't the brand I usually wear", you stammer, "and wait...these are size 12, and I wear a 10".

"Yes, we know. We like everyone to wear the exact same pair of shoes, so that we all are wearing the same pair of shoes."

"That doesn't make sense, though. I have a different foot type than the other runners", you plead. But it's no use. You put on the shoes.

Finally, you make your way over to the starting line, but right before you get there you bump into the club's running strategist. He hands you a shiny, color pamphlet with a bunch of nice info-graphics in it. "Please read this before you run. It explains our micro-burst strategy for racing", he says. "Basically, we'd like you to sprint for 30 seconds, then walk for 30 seconds, then sprint again, then walk, and so on."

"Wait, what?", you question. "Does that work? Do I do that for 26 miles? And have you actually tried this before? Are you even a runner?"

"No...well...I used to run 15 years back, but I don't do that anymore. Running is kind of, you know...low-level. I do read a lot about running though, and now I just help runners by telling them about best practices. Anyway, you better get to the race, it's starting in a minute."

"Ok, whatever." You're beginning to feel a little jaded by all of this encroachment, and you just want to get to doing the thing you enjoy: run.

With just a few seconds before the gun goes off, you see the head coach out of the corner of your eye. He screams out, "we need you to run this race in under 2 hours. Can you commit to that?"

"Are you crazy?", you shout back. "Even without all this crap, the fastest I could possibly run it in is a 3:30".

"I'm sorry, but I need you to commit to running under 2 hours. Can you do it?"

"Are you asking me?"

"No, not really. So can you do it?", he again prods.

"Ummm...sure, whatever. I'll run it in 1:59." you shout back.

"Great. I'll mark you down for 1:40, because it shouldn't be that tough. Just push hard. You can do it."

The gun goes off, and right from the start, you feel weighed down by the backpack and you're tripping over your shoes every 5th step. You try a few micro-bursts, but obviously that doesn't work. No fucking surprise. You're getting bitter.

A few racers pass you, and then a few more. Some of the other racers are running solo, but some are racing for other, smaller clubs. Everyone seems so much freer. And faster.

You slog through. By mile 15 the ankle brace has rubbed through the skin. Your shoulders are in knots from the backpack. You look over and see the coach behind a barrier, staring at you and gesturing to his watch impatiently, the international sign for "hurry up".

You push harder, surrounded now only by people from your club. Everyone else has passed you by. You pound through the remaining miles, and get to the finish. The clock says 5 hours and 47 minutes, but it feels like longer.

Despite all the pain, you do feel a strange sense of satisfaction. Sure, you're 2 hours over your usual marathon time, but the fact that you finished it at all is an accomplishment. You high-five the handful of runners from your club who were able to finish, then go get your massage, put your new gear in your backpack, and walk to your car, vowing never to run for a big club again.



I've done a few stints at large companies, and actually have appreciated and learned from each opportunity - but it was certainly frustrating. For those fighting the good fight at these companies, I have great respect. In my experience, the toughest problems to solve in these environments are often not the technical ones, but the social, political, and organizational ones, and with a little mindset adjustment, I think they can be just as interesting and challenging, but it's obviously hard when what you probably most want to do is just build good software.

In the way of advice (because what kind of blog post would this be without advice?), here are a few survival tips I picked up during my tours of duty in corporate-land. First, be a little bit cunning. Just a little bit though. Not deceitful or malicious, and not to pursue your own ambition, but make the conscious decision that your job is to do what's best for the company, and sometimes this means finding ways around or through the over-bearing policies that get in the way of that. "Forgiveness over permission" seemed to be the mantra of the most effective programmers I met.

Second, use your work to get past the blocks and blockers. If an ivory tower architect tells you that your approach is impossible or sub-optimal, go back to your computer, put in the extra hours, and at your next chance give a demo of how it does work. Or better yet, show your prototype before you get any feedback. In other words, put in the work, and then let it speak for you - try not to get bogged down in the endless meetings and other bureaucratic shenanigans.

Anyway, I'd love to hear any of your tips or tricks for not just surviving but thriving (and dare I say, enjoying) life as a programmer at a big company. Please share!

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (5)
October 15, 2019
This just sounds like you don't want to follow any standards and want to be the coding cowboy, doing whatever you want while the rest of the team always has to clean up after you.
Saying "ignore what you're told to do and do it your way anyway" is not good advice.
October 15, 2019
@Human - Thanks for the comment. Fair point, but not the case. I believe strongly in collaboration, standards/consistency, code reviews, and other team-centric practices. I've worked on/maintained code bases written by "cowboys" who went off and made ill-considered decisions, brought in obscure frameworks, etc...and I agree, that's not a good situation either.

I do believe that at some big companies (particularly ones where technology is a cost center), the rules, standards, and decisions can often be capricious and over-bearing to the extent that it's difficult to do what the company hired you to do: build good software.

For example, you're constrained to tools/frameworks that don't address your problem because that's the "standard". Or you're forced to reuse some buggy/half-baked library written by an different internal group because management wants to say it does reuse. Or your given an old/crappy laptop with a bunch of CPU-hogging security programs running every hour and your local builds take 15 minutes when they should take 30 seconds. That's the kind of stuff I'm talking about.
October 15, 2019
@Ben - my tip for swimming in the big pond is simply: network! Growing one's circle of trustworthy people outside of their team/department is crucial for navigating bureaucracy and getting past blockers of all kinds (technical, political, otherwise).

@Human - who hurt you?
October 18, 2019
@steebe - great point. Having a strong network can really help when getting things seen/approved at a big company.
October 22, 2019
Seems most company could use Test Driven Management