Get Shit Done: The Worst Startup Culture

I was hired on the merit of my portfolio and past positions (I do not have a high-snob-factor college degree), and dove in and got up to speed pretty quick. Job was to implement a lot of Java code and some .NET for a major web-based marketing product. Management was completely by the book Scrum, including actual use of terms like "pigs" and "chickens" and such. I roll my eyes at that kind of thing, but I don't really mind and can just roll with it. It's by no means the worst "management design pattern" you could use.

The place had a superficially awesome culture, even had a foosball table. Roll eyes a little again, but who cares if it's startup-cliche. It actually is fun so again roll with it. Communication in the team feels good, stuff is actually getting done, etc. One person is a bit of a dick but everyone else seems cool. Nice view from the common office window. I feel pretty good about this job so far.

My first and only real hint that anything is amiss is that the code I am tasked with working on is shite. I mean hacky, ugly, uncommented, generally nasty-ass crufty Rube Goldberg machine Java code that takes over a gigabyte of RAM to do trivial things that ought to take under a hundred megs. It's also uninstallable. Just try running it in a dev environment. Seriously. Just try.

I had obviously been given the bastard child of a Red Bull fueled late night coding binge to untangle. That's cool. I'm on it.

My task, should I choose to accept it, was to add a few features to the product and fix a list of several bugs.

Problem #1: this code was so badly written it was incapable of handling the load of current customer demand. Short term solution #1: fire up more EC2 instances. I calculated that for this product alone they were spending almost 1/4 of my salary on EC2 compute instances to compensate for the code's general clunkiness. To do something that ought to be able to be done on a Pentium-4 with a gig of RAM they were running enough EC2 compute nodes to do protein folding on a complete genome.

Problem #2: the code was full of static, global, mutable state. This meant that the easy way of reducing overhead by parallelizing things was an exercise in banging one's head on the table.

I am told this needs to be done. I start feeling as if I'm getting pressure. Sprint is coming to an end soon. Everything I do fixes this or that problem but the boat anchor continues to suck so bad my demonstrations and tests fail simply on sheer bloat. Fucking nasty-ass sack of crap is so bloated I can't even properly test it on my dev workstation.

Fuck it. All weekend coding spree time. I am going to -- wait for it -- rewrite the core.

I stay up late all weekend at home doing this, coding furiously, and by Monday end up with a functional core of this product that does the same thing the old one did but used ridiculously less resources. The old version took many EC2 nodes to do what it did, while the new version does the same thing on less than 512mb of RAM on my Macbook and does it in a fraction of the time. Coffee has now supplanted hemoglobin as a principal oxygen/CO2 carrier in my bloodstream.

Unfortunately I'm going to have to spend a bit longer to get things done by the end of sprint on Tuesday, but never fear. I have cleared my schedule and plan to stay at the office until all sprint tasks are completed, which should now be do-able without wrestling a greased shoggoth.

The meeting is awkward though. I show this to people and I have a strong sense that something is wrong. Later that day I'm called into the office and told I'm being let go, though with a bit of a severance (??? not sure why but I'll take it).

Why?

(1) Performance doesn't matter. Don't I know anything? "Premature optimization is the root of all evil," even if said optimization saves 1/4 of my salary in compute costs and makes the product instantly responsive.

(2) "We don't want to maintain all this new code you wrote" -- but it was less than the old code, I argue, and the old code was... never mind.

(3) My favorite: apparently what I did was "not agile," and I would be "better suited for a research position."

Managing people is not trivial. So, to bring tech into it, it really boggles my mind when I see these awful styles. I mean, we spend years developing our skills, and break our arms patting ourselves on our back on how skilled we are. Then, for whatever reason, we end up on the people side and suddenly making it up as you go is fine. We have books on managing people - they are not a panacea, but I'm shocked at how few people in these positions have heard of them, let alone read them.

For example, the Microsoft Press books form the 90s are great. Debugging the Development Process, Software Project Survival Guide, Writing Solid Code, Rapid Development, and then books like The Mythical Man-Month, and Peopleware. Just a passing familiarity is all I ask. But no. Favored people and 'can't be hit by a bus' people get away with anything, great people with a few rough edges get fired at whim, no guiding principles on what it takes to execute a project (get shit done doesn't count, sorry), no concept of personal development. Ugh.