Dear God this was my life at a past employer. The biggest issue is that Get Shit Done usually turns to Get Shit Done exactly how I want even though I won't tell you what it is because I'm "Getting Shit Done!". I know better now. If I see that at an interview now, I'll run, not walk, run away. People bitch about how hard it is to find good developers and yet hire talented developers but put them in shitty positions. Then bitch about them not being good enough. It's like buying a sports car and putting shitty watered down gas in it and complaining about how the car doesn't perform like it should.
> People bitch about how hard it is to find good developers and yet hire talented developers but put them in shitty positions.
Notwithstanding the fact that the GSD mentality is often nonsense that comes from folks who don't know what they're doing, I would make the point that a lot of software jobs are "shitty" in the context of what many expect to find when they decide to become a developer. And that's life.
Even at many of the biggest names in tech, a lot of developers are performing mundane tasks that are not nearly as interesting or sexy as one would imagine. If even the biggest companies in tech, which deal with some of the biggest problems, can't create more "good" positions than "shitty" ones, it shouldn't come as a surprise that smaller companies and startups can't either.
Incidentally, it's like this in just about every profession that is glamorized in some fashion (i.e. investment banking, law, etc.).
I'm not sure if performing mundane tasks is the same thing he's talking about. When you are prevented from doing your tasks because of a lack of support by your company and a lack of communication under the guise of "Getting things done", you are given accountability without responsibility i.e. You are punished for failure but not given the tools to make yourself succeed.
Exactly. Everyone has to write migrations or make new branches in source control or a million other mundane tasks that few actually like doing. I meant a shitty position as in a job that should be a great gig but isn't because you are constantly told "GET SHIT DONE!" without being told what type of shit you should be getting done. I'm completely able to make up my own shit to work on but don't bitch if my shit doesn't match your shit that was locked in you mind.
I completely get that but a shitty job at a cool competent company that communicates well is a world of difference away from what should be a great job at, what turns out to be a shitty company. In other words you can be treated like a valued employee or like a scapegoat. How shitty your tasks are usually have little to do with which end you land on that scale.
"I would make the point that a lot of software jobs are "shitty" in the context of what many expect to find when they decide to become a developer. And that's life."
It is easy to develop unrealistic expectations and romanticized notions about a lot of things. That is life.
Tech companies aren't forcing employees to perform "mundane" tasks (fix bugs, refactor code, etc.) in air-conditioned offices in exchange for $xxx,xxx/year in salary plus benefits and perks the vast majority of American workers don't receive.
If you want something different, there are of course many other options. But here's an inconvenient truth: if you think running your own show (freelancing or building a business) is eight to twelve hours a day of fun and intellectual stimulation, you are probably going to be very disappointed when you're your own boss as well. If anything, "doing your own thing" is even more romanticized than working at Google, Facebook or [insert hot startup name here].
I agree with you but your conceptualization doesn't explain why people should put up with suffering just because they've seen suffering and are used to suffering. That's not logical. There's no reason to go in depth unless you can actually present an argument based on necessity or some kind of platform that would explain it other than "people put up with it".
Bah, it's a soul sucking reason. I quite my microsoft job to go bum around in SE asia while my SO finishes her TOEFL master degree. My startups annual revenue is only like 60k and I have two developers, an assistant, content guy and a designer on the payroll part time but I'll take my 100k less a year salary out here versus doing boring crap back at Microsoft any day.
Major upvotes to you - ignore these other comments, you're entirely correct.
A lot of these mundane jobs do need to be done, but a lot of people enjoy stable mundane jobs. Leave these kinds of jobs to them, they will actually thank you for it. If you're more interesting in accomplishing something, there are far more jobs that really need someone with some skill to come and do them - or, more realistically, find them.
I agree completely in the terribleness and lack of will in a statement like "That's life". No it most certainly is not. Life is entirely what you make of it and we are a long, long way from being forced to perform mundane tasks. If you can handle the stress of doing something new instead of doing something mundane - the door is always right over there. Walk through it and find your own path.
> A lot of these mundane jobs do need to be done, but a lot of people enjoy stable mundane jobs.
It took me way too long to accept this. I always thought those people just did not know better, or something.
I will never forget the QA department at a previous company and their ~200-step excel-based manual QA procedure. For me, that is basically a nightmare made reality. I tried to talk them into automating it, but they resisted that, almost angrily. They liked stepping through that 200-step spreadsheet.
I cannot understand it, at all, but I now accept it. People are different.
It could also be because they thought you were going automate them out of a job. People who aren't in the business of change don't like it as a general rule.
I actually took some pains to assure them I was not trying to do that. I offered to teach them the techniques I would use, which would actually have increased their market value. They just would not have a word of it. About 6 months later we were all laid off when the company folded.
I now hire spreadsheet testers on odesk for $10/hr. Upskill when you have the chance or die.
I think you may be confusing two different types of people. The idea, to me, of making $xxx,xxx while working 40 easy hours a week (manytimes fewer) and spending the rest of my time with money for my hobbies and lifestyle sounds great; I feel like I'm beating the system. Mundane tasks are the price you pay for that. There may also be people want to press that button 200 times, but they're a different group.
Why would you expect a corporate job to give a shit about you? It's not a person (regardless of what the Supreme Court says...), it doesn't have feelings.
Your parents love you unconditionally. If you want anyone else to care about you, you have to make it happen through your actions.
Why would you expect a corporate job to give a shit about you?
Why would I expect the company to treat me decently? Why do I expect the company to treat me decently? It's because people do not only have rights, they have duties towards their fellow man, that's why!
This is a long-standing idea in German political thought - it's called Sozialpflichtigkeit des Eigentums, and it made its way into both the Weimar and present constitution. "Eigentum verpflichtet", it says there. Americans have a hard time understanding this.
> they have duties towards their fellow man, that's why!
That's exactly what he's saying. It's a company, not a person. You are not its "fellow man"--because it's not a man. It's a legal structure that exists to generate profit.
It's not unreasonable to expect your boss to treat you decently, at least if you treat her decently. She's a person, after all.
But the corporation as a whole? The corporation is a system. It responds to the environment around it. If it doesn't make the right response (as in one that maximizes its chance of survival), it is replaced by other corporations that do. That right response may be at odds with your interests as a person.
You, your boss, your boss's boss, and all your coworkers are part of that system. If they don't take the "right" action (as in, the one that maximizes their chance of survival within the organization), they will be replaced by others who do. If you feel you've been mistreated by this, your only option is to look for a different place in that system where you will be happier.
It's a two-way street. It's not just that people should refrain from treating you poorly, it's also that you shouldn't put yourself in a position where you will be treated poorly.
The documentary "The Corporation" actually illustrates this point quite well. The psychological profile of a corporation is one of a sociopath, hell bent on making profit, at the disregard of all else.
Don't be loyal to a corporation, don't buy into propaganda about the well-being of the corporation == your well-being.
"It's a legal structure that exists to generate profit."
There just might be differences in the behaviour of an organisation that generates (and maximises) profit over the short term and one that generates profit over the long term.
The latter organisation may have to pay more attention to the 'social obligations of ownership' than the former, including the training and skill level of its workforce.
Same here. Although its true theres a lot of bad corporations out there, there are plenty of bad startups as well. People don't like to hear about great paying corporate jobs that treat you like human beings though.
This is a prime example of the attitude the author is warning against. This kind of anti-establishment ignorance comes from people with little clue as to how 99% of software is written...
Which is why a small but vocal minority of us prefer not to work in overly structured corporate environments.
No one really fucking cares that the implementation of the design is pixel perfect, they care whether it moves the needle whether it matches the design or not.
Like anything there is an effective version of 'get shit done' and a cargo cult version, most are the cargo cult version where people are not actually empowered to make decisions.
99% of software is developed in shitty cargo cult conditions, half the world lives on less than $5 a day, I don't care to trend toward the average. If you want to hold up the average as something to strive toward knock yourself out.
To play devil's advocate, I've been in startups where it seems like very little ever gets done and dithering and playing around with cool code becomes the norm. Eventually, a "bull dog" personality has to be brought in to light some dynamite under the ass of engineering and get them focused on delivery.
That’s not about what this article is about, at all. It’s about thinking that „get shit done” is somehow enough, not that being goal-oriented is bad. It’s about thinking that screaming that term around is somehow a valid management technique.
In fact, you don’t need a bulldog, more like an elephant. Patient, but smart, and they’re gonna get there.
I'd argue that is rarely if ever works well. I think there is a world of difference between playing around with cool code and the GSD path. Controlled, focused, and communicative processes, driving towards building the best, most light weight piece of software/system you can works better than either extreme. Work hard, damn right but work smart also. It takes both IMO. Software developers are smart people by definition, enable them to use that for the benefit of the company. If someone is just scrambling to meet an arbitrary quota because they need to "GET SHIT DONE!" they aren't making smart decisions, and as a startup that will kill you.
I had a previous job that was this way. Their informal mantra was "Do it now, scrape the blood off the walls later." In practice, this meant poorly communicated expectations, multiple conflicting reporting lines, non-specific project task ownership (everyone owned it, or someone else did and you were expected to as well), and best of all, no formal (or even informal) QA process.
No surprise then, that between the various forms of attrition (whether from firing, as managers spread blame and scapegoated, or quitting from those capable and prescient enough to see it coming) the company lost nearly half of its IT staff in a 12-month period, which included a major software release.
Yep, that pretty accurately describes where I once worked. But I don't think this is a bad thing from the perspective of the board of directors, only for the likes of you and me.
Remember, the goal is to spend as little money as possible developing a product/service and then sell out in 5 years. So you want to hire inexperienced but talented drones who will do as they're told and give you value for money (i.e. work their evenings and weekends for free). Anyone with the sense to push back on that needs to be cut loose fast.
> People bitch about how hard it is to find good developers and yet hire talented developers but put them in shitty positions. Then bitch about them not being good enough. It's like buying a sports car and putting shitty watered down gas in it and complaining about how the car doesn't perform like it should.
Also known as "iteration" and "failing fast" and "being quick to pivot."
These are not bad concepts when properly understood. Unfortunately they are rarely properly understood.
Hint: they do not mean "it doesn't matter whether what you do has any merit out of the starting gate," nor do they mean "quality doesn't matter, just fling shit and see if it sticks to the wall."
I wonder if this piece I wrote on one way for organizations to succeed without bureaucracy or heavy top-down management might not be of interest to those suffering from the "fail fast" syndrome: http://jasonlefkowitz.net/2013/03/how-winners-win-john-boyd-...
Not to say it's the only way to do things, of course, but it's a hell of a lot better than "Get Shit Done" ...
There's a spectrum. On one end are the large organizations stuck in analysis paralysis. On the other end are firms too busy getting shit done to fix root causes. You can put Google and Facebook at spots somewhere in the middle - where they are relative to each other says a lot about their culture.
Neither extreme fits 100% of the solutions. When your company (or market) is on life support, you need to only worry about the present. When it becomes habit, you can't move from saving the company to rebuilding it. And as others say, too much GSD is terrible for morale. It's good for 6 months to save a company. It's bad for 2 years of floundering.
Half of the work at a startup, or in programming (and many other things) is figuring out what to get done next. GSD isn't a problem in itself, the people who have both vision and GSD are usually killing it and I love working with those people. What you describe is more like a PITA-client who picked up GSD as a buzzword.
I think I have a different definition of get shit done than this blog post describes.
To me getting shit done means actually getting your work done. It means you don't read Hacker News all day long (oops) and send cute cat pictures to the entire office every hour. It doesn't mean you take every possible shortcut and hacky workaround to save a few hours of implementation time.
However, sometimes (and ONLY sometimes) that's what you are going to have to do. Just make sure you fix it later. If you do that all the time, it's going to blow up on your hands sooner or later (or on the hands of the poor schmuck they hire to work on it long after you're gone).
I work for a startup getting pressured by several BIG competitors that have all the advantages (client base, billions in the bank, established brand names, etc.), so we're under a tremendous pressure to "get shit done". There have been times (actually, I think only one time) when the right call was to get shit done in the wrong way of the phrase. We fixed it later. The core of the solution was solid, though.
We've also been unlucky to hire people who do NOT get shit done. It's like they have some sort of perpetual procrastination engine built in their brains. No amount of planning or iterating worked. Shit just wasn't getting done in any way, poorly or excellently. If you can't decide what approach to take, just pick ONE and move forward. Chances are you'll learn something along the way to validate or invalidate your approach, and you can then adjust.
I said this a while back in another thread, but it's actually more on-topic here:
One of the worst things about tech culture is that it's full of socially awkward people who have learned a neat low-effort hack for getting around their poor social skills: be an asshole.
Being an asshole is easy. It requires no actual effort spent in learning the intricacies of human social interaction or human nature. It requires no effort spent getting "outside your own head," trying to connect with other people, investing in forming genuine bonds or understanding the motivation of others. All you have to do is learn to at least feign confidence, to be superficially charming, and to throw your weight around.
The tricks of the asshole trade are status symbols, name dropping, rank-pulling, appeals to credentials (I went to Stanford so I am better than you), fast talking, claiming you have "no time" for anyone who doesn't kowtow to your superior assholery, etc.
Like many low-effort hacks it "works" in the sense that it creates a superficial sense of social proficiency and permits the user to navigate meatspace. Sometimes you can even get things done. But it's a cheap trick and it doesn't scale forward either in size, scope, or time.
This has nothing to do with tech, IMO. Wander over to Wall Street, go into some white collar office with a bunch of people doing data entry, go to some fulfillment center warehouse, and then go to a construction site and you'll see the same behavior.
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.
What I find particularly interesting about this is that, as technology creeps further and further into the mainstream, we're going to need more people writing/maintaining software. And they're likely going to be from the fatter part of the bell curve w/r/t skill (or else wouldn't they have become interested in software anyway?). So will it get easier or harder to manage coders when the average ability level moves toward the mean?
This is a good statement. Management is actually hard, and questions of leadership and management have been seriously thought about for centuries, because it is a hard problem that manifests itself in places where good results are expected.
I would argue quite the opposite is true, that being an asshole requires the same amount of work as being nice. Poor social skills are just that, poor social skills. Being an asshole is simply learned behaviour, it doesn't have anything to do with how easy it is..
I think the catch is that empathy is a large part of good social skills. And is something a lot of "socially awkward" folks are lacking. When you have a massive inability to understand the person on the other end of the conversation, it is not surprising when you learn to ignore them. That is, be an asshole.
Definitely! empathy is such an underrated skill for consultants (use the term broadly, anyone who provides a service to another). If you can't understand, via basic communication, the other person, how can you hope to serve them?
In my experience GSD is just an excuse to avoid the organization and planning work that's not particularly interesting compared to banging out some code.
I've seen a lot of startups just failing utterly because their primary philosophy is this one, and it tells them that it's ok to skip the hard/boring parts of your duties.
On the plus side those who are thinking through their experiments and still failing fast but intelligently choosing what they are trying rather than just skipping the planning and hammering out some code can really out-compete their GSD'ing competition. I have some good friends doing exactly this and doing it very consciously right now (just yesterday I told them they should call it Hammock Driven Biz Dez since we are all Rich Hickey fans). It is working very well, and that's measured in revenue.
Last company I worked at, we were doing planning for 2 years and have yet to ship a product. There is something to be said for GSD, but only for startups in teams of under 10. Why? - because shipping a product gives you something to look forward to, live product is something you can brag about show and change the world with. It is better to ship than not to ship. If you can't do it in 2 months - cut features out, etc etc.
If you have razor sharp focus and most people are apt in their roles and know what to do without looking up to a central person - thats called teamwork. However when you get to point when you start getting less focused and start looking for a new target, things got to get reorganized, thats when GSD is useless. When realigning troops you got to give some wiggle room instead of blindingly forging ahead, maybe off the cliff. When you hire more people - grow beyond original team - GSD can be a bit hard to deal with and frankly destructive on the whole to the growth of a company.
Yes, obviously over-analysis/over-engineering is also bad but I'm not sure why that provides any evidence that doing none is good.
It is definitely not impossible to fail fast and emphasize MVPs and shipping while still being highly organized. People do it all the time, and they produce way more useful features than the GSD'ers because they are organized. And by the time they've been working for a few months they are moving faster than the GSD'ers (in my experience anyway, the actual timespan probably depends on how complex the problem is).
Maybe we aren't agreeing on what exactly GSD is? Because even on tiny projects where you come up with an idea and ship an MVP a week later I've abandoned the GSD style blind flailing. I spend maybe 5% of that week thinking about it and planning a few things out, altering that plan as you build it and another maybe 10% keeping technical debt low. That thinking time saves at least a few dead ends that I would have otherwise gone down. The low tech debt makes debugging easier throughout the entire rest of the 85%.
That 15% investment has never not seemed to pay off. Not so far. And then on week two, when there's feedback and it's time to iterate you are sitting pretty, not starting from scratch and just winging it some more like you would be with the GSD strategy. I've done both, and I really can't emphasize enough how much of a payoff there is to keeping lightweight, flexible but mandatory process in place. Always.
GSD style cowboy development is something I kick myself for wasting so much time with when I was younger, and it is totally natural to fall into that style when you like writing coding and are lazy.
Sorry, that was quite the wall of text, I guess that's my 4c.
I'm not sure why so many teams go for the extremes - either zero planning, or planning out the wazoo! For most situations the best methodology is going to be somewhere more near the center.
Sure. Friday on LinkedIn I got one of those "recommended jobs" thingies in my story line. It was full of "you should value execution over planning". It pretty much sounded like a 20hr/day sweatshop of fighting endless bugs and chasing the whims of the founders.
Are the VCs listening to this? You are funding people who don't take spending your money very seriously. There is a huge continuum (shall I say gulf) between not over-engineering something when you don't yet have proven market share and just randomly tossing shit together.
With a few exceptions, I think the VCs are fueling this kind of mentality. It's not really their money. Netscape was the perfect model for this kind of behavior. Just ask JWZ.
Throwing something together and putting it in front of people aims to answer the question of "what does the customer actually want?" Until you've answered that question you can't build a professional product - otherwise you're building without a defined set of requirements.
Many entrepreneurs I've met hate the fact they're writing utter crap code, but without the budget to make mistakes (e.g. building the wrong thing), you have little choice.
I am not sure if you are disagreeing with my comment, or expanding on it, so let me clarify.
That was the point of my 'continuum' comment. If you don't know what the customer want, sure, one way to answer that is to prototype things and put it out there. In which case you are certainly not going to worry about whether the current system is scalable and so on.
But.
If your product is the front end to my bank, yes, do DO have to worry about whether it is a professional product or not. Even if it is a silly game, you need to stop and think about what you are going to put out - just hacking some shit together is unlikely to result in a product that people want. That is what we are talking about - think about what you are doing, adapt your strategies to your goal, and so on. Naturally that sometimes leads to substandard architecture - most understand and accept that. But to just run around randomly doing shit? That way lies madness.
Sorry, this is about impossible to capture in a single post, or series of posts. But so many companies have taken the difficulty of requirements definition and somehow conflated that into a 'ready. fire. aim' mentality about all aspects of the business.
edit: for a long time I worked in avionics. This was a vertical silo. Let's ignore the human safety aspect, which of course sways engineering quality immensely, and focus on the silo part. It was mostly really clear when something was a throwaway, and when something had value beyond a single product. For example, code to display an HSI. You could hack that out quickly for a trainer, but hey, look, we work in avionics. Think that just might be useful even if this trainer ends up thrown away? Of course. So, you might put a bit more effort into that part of the project. I wrote code in 94, for a prototype, that is still running today in many different products. Small parts of that code, but the important bits. 'Get Shit Done' doesn't even admit that conversation, whatever the right decision might be (there are certainly budget/time cases where you might just hack it together).
Many of us who have had jobs for a long period of time know exactly what problems need solving and how to solve them. What the market wants is not always a mystery.
There are those who believe that projects don't need any management, just "doing/executing". . .and that when projects fail, it's because project management got in the way. . .which is true sometimes, but not usually.
Yes, I worked at a large media company where the GM would run around saying this exactly in this way. However, ON TOP, there was a massive PM department that was poorly setup and just slowed everything down. Worst of both worlds.
It's not all of project management, but it's part of it: projects do not exist for their own merits, but because they are delivering something of merit.
A lot of shops spend months talking about how cool the new architecture is going to be, how cool its features will be, how cool its scalability will be, how cool the future is going to be…and never end up supporting the business with something, now.
The whole start-up culture encourages this behaviour. The current fire fast trend, rather than trying find the root cause for example.
Firing someone can completely mess up someones career, but people are being told to fire someone on a whim, if they're not right fit(I mean that could be anything). Turn it around, and put yourself in their shoes.
It's an odd trend in part because it doesn't seem like companies can afford it. At least, they complain about the results: can't find and keep enough good programmers. If there were a huge pool of easy to find qualified people, just firing people at the first whiff of difficulty, rather than debugging management, could be a viable strategy. But if good people are hard to find, firing a good engineer for "bad fit", rather than first trying to figure out whether the fit is a management issue, seems shortsighted.
Or at least, if you take that strategy, I'm not going to have a lot of sympathy for complaints that good developers are hard to find! If this strategy works at all, and companies really can take a haphazard approach to management and succeed with it, it would suggest that good developers aren't really in that short supply after all.
By the otehr side, not firing can completely mess up a small company, but nobody ever likes doing it.
People repeat a lot of "mantras" that say you should do something contrary to human nature (fire fast, get shit done, speak in a lot public, try to falsify your hipotesis). They are very important, as human nature dictates the default action every time, we need to be constantly reminded that the default may be wrong, and that we should stop and think about it.
But then, stupid people exist, even if they are stupid just a small fraction of the time. And those people will make stupid decisions. There is no procedure, environment, or technique that solves "stupid".
I experienced "fire fast" on the receiving end once. It's the one and only time I've been let go for any cause from a job. It occurred at a shall remain unnamed big startup on the East Coast.
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."
Going to go off the deep end here and say you really were at fault. You can't just rewrite whole systems as a new hire on your own decision with zero buy in from other colleagues or management. While the technology is important in a startup, you kind of tossed the team out of the window there and likely just replaced code that everyone else understood (however bad it was) with code that nobody except you understood.
Basically your approach was terrible and working in a company is more than just producing code. You should have had a chat with whoever had previously been involved in the system as well as whoever in management was in charge of it and explained the issues. They might have told you that the system you had just rewritten was being discontinued in 2 months for a different system someone was making, etc.
I get the desire to just fix any code you come across and it's a great desire to have - but take 15 minutes to communicate with your team - or hell, just send an email before rewriting a whole system.
I wasn't clear in my OP: there was poor communication on both sides here. I was receiving mixed messages, with the company's VP basically claiming I wasn't able to deliver anything good enough and my immediate boss telling me to kind of punt on the thing. In retrospect I should have dug more deeply. Actually in retrospect I should have started looking for another job, since the VP line-jumping the team lead is a sign of insanely dysfunctional politics.
RyanZag is right that the way you approached this was probably not ideal, but it's quite appalling that the response to a raw display of passion and technical talent was dismissal. They don't deserve you, really.
Sounds like a Daily WTF, but it's also very common.
Its seems most companies don't realise the easiest way to move fast, is a extensible, easy to change/understand code base. And not going through spaghetti code with a fine tooth comb. Odd they recommended research, they only care about one off prototypes.
The problem is future employers assume your the problem.
Btw, Proper scrum/agile encourages people to refactor and keep technical debt down.
Luckily this engagement was so short, and followed after a period of independent consulting, that I was able to be only slightly dishonest and call it a short-term consulting gig.
Thing that pissed me off the most was that I was proud of this code. It was elegant asynchronous java.nio-based stuff that used something like 1/100th the RAM and brought the product's response time down from a several hours "we'll get back to you" to less than a minute for small customer sites. It could also run the entire product on one EC2 compute node instead of like a dozen. I also commented it thoroughly and wrote a design document to hand to other developers describing exactly how its central queue based async architecture worked. Every method had a complete JavaDoc comment including the method's "contract," etc.
It's actually some of the cleaner code I've written. Not the thing I'm most proud of, but probably on the top ten.
Didn't have full unit tests yet, but could have done that in a day or so easily.
The second thing that pissed me off was this: I have a strong suspicion based on circumstantial evidence that the fact that my college degree is from a po-dunk Midwestern school had something to do with it. I have a strong suspicion that what I did would have been brilliant if I'd gone to a top-ten university. The founder apparently had such a hard-on for top-ten talent that he wrote about making sure candidates were from "the right schools" repeatedly on his blog, and I got the sense from the get-go that he was skeptical of my hire.
Whatever. My career is looking good and I can probably code the guy under the table so :P
> The founder apparently had such a hard-on for top-ten talent that he wrote about making sure candidates were from "the right schools" repeatedly on his blog, and I got the sense from the get-go that he was skeptical of my hire.
Fuck these people. I have a fancy degree and I work with better programmers who never even went to college.
I work for a client that is very scrumy and I did a huge rewrite/refactor similar to you one week, although probably smaller considering I also delivered the other tasks expected for the sprint. Nobody even cared that the rewrite made the product 10x faster. Nobody cared! But they were ecstatic about other lame changes that were assigned.
I think it's because management didn't ask for it to run faster, but they did ask for the other things.
The next week I got asked to find out what my changes broke because the app is behaving so much quicker. I had to remind them that I rewrote the slow part and there's nothing wrong. Still, nobody was excited... except me, because now it was a lot easier to develop with because it was faster and easier to debug.
> Btw, Proper scrum/agile encourages people to refactor and keep technical debt down.
How? At the place I worked that followed agile by the book the backlog prioritization was done by product owner, who prioritized by the value to the business. Since it was a customer- (and hence sales-) driven business, any trivial change that was visible to the customers ("change subheading to Verdana") was prioritized higher than any refactoring.
Two-week sprints also meant you couldn't really commit to anything that would take two weeks + 1 day.
We allocate so many sprint storypoints for keeping technical debt down. That's a fixed amount, immune from interference. The value justification is thst it allows you implement features faster long term rather getting clunkly a codebase. So it does provide customer value.
In this case my part of the sprint probably would have run over by one day, since I had one more feature to implement around the new core I had written and I had to spend extra time refactoring code for existing features a little (not too badly) to make them work with said new core code.
The logical thing would have been to punt that one feature, make everything else work (it was very close), then spend the rest of the sprint testing before swapping the old boat anchor out. Either that or keep the old version in place until the end of the next sprint to give time for complete unit tests to be written.
Apparently the fact that I had "rewritten something for performance" was viewed as an inherently bad thing to do regardless of the rationale or benefit. That's because some smart guy once said it was "the root of all evil," and everyone believes smart guys who are quoted a lot.
I really have a pet peeve about cargo cult thinking in general. Concepts and ideas have context. To me it's a sure sign that I'm dealing with an impostor who does not actually understand their subject. Yet another reason losing that job was a blessing in disguise.
I agree that there is a stigma attached to being "fired", but in the real world it's something that can happen, for reasons completely unrelated to one's worth.
For someone with a solid portfolio and demostrable previous experience, something like that should be nothing more than an unfortunate aside.
Well normally you get the offer only then do you give them your references - get knocked back the then you get your layer to get the papers from the section process.
Now Mr HR manager lets say 30k for a compromise agreement shall we and you fire the person that decided to accept the libelous statement for my ex employer - and when do I start :-)
I attempted to communicate the fact that something would have to be done about this code base if it were to scale beyond "beta," and talked a bit about making this an official part of the next sprint. The decision to do a barn storming run was a result of pressure and mixed messages. I was getting e-mails from the VP (not my direct boss) sort of implying that I was being slow and that my performance was not satisfactory.
In retrospect I may have walked into a political trap, but it's cool because I don't want to work for a company with politics like that. I also think in retrospect that there was poor communication on both sides. I didn't communicate the issue quite clearly enough, and they didn't communicate their priorities clearly enough. I also think getting mixed messages from different people above me in the company hierarchy really confused my sense of priority. If I hadn't gotten that I probably would have just done what I could on the issues at hand with the strong recommendation that the core be rewritten and moved on to the next sprint.
Yes. They are actually a fairly hot company on the East Coast.
In retrospect I do realize this: they are not a tech company. They are a marketing company. They have a couple cash cow products and their audience doesn't care much if they're slightly rough around the edges. So in a sense I was polishing their product in a way they did not think was important. I disagreed -- personally instantaneous response times are a big selling point for me and I did point out the hosting cost savings which were non-trivial -- but I was not the boss so that's how it goes.
"Everyone has the potential to be productive or unproductive. There aren’t people who are A players and C players. Just people who are performing at an A level and at a C level."
But some people will go from 0 to A faster and with less assistance than others within the scope of a specific set of tasks for which they have innate talent or relateable experience.
Further, if the skill set demanded is fungible it is cheaper to buy talent than build it in-house. Firing a C to hire an A is better business than hiring a C and expending time and energy to increase the probability of them converting to an A at some unknown point in the future provided that there is a ready supply of As (or Bs) on the market. With regards to entry and mid-level programming positions, that appears to be the case.
Unfortunately, it's difficult to evaluate the quality of the work that you will undertake as a developer from the outside. This leads to tons of employers with C-quality work clamoring for A-quality individuals when they could find a B-quality candidate much easier.
How much of 'business' is predicated on this zero-sum mentality? It's all very tiring. You don't need the best; you just need good enough.
"How much of 'business' is predicated on this zero-sum mentality?"
This is a problem of asymmetric information, i.e. employees generally knowing themselves better than prospective employers, and wide uncertainty bands around the evaluation of prospective employees. A rational employer retains a C over replacing them with an expected B who might be an A or an F.
GSD for us is less of a management tactic and more of a trait we find in engineers. Some engineers spend too much time in the design phase, planning out features nobody is going to use. GSD is about finding the fastest route to a solution. The quality of the solution is orthogonal to GSD. Bad GSD results in spaghetti code. Good GSD means providing the minimal solution without painting ourselves into a corner. It means a clean interface and set of behavioral tests with perhaps a hackish library implementation that can be pushed to production. Building out that hack vs taking the time to "do it right" can mean 10s or 100s of thousands of dollars of revenue. Sure it builds up a bit of tech debt (which we resource immediately), but that's often well worth it.
The only way this "strategy" works is if a few things are already happening:
1. Communication is already really good
2. You have a basic plan in place, milestones laid out, and because of #1 being good you're ready to handle anything that doesn't go to plan (because things definitely won't)
3. If you have a plan in place you better have discovered some hint of product-market-fit (figured out who your customers are, what pain point they have, and how you think you can solve it) that the plan is based around
If you have those things in line, there isn't anything wrong with "get shit done!" (which I really take to mean less meetings, less screwing around over-planning, etc). This mentality or strategy backfires when you are missing a few items from my list, or you have bad managers / founders who don't understand the importance of the list.
Agreed, there is nothing wrong with GSD as long as it's organized.
I see this in science all the time, "I'm too busy to show you how to do something, just GSD!".
That ends up meaning:
1. GSD
2. Do it again, it wasn't done right
3. Do it again, because it still wasn't done right
(repeat 2 & 3 a few times over)
4. ....
5. Profit!
This would be more effective if they followed what you posted, then said "GSD". Communication, planning and proper support are critical and without them, you aren't getting shit done, you are getting SHIT done (and wasting time).
Plan quickly, train quickly and throughly, then get shit done effectively. GSDE would be a better mantra.
It's like anything else, if taken to an extreme, you can make anything bad.
The inspiration of "get shit done" are the bureaucratic nightmare environments where the mundane and irrelevant are debated for weeks, months or years, and many people make careers out of coming up with excuses why things cannot, should not, or will not get done.
Some not-so-good managers with poor leadership ability turn this into a power trip. I'll tell people to "shut up and get shit done" when I sit through a meeting that's nothing about debating things that aren't important, or just travelling down rabbit holes with no way out. And I don't deliver that message in an offensive or nasty way.
We just got a bunch of "startup vitamins" at our new office. My "favourite" is "Fuck it. Ship it."
Hmm, this doesn't pass tests? You didn't run the tests? It breaks something else? Fuck it, ship it. So now when support comes and asks why everything is broken, I just point to the sign.
I think the author is missing one of the points of 'get shit done', which is instead of debating whether you should use Go/PHP/node, just fucking do it. Instead of agonizing over a design choice, just make the damn thing and tweak it later. Don't over-engineer things.
This can't be overstated enough. Just getting started on the problem is half the battle. Choosing a naive solution is fine since a) you can improve it later, but with better more actionable knowledge b) it is very difficult starting a complex project from scratch, so you might as well just start somewhere.
Exactly. "Get Shit Done" is basically Agile development. If developers were left to draw their own agendas most would get bogged down in refactoring code so that it's perfectly extensible and uses the latest prettiest and more efficient architecture.
Developers are often perfectionists, and perfectionism is something you often need to keep in check, b/c at the end of the day you need to deliver a product.
I couldn't help but feel that this was a blog post that I've been meaning to write for a while.
This, mixed with "beer culture", and measuring productivity based on hours sitting in the office as opposed to features produced/bugs fixed. Complete disregard for security vulnerabilities that may put our users at risk because "we don't have time for that shit", issues of "you are not 100% committed" when you leave on time one day because your mother is terribly sick. Stalking your LinkedIn then making a huge fuss about it when it clearly hasn't been updated in a long time, adding the fact that you have a website to not "100% committed", etc.
Guess it's time to finally go write that blog post.
Anyone who has endured more than one startup will tell you GSD is a bullshit line. The only people who ever mention this are those who usually have not been in a position of control to execute (usually because they worked at BigCo, Inc.) and are now free of those constraints. It's the occupational equivalent of moving out of Mom & Dad's house and getting your own place.
GSD, when first brought up, was about the fact that startups needed to not over-analyze and move to do things simply. And, if you moved quickly, simple solutions would follow. Or so the thinking went.
But the goal was lost in translation, and now GSD looks like something that should die along with other awesome concepts such as bro-gramming.
I won't call what we're in a "bubble", but the culture seems to be going in the direction of mass producing startups, and this is the result. I see many startups popping up that seem to be creating a product just for the sake of creating a product, with no real long term goals.
Some VCs seem to be encouraging it, throwing millions at redundant social network apps that do things like "Gamify brushing your teeth!".
The tech industry has an immense ability to "make the world suck less" as Alexis Ohanian puts it, and it's important that we focus on that.
I'll put in a plug for Roy Osherove's "Notes to a Software Team Leader" which discusses some of these issues and how to deal with them. It especially deals with how to handle "overload" and the feeling of falling behind and the decreased productivity that can bring a team.
These sorts of generalizations do not end well. For example, if you really think that "There aren’t people who are A players and C players. Just people who are performing at an A level and at a C level." then fire your entire recruiting department and hire anyone who walks in through the door. After all, there are no bad people, only those who perform badly right? So if those strangers who walk in do not do well, it is the fault of your environment and management, right?
Management by catch-phrase, one-liner, pre-packaged "management methodology," etc. is about as good as code written in the same thought-free manner. As with code, good management requires deep consideration of the actual problem at hand.
There's a difference between the company who wrote it on the wall and the company who read it from the wall. There's surely more to "The Facebook Way" than 3 words can convey.
I used to say "Get Shit Done" to my team, but for a different reason. That company I was at then is (still) so bogged down in meetings, changes, planning, etc that nobody ever had more than a few minutes to code without hours of interruptions.
So, different scenario but I get the post's point.
It's already down (it's the database... why does it always gotta be the database... sigh. Actually, it's probably a blog post so why is it even hitting the database to begin with instead of being served from cache?)
I guess someone didn't prioritize "getting shit done" haha
Don't feel bad about the crash. My wp blog also crashed the first time I got to the top of hacker news. You will learn a lot making sure that won't ever happen gain ;) Caching is going to get you through this one but checkout c10k.
WordPress' inability to stand up to even moderate levels of traffic is well known enough at this point that the product really should come with some kind of caching solution built in, IMO. Yes, there are caching plugins, but the users who need them the most are also the ones least likely to know they need them.
Software users not having a comprehensive understanding of the technical complexities of their software is nothing new. It is, in fact, the status quo , as anybody who does IT work for a living can attest.
That WP should have built-in caching, I cannot argue, but once the choice is made to use it, it becomes the chooser's problem.
On one end of the spectrum, you have non-technical people going for wordpress.com accounts that are hosted by Automattic. On the other hand you have fairly technical high-traffic users like New York Times or CNet hiring either their own technical staff (or, once again, outsourcing that to Automattic).
The target market of "people technical enough to download, roll out and host their own version of Wordpress, but not technical enough to find and roll out a plugin" is fairly small.
They could probably package WP-Cache with a default distribution of WordPress, but since that requires allowing write permissions on some directories, I suspect they're erring on the side of security.
What are you working on? / The shit.
How much longer? / Not much. Almost done.
Is it hot? / It IS shit.
Is it tight? / It's DONE.
Awesome. Can I blog about it? / Yeah... you're the CEO.
Later...
Hey - this is a pile of shit! / It IS done.
You're a cog in someone else's machine. You are a means to an end - which is some form of naive auto-fellating bullshit. Shut up and get the shit done. Someone wants to disrupt the treehouse club!
Treat me mean. I need the money.
Maybe they should A/B the color of their log in finding the A players.
I'm nervous to think that "get shit done" is likely the current mantra of Healthcare.gov, as contractors are scrambling to fix an untested spaghetti-codebase before Thanksgiving....
> There aren’t people who are A players and C players. Just people who are performing at an A level and at a C level.
That sounds very nice, like something Barney the Dinosaur would say. People who consistently perform at C level are C players. Maybe they would be A players doing something different but that's not much use to you.
Of course they are. Get them doing that other thing they are good at. People naturally gravitate to tasks they are good at. Are they're any tasks they are voluntary doing? Is there a full-time position for this?
Great post, David! You especially nailed it with the paragraph about disciplined routines and productive habits. In retrospect, we'd wasted more than 10 years in our company by just getting shit done. Our solution to this problem was to keep a simple "logbook" to regularly record and reflect our achievements and experiences in a team context. (We released a public version of our internal logbook tool called "teamspir.it" a couple of months ago.) I must admit that it was damn hard to convince all of our team members that it is really important to write regularly. Even today most of the people I talk about this habit ask "Why the hell should I do that? I know what I've done, no need to write it down...". There are several good approaches for answers to this question in your post!
As the manager/co-founder, helping with tools, coping mechanisms, etc. is often not enough. When an employee has shit falling off of his/her plate, he often needs help prioritization. Managers/co-founders often assume everyone knows the priorities of projects and that's often not the case. If the manager's or company's priorities have shifted, that needs to be communicated to everyone. If you have a meeting scheduled with some big-wig tomorrowand I'm providing data for that meeting, I need to know; otherwise you may not get your S until it's too late. But, by God, I'm GSD!!
"Get Shit Done" is completely different than the other ideas lumped in here, ie "ship something", "fail often" etc. Many people may mistakenly apply these concepts in such a way, but it is not inherent.
The assumption made in this article is that startups with the "get shit done" mantra only say to "get shit done" when you're not performing. I feel like the entire article is based on a bad assumption..
This isn't really a problem with startups but people in general. The average person just isn't very empathetic, and especially so when you you're focused and stressed out working around the clock during a startups early stages of life. Also: if you were a CEO or manager what incentive is there to try and dig deeper into why someone is unhappy with their job? Most of the time, its not fixable, and interviews are there to help filter out individuals who aren't a good fit both on a technical and personal scale. Now, if all of your employees are unhappy thats a different problem.
Kind of offtopic, but it really grinds my gears when a site is perfectly functional without javascript, but then it has a noscript element blocking you from reading it. I know how to hide the noscript element. Even if it's not a noscript element, I know how to delete it from the DOM tree. Why would a site writer purposefully block people with js disabled from viewing their site? It's not like you can accidentally disable js in a browser, if it's off, it's off because I went out of my way to turn it off. And I can hide your opaque fullpage div just fine.
Another site reporting "Error establishing a database connection". For anyone posting blog entries telling people that they are doing things wrong, it really destroys your credibility when you can't set up a server that continues to function with a moderate amount of traffic.
Not everyone writes something with the aim of being on HN or reddit or anything else. Sometimes people simply write for the joy of it and don't want to bother with server upkeep.
Glad I didnt take my first offer out of school. This was exactly what that company was about. I knew classmates who took the jobs but left before 6 months.
They were paying 15-20% more for some positions, now I know why. Their motto was hire and fire, most managers were with them for less than 1.5 years and promoted because they were most senior after about year.
I think you interpret "get shit done" different than I do. Not trying to put words in your mouth, but I think you interpret as get this product out ASAP. I think of it as take responsibility for yourself, if you need a break, take a break. Whatever you need to do to "get shit done", do it.
I agree in that "Get shit done" shouldn't be a culture but a goal. It should be a reminder that, after all your pontificating about monads or whatever, nobody but you cares about that shit and you need to produce things that they do care about.
Get Shit Done is a value, not a management tactic. If managers are considering it as a management tactic then they are utterly incompetent as described in the article, however I hope and believe that's it's a strawman and this practice is not widespread.
No, there are definitely C players. People who, if you give them all the advantages in the world, will still be completely unable to perform at the expected level. It's perfectly possible for an A player to perform at a C level, but not the other way around.
Kind of depends on how you interpret it. Many developers over think and feature creep. When I see Get Shit Done I'm thinking about doing what needs to be done now instead of working on solutions to problems that haven't happened yet.
I think GSD is most appropriate for the earliest stages of a startup (ie. few to no employees), where you really do need to just get a working product.
Obviously middle managers screaming this mantra at paid employees is silly...
What's your experience with larger multi-layer structures, as if someone up the chain is pushing GSD, there is less opportunity to fix this downstream, leaving people to constant stress.
Tripadvisor's slogan is "Speed Wins," which seems like it would translate into "rarely pay down technical debt." It's always put me off of working there.
But if you rarely pay down technical debt you'll go slower. So maybe "Speed Wins" means they do pay down technical debt. Just playing the devil's advocate.
"what a good manager does is help this person identify the things that are causing them to be unproductive.
They’ll help them develop new habits and encourage them in their efforts to adopt them.
They’ll force them to take a step back and see the bigger picture.
They’ll work together to build new systems that will help them be successful.
Shit, at the very least they’ll recommend a good self help book."
Are you serious??? With all due respect, if you are not capable of developing new habits, stepping back and looking at bigger picture or (sigh) reading a good self help book on your own without someone holding your hand, then you have a problem. Wake up my friend and GET SHIT DONE!
no prob. sorry for the heavy stab. i'm a big advocate of getting shit done - i prejudged your argument as invalid before seeing it. :)
having now read the article you have a valid point. there is a real problem with the idea that people can be hired and left to autonomously work - its ignoring literally thousands of years of experience we have with leadership and its value.
i've had this exact same problem myself. its really quite difficult and offensive it seems to tell your boss 'please provide some leadership and management - its your job, /you/ need to get shit done before i can do mine...'. the best solution it seems is to not have to be in that position.
fortunately my current 'boss' always takes the approach of 'what am i doing wrong?' rather than 'why is he dicking me over?'
