Get Shit Done: The Worst Startup Culture
whatspinksthinks.com
whatspinksthinks.com
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."
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" ...
EDIT: Submitted the post to HN for discussion: https://news.ycombinator.com/item?id=6669129
Beautifully said!
GSD works so long as it's focused on shipping.
In fact, you don’t need a bulldog, more like an elephant. Patient, but smart, and they’re gonna get there.
What if shipping isn't the problem?
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.).
The only reason people put up with it is because they're told "that's life" or "that's just how it is." when that's meaningless bullshit.
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.
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 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.
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.
Don't be loyal to a corporation, don't buy into propaganda about the well-being of the corporation == your well-being.
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.
Because most of us don't speak German!
Sozialpflichtigkeit des Eigentums can be roughly translated as "Social duty of property"
"Eigentum verpflichtet" is more or less "Property committed (to a duty)"
It's a two-way street, and when you're a faceless unknown dealing with a large entity, you usually have to make the first move.
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.
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.
I now hire spreadsheet testers on odesk for $10/hr. Upskill when you have the chance or die.
"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].
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.
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.
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.
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.
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.
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.
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.
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.
It is never easy.
my 2c.
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.
We are doomed.
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.
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.
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).
People who hold to this philosophy should practice it while driving. This would reduce the number of people who hold this philosophy.
http://www.jwz.org/blog/2011/11/watch-a-vc-use-my-name-to-se...
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.
At some point, you gotta Get Something Done.
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.
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.
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."
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.
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
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.
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.
For long tasks you use a thing called epics.
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.
Looking back, did you feel like you were fully communicating your situation to your team? What did your manager say about your concerns?
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.
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.
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.
In a way, it was for the best, isn't it ?
It is clear that you weren't a good fit for their development team and their interpretation of "agile" software ...
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 :-)
For someone with a solid portfolio and demostrable previous experience, something like that should be nothing more than an unfortunate aside.
Either way you become enemy number 1 for the team.
Maybe your changes may have been accepted over time but no one likes someone to come in and tell them how crappy their stuff is.
I know that you didn't do this explicitly but that's the message that comes across.
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
So, different scenario but I get the post's point.
I guess someone didn't prioritize "getting shit done" haha
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.
Why? Do people with least technical knowledge just happen to build Wordpress-based sites attracting billions of eyeballs?
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.
Try refreshing.
Sigh.
Great post, btw!
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.
1. "Just" carries a hidden assumption, that the thing is simple and straightforward.
2. It's awkward to respond without tacitly accepting the burden of proof for why you can't do the thing.
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.
Cached version: http://cc.bingj.com/cache.aspx?&d=760352947104&mkt=en-US&set...
This worked for me:
http://webcache.googleusercontent.com/search?q=cache:http://...
Mirror:
http://webcache.googleusercontent.com/search?output=search&s...
edit: It does now! Strange. Thanks!
My host is working on the issue. Wasn't planning for a HN hit.
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.
Obviously middle managers screaming this mantra at paid employees is silly...
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!
cough... YES!
Now this Java shit is about to hit the fan.
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?'