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.
.
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.
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.
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.
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.
> 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.