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.
Sundarajan, a victim of Indian coding sweatshops now "projecting" his traumatic experience onto us
No seriously, why are we reporting on them?
It's not a statement of intent but an observation.
How can I believe you when you tell me what I don't want to hear?
There are at least two things there not directly contributing to Google's bottom line.
lies sell
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
Ideally, I only code 2-4 hours a day and then exercise a bunch. The rest in between lets you strategically think about your software's architecture so it is stable across updates. Thinking takes more than a couple minutes if you're doing significant projects, so you might as well go for long walks.
God spoke to me
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."
Obviously, only complete loonies would support such a preposterous idea as a serious time investment.
Ezekiel 23:20
.
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.
Going all in like this actually works. There needs to be breaks between projects or milestones for this shit to be sustainable though. The reason the industry constantly grabs new talent and lets them work like crazy is because that is actually a functional way to get code done. Every engineer doing that ends up with more working memory devoted to the things his code touches, and he is exposed to it every day. Saying "oh, doing all these other things makes you a better coder" is an extraordinary claim, and needs evidence. A better argument would be "if we work people tons they'll burn out" or "it isn't right to demand that people work this hard for your bottom line". Flat out lying isn't gonna cut it.
Everyone knows that coding is addictive and if there is something not working you are not going to sleep well until you figure out what it is. And you can eat and code at the same time. Relaxation time comes after the orgasm of a running perfect product.
Jesus fucking Christ. It is a joke. Like those "[insert sport here] is life" shirts. No one really thinks Baseball is Life.
Eat, Sleep, Code, Repeat
As long as Emily Blunt is my pair-programming partner ...
It must have been something you assimilated. . . .
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.
When I hear about a new startup, I drive by their office at 9pm on a Friday evening. If the parking lot is full, and the lights are on, then that company may be successful. But if everyone has already gone home, they will almost certainly fail.
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.
The assertion in the summary that a "balanced life" makes you a "better programmer" is not supported by any evidence that I have seen. I don't work long hours like I did when I was younger, but I am not as productive either. There is nothing wrong with living a balanced life, but don't kid yourself that there is no tradeoff.
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?
Eat, Sleep, Code, Repeat probably explains why there are so many silly bugs and braindead design decisions.
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.
The person doing 16 hour days is not turning out the same thing as two people doing 8 hour days. Even if they somehow sustain their level of effort, the quality of the code is going to be much worse.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
You see this when you go in for a job interview and they want to know, on top of your full time job, if you contribute to open source, or go to meetups, or otherwise pour your whole life into programming. Don't get me wrong, I love programming. And when I'm not doing 50 hours a week (the new 40) I like to do some for fun. But this culture of exploitation has to stop. It's what leads to 80 hour work weeks, not taking vacation, and burn out. It's exploitation pure and simple. And it doesn't work. People who are overworked underperform. And until the MBA's running the show understand that, they will have high turnover and poorer code quality than the companies that do understand it.
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.
Old model. The last startup I worked at had 8 programmers in 7 different states. Nobody was "at the office" ever. But I could get online on my couch with a cat on my lap from 8 am til late at night and knew that most of the others were as well. All connected via chat room. Saving two hours a day of commuting made us all more productive.
Intron: the portion of DNA which expresses nothing useful.
My dear employee
You are paid a salary
Work until it's done
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.
You might have heard of this little program called "the Linux kernel".
https://www.kernel.org/pub/lin...
The assertion in the summary that a "balanced life" makes you a "better programmer" is not supported by any evidence that I have seen.
I think that having a "balanced life" makes you a "better everything". A better employee, spouse, parent, etc etc etc.
Bragging about working like a dog and putting 80-hour weeks is for suckers who haven't grasped that there's more to life than work.
Sure, I've put in some long hours on occasion, but not often and not regularly. I work to live, not live to work. Fuck that shit.
Feel free to spend your night coding function calls if you want...but while you're doing that, I'll be having dinner at a nice restaurant with my wife.
Just cruising through this digital world at 33 1/3 rpm...
> wind up tossing the entire shebang
The entire shebang line?! That's like ten characters! :)
> 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.
Can you tell your manager how long something will take? Have you tried doing so in a matter-of-fact, polite but firm way? Can you give an ACCURATE estimate?
I haven't worked for very many companies, but I haven't had this problem, not after showing that I know my job and giving matter-of-fact statements of how much time is needed.
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.
Either that or it's an intentional and cynical attempt to con gullible staff into working longer than expected under the guise of a "crunch", most significantly in the gaming industry.
'Course, it's probably not coincidental that the gaming industry is the one with the highest proportion of relatively young, newly-graduated, gullible (smart but with little life or industry experience) and easily manipulated programmers.
By the time they figure out that the "crunch" is a pathological and embedded aspect of that industry, there's a fresh supply of naive graduates willing to take their place for mediocre wages just to follow their dream of working in the games industry.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
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/
When I noticed that IBM's parking lot was nearly empty by 6pm, I sold all my IBM stock.
That was like 30 years ago, right? At least, I can't remember ever seeing IBM's parking lot full at 6pm.
"First they came for the slanderers and i said nothing."
do {
eat();
sleep();
} while (codeIsFun());
retire();
Trigger warning: this comment contains a quotation drawn from an armed forces recruitment slogan of another era, and therefore may offend just about everybody.
How much time can be spent coding is determined entirely by how much true creativity is involved. Three hours is pretty much the limit for truly creative work (PhD experience). But if it's just work, well, I put in pretty productive 30-hour shifts as a medical resident (medical experience). See a terrific book called Daily Rituals by Mason Currey: almost all of those extraordinary creators were good for three-hour shifts, at most twice a day with a long break in between.
But let's face it, the message is not making a statement about coding in general. It's about the culture Google wants to create among their organization. Like the Marines, Google is "looking for a few good men." At least there's no doubt about what you would be signing up for.
The person doing 16 hour days is not turning out the same thing as two people doing 8 hour days. Even if they somehow sustain their level of effort, the quality of the code is going to be much worse.
That has not been my experience. I produce my best code late at night, when I can work without interruptions. The worst code comes from the 9-to-5ers that slap something together between meetings, skip the unit tests, and check-in uncompilable garbage before rushing out the door for Junior's soccer game, leaving me to work late cleaning up their mess.
In my experience, code quality is inversely related to to time spent coding. Some people think better at certain times of the day, like 2am, but most people who spend more than a few hours coding seem to have some of the worst code, and I don't mean non-clean code.
> I have rarely seen a programmer give an accurate estimate. Inexperienced programmers usually wildly underestimate how long a task will take.
I learned a while back that while programmers, including myself, generally give very bad estimates, each is pretty consistent in how far off they are. In other words, if I estimated 1/3rd the actual time on the last two projects, I'll probably do the same on the next two. If you over-estimated bu 50%, you'll probably over-estimate future projects by 50%.
Therefore, IF you write down each estimate beforehand, then write down the actual time, you can discover that Ray's estimates can be corrected by multiplying by three. People who have tested this report good results. I haven't done it consistently myself.
I suspect that some projects which include a significant element of inventing and developing new methods can't be estimated accurately at all. For "routine" projects like building a typical e-commerce site or GUI for a database, I suspect my estimates are wrong in a consistent, predictable way.
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
Meat Grinder companies like that generally don't last very long. No matter how amazing your are at programming...if you don't start pushing your job to subordinates as you expand, you can't expand.
People in cars cause accidents....accidents in cars cause people
Programmers don't usually stay long hours because they're told to - they stay long hours because they are into what they're doing.
That's assuming they are working on a project that has been scheduled well. Usually a lot of people I've known (including myself) had to work long hours because a project which has been allocated 12 months had 11 months doing nothing due to management indecision and then 1 month to cram in doing actual work. This has happened to me more often than any other scenario.
Assuming someone didn't just accept Googles slogan as a statement of passion... Why does someone think "coding" is just typing? Xtreme Programming isn't just about writing code. It is about the process of creating software. Yeah, I want you coding when you are working. You can go somewhere else if you are your view of coding is "typing" or if you want to spend 6 hours a day exercising like the person above.
My wife had written "Eat. Sleep. Run. Repeat." On our whiteboard while we were training for our last marathon. Obviously it was not to be taken literally and was only for motivation.
Ok, everyone knows "Eat, Sleep, Code" is a joke. What I find shocking is that somebody thinks it's real. There's probably nobody who does eat sleep code outside of a few bursts lasting at most a few months to a year when working at a startup. I mean, you have to go buy the red bull at some point, right? Anyway, I think it's a good tag line though.
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.
But only for one or two years or so. And only when you're young. And only voluntarily. How do you think concert pianists get to where they are? They 'eat, sleep, play the piano, repeat'. It's how *everyone* gets to a good level of proficiency at *anything*.
Religion is what happens when nature strikes and groupthink goes wrong.
> explain the task so I can understand the business motivation and the real deadlines
Mod up.
> that would mean I already did something vaguely similar and if that would be the case, then I would be perusing [reusing?] that other piece of code so there's no a third time. ... The first case is a boring one that, fortunately doesn't happen too frequently.
It's interesting, I've almost always done some vaguely similar. Example 1: the organization has data in system X and they want it to be in system Y. Each can use (different) text-based formats to export and import data. Example 2: we want to a GUI to manage some information that's in a database. Example 3: we want to watch for cases outside the norm and trigger some action.
For most projects, I have some experience I can draw on. Yes, I'm a senior.
After 8 hours in a day, most programmers start creating negative value. My max limit is around 4-6 hours, depending on what I'm working on. Even then, I can't sustain those levels for more than a few weeks, and it will then take me a few months to recover.
Hell, I was one of those obsessives in the workplace, and I've universally caught crap about it in here. I don't think one person ever agreed with me about my work habits.
So now, we are supposed to attract young people, especially young ladies into coding with the attitude that it is the only thing you do in life beside eating and sleeping?
That's maybe 1 in a thousand people that have that outlook, and by and large, they are considered freaks.
In a pop culture world, that dog won't hunt.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Yeah for someone who's all about getting out their seems to be some confusion that this is a play on a common meme "Eat, Sleep, Rave, Repeat". Which was never meant to be taken literally either, it's a song. Not an instructional manual.
Many moons ago a Soviet military attaché saw that there were lights on late at the Ministry Of Defence, and reported to Moscow that the British were planning a first strike.
It was the cleaners.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
And that is precisely why I am good at it. I would never write long-winded BS that was mostly copy-pasted, loaded with huge if-else chains that can't be unit tested.
At my current job I delete more code than I produce. I refactor the BS written by junior coders in the past ten years and it is not uncommon to replace 100 lines of code with 2 or 3. Deleting BS code is so satisfying 3
"Work smarter, not harder!"
You completely took it out of context. Mythical Man Month just says the cost of communication increases exponentially as the size of the time increases. Other studies have shown that value created by working more than 8 hours quickly turns negative. 16 hours of work is not 16 hours of work, it's also not 15 hours of work, it's negative N hours of work. You'd get more done by not doing anything at all.