Slashdot Mirror
'Eat, Sleep, Code, Repeat' Approach Is Such Bullshit (signalvnoise.com)
At its I/O developer conference, Google had the message "Eat. Sleep. Code. Repeat." spread everywhere -- walls, t-shirts you name it. Dan Kim, a programmer at Basecamp, has shared an interesting view on the same. He says while he gets the "coding is awesome and we want to do it all the time!" enthusiasm from the company, but he doubts if that's the approach a programmer should take, adding that the company is wittingly or not promoting an "unhealthy perspective that programming is an all or nothing endeavor -- that to excel at it, you have to go all in." He writes: Whether it's racing cars, loving art, reading, hiking, spending time in nature, playing with their dog, running, gardening, or just hanging out with their family, these top-notch programmers love life outside of code. That's because they know that a truly balanced lifestyle -- one that gives your brain and your soul some space to breath non-programming airâS -- actually makes you a better programmer. Life outside of code helps nurture important qualities: inspiration, creative thinking, patience, flexibility, empathy, and many more. All of these skills make you a better programmer, and you can't fully realize them by just coding.
Its a play on the Fatboy Slim song Eat, Sleep, Rave, Repeat. Someone needs to take the stick out of their ass. Maybe someone should buy Dam Kim a shirt with Keep Calm and Carry On plastered on it.
I code to get paid
When I work forty a week
Otherwise blow me
.
That "Eat. Sleep. Code. Repeat." mantra is odious, miasmatic bullshit. Plain and simple.
I'm trying to figure out how could possibly serve as a more ironically unwitting example of precisely the thing he's criticizing.
The point to having a balanced, happy life isn't to be a better programmer. It's to have a balanced, happy life.
Just more BS cop-out from those who can't. It's too bad Google is now full of this NIH thinking.
Jesus fucking Christ. It is a joke. Like those "[insert sport here] is life" shirts. No one really thinks Baseball is Life.
After 20 years in the business, I spend MUCH more time thinking about the problem and the best solutions than I do actually coding. If you're spending most of your time coding, that's probably mostly code I'll delete in a couple of years whwn I do it in a simpler, more elegant way.
This is a major motivation for going after young coders and avoiding people with experience. People with experience know about the burnout bullshit, but people earlier in their careers assume that is the way to get things done. Managers know who they can easily manipulate for the death march on an ill-conceived schedule. Someone who has been there before is going to raise meaningful objections and might alert the younger people that it's a pack of lies. Upper management can't make vast amounts of money unless the workforce remains ignorant about the real cost/reward equation.
Why is Snark Required?
I'm not sure how you make the jump from a company's stock price to how good its programmers are.
Your observations have everything to do with how much time the programmers are devoting to the company, and nothing to do with the quality of their code. A company that can get a single programmer to spend 16 hours a day working for them is probably going to be more profitable than one which needs to hire two programmers only willing to work 8 hours a day each - it's as simple as that.
Startups play the long hours they require from their workers against the hypothetical promise of future wealth to their workers. Thing is, that may have been how things worked out for the companies that created the tech boom in the first place... but that's not how it works out for the average startup employee nowadays.
#DeleteChrome
Code is a byproduct of ideas. The actual act of writing the code is the least difficult and least time consuming part of creating software. I can't even remember the last time I sat down to write code and didn't already have all the code in my head. Once the problem is solved in your head, it's just pushing buttons in an editor to bring it to fruition.
I think that's part of the problem with the software industry. People think they need to show up to work and bang out code all day. That's basically the recipe to writing buggy code. Let the code brew in your head for a while and then sit down one day and bang it out and you'll probably find that it's super solid, very coherent code.
If you are writing code and can't see the next 100 lines of code you're about to write, you're doing it wrong.
Based on my personal experience, that's not quite how it works. Programmers don't usually stay long hours because they're told to - they stay long hours because they are into what they're doing. There are crunch-time exceptions, of course, but if the company is making people stay long hours regularly and they don't care about what they're doing, they'll burn out and leave. So to some degree, people staying late at work regularly has some correlation with work engagement, which for coders is a good thing.
Personally, if I'm sucking at code, I'll try to escape earlier. If I'm deep in flow, I'll be coding until 2AM. And that's when I do my best work.
YMMV, of course.
Based on my personal experience, that's not quite how it works. Programmers don't usually stay long hours because they're told to - they stay long hours because they are into what they're doing. There are crunch-time exceptions, of course, but if the company is making people stay long hours regularly and they don't care about what they're doing, they'll burn out and leave. So to some degree, people staying late at work regularly has some correlation with work engagement, which for coders is a good thing.
Personally, if I'm sucking at code, I'll try to escape earlier. If I'm deep in flow, I'll be coding until 2AM. And that's when I do my best work.
YMMV, of course.
Exactly. And when you are there late, I'm willing to bet that the parking lot is practically empty. It's only the businesses that are failing to plan ahead or which are experiencing business problems that have the entire staff there at night consistently. It's more of a sign of flaw in leadership and business operations.
This investing strategy is pure BS. There are much more important factors in an investment strategy than if the workforce is at the office after 9pm such as product, leadership, talent, market, logistics, and funding. In fact, if a company has it's staff working at night consistently, it's more of a sign of underlying flaws in the business, leadership, or funding.
I wouldn't be so sure about this. Unless you're comparing businesses from a similar culture.
E.g. in Japan, presenteeism is an issue. People might be at the office for huge hours, but much of that time is spent fucking about rather than focusing on work. OTOH, in countries like Germany, if you don't get your work done in the allocated 8 hours, you're considered weak and incompetent.
Culture matters here, but also, it's up to the local leadership to set the tone. Some workplaces just have dumber managers who measure the wrong things when understanding developers' productivity. These same workplaces might also embrace technologies/approaches which destroy programmer productivity too (e.g. overreliance on online chat and emails, expecting devs to be preemptable at any time, etc etc).
IBM has a hell of a lot worse problems than their employees going home at a reasonable hour. And there are a gazillions startups where plenty of enthusiastic young programmers ruined their relationships and health, only to have the company eventually fold under them anyhow.
I can't see how working insane hours is any measure of success for a company. In fact, one of the most successful companies I've ever worked for (and this is in the videogame industry, which is notorious for its insane crunches) has deliberately insisted that their employees should NOT work long hours, because it's actually detrimental to both employees AND the product in the long haul.
Even the mantra I hear of of "programmers work long hours because they *want* to" is idiotic and self-destructive. Most people will eventually burn out, even if it's doing something they love, if they're doing it too long and too intensely.
Irony: Agile development has too much intertia to be abandoned now.
> wind up tossing the entire shebang
The entire shebang line?! That's like ten characters! :)
My dear employee
You are paid a salary
Work until it's done
And I will....at 40 hours per week. It'll be done when it's done, so stop harshing my buzz, man.
Just cruising through this digital world at 33 1/3 rpm...
> but I've seen dev houses measure quality by doing over 10,000 lines a day, regardless of bugs.
I find that lines-of-code IS a good measure for me. If I can delete 10,000 lines of data transform and transport code and replace it with a direct connection in 12 lines of code, that's a very successful day.
As an example, a project I'll take on soon currently dumps data from a database into csv and transfers it to a server via FTP. Later, another server retrieves the csv via CVS, transforms it into XML, and makes it available via another protocol. It's then retrieved by another system which imports it into another database. I will replace these systems with the following: ... FROM source.table JOIN source.othertable.
INSERT INTO destination.tablename SELECT
Literally I'll replace hundreds or thousands of lines with one or two lines. That's a good day; getting rid of thousands of lines of code.
they want lots and they want it now. The idea is to throw a ton of ideas at a wall and see what sticks. That means fast and cheap, not good.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
You can give an accurate estimate ...
I have rarely seen a programmer give an accurate estimate. Inexperienced programmers usually wildly underestimate how long a task will take. More experienced programmers will apply Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
The best way to estimate how long a programming task will take is to look at how long a similar task took for the same team in the past.
You drove by IBM? All the locations? That would take you quite a while...and a few plane trips...
People in cars cause accidents....accidents in cars cause people
The last 10 years have been much much easier ala Kenny Rogers
You've got to know when to hold 'em
Know when to fold 'em
Know when to walk away
And know when to run
The real bonus is that our work product is much more black or white in terms of acceptance. A musician...not so much.
People in cars cause accidents....accidents in cars cause people
When I noticed that IBM's parking lot was nearly empty by 6pm, I sold all my IBM stock. That turned out to be a smart move.
Do you actually believe this?
And if yes, do you think it was not the case during IBM's heyday in the 60s when they were unstoppable?
A hint: it was in fact the case in the 60s.
Therefore in IBMs case it is uncorrelated with success and so you made the right decision for wrong reasons but got lucky by random chance.
SJW n. One who posts facts.