Hacker Newsnew | comments | show | ask | jobs | submitlogin

It should be noted that what is needed for assembly line productivity is different than what is needed for complex cognitive tasks. The more demanding the cognitive task, the more important sleep and relaxation are. That is why in Steve McConnell's classic Rapid Development he advocates a 35 hour week.

And the real limit for a lot of people may be less. For instance read http://www.kalzumeus.com/2012/05/18/kalzumeus-podcast-ep-2-w... to find out that patio11 thinks that he can only be productive 2-4 hours per day. This is a man who started a business on the side while working the insane hours of a Japanese salaryman. It isn't that he can't put in the hours, it is what he can do and be productive.

Greatly complicating all of this is are two simple facts. The first is that we can push ourselves and be productive for a short period, so over a couple of weeks we really can work insane hours and be productive. The second is that we have coping mechanisms to hide our own inability from us - so as our ability to function disappears down the drain, it is very hard for us to judge how impaired we are.

To that end, there was an interesting piece of research that I read about many years ago. The military was conducting research on sleep deprivation. One of their findings was that soldiers can be trained to operate on 6 hours of sleep, and will self-report that that they are functioning well and getting more done than they could if they slept longer. However the wives of those soldiers disagreed. And when ability to perform was judged on standard ability tests, the wives were right.

If you, personally, work long hours and consistently get little sleep, there is some food for thought. Could you be getting more done if you took care of yourself and put in more reasonable hours?




> It should be noted that what is needed for assembly line productivity is different than what is needed for complex cognitive tasks. The more demanding the cognitive task, the more important sleep and relaxation are. That is why in Steve McConnell's classic Rapid Development he advocates a 35 hour week.

In my personal experience this is 100% right. But the reason could be the level of pressure and the anxiety involved.

On manual jobs I can work more than 8 hours a day with a good productivity and without feeling tired. In software development I can't. Probably this depends on the pressure. If you are in a manual jobs with higher productivity pressure (like assemble <n> units a day where the average is less than that) will have a similar effect.

Also I find a difference between people who have an expertise in a more specific software development field (SQL databases) than on people who jump to different problems/languages/technologies in different computer fields all the time. You can maintain your productivity if you narrowed your areas of expertise.

-----


The article mentions a very similar result:

"In a study on the effects of sleep deprivation, investigators at the University of Pennsylvania found that subjects who slept four to six hours a night for fourteen consecutive nights showed significant deficits in cognitive performance equivalent to going without sleep for up to three days in a row. Yet these subjects reported feeling only slightly sleepy and were unaware of how impaired they were."

-----


>>It should be noted that what is needed for assembly line productivity is different than what is needed for complex cognitive tasks.

Not actually. Assembly line work might be less intellectually appealing to us, but for a lot of people it is a complex cognitive task. If you were to talk to a every day assembly worker of an iPhone, he would find assembling complex circuitry pretty intellectually challenging.

Things become less intellectually challenging as your brain gets seasoned to it. Even coding for that matter these days has become pretty less intellectually challenging. Growth of modern day IDE's have rendered many programmers into kind of code assembly workers, autocomplete/intellisense does most of thinking these days.

>> The more demanding the cognitive task, the more important sleep and relaxation are.

My dad is a cab driver and he used to drive trucks before. I can tell you this is not true. You can easily argue driving is a repetitive task once learned. But you have no clue how tiring it becomes. In general a hobby is enjoyable, but any thing taken up full time as a profession is tiring.

In the book Flow by Mihály Csíkszentmihályi, he explains how once you get into Flow enough number of times, any job becomes boring and you have to keep moving higher up the ladder of difficult tasks to experience Flow again.

So its not that we programmers do jobs which are the center of the universe. What is true for others is generally true for us too.

-----


Are you saying that the assembly line work that Ford studied was a complex cognitive task? Not according to the people who did it - in fact a major reason cited for quitting was that the work was so boring!

Luckily that type of work has been pretty much replaced by robots today.

Assembly line work is exhausting - very exhausting. However you can continue to do it while your brain is shot. This contrasts with programming where you simply usefully can't work on many problems unless you're in good enough shape to keep the necessary state in your head.

And an incidental note about your dad. Driving involves a lot of complex visual recognition and situational awareness of a constantly changing environment. We do not think of this as a complex cognitive task because we're wired to do it without even being aware of doing so. But when you look on a brain scan, huge parts of your brain light up and are working. This is real mental effort being made, and it is no surprise that you get tired after constantly doing it for long enough.

-----


All I am saying is- the definition of a 'complex cognitive task' is highly subjective. And it depends on many other things.

To give you an example. Try writing code in Java these days. With Eclipse very soon(And trust me you will feel this in days) you will realize that you are hardly doing anything that is intellectually heavy lifting. Unless of course you are doing something that is totally new to your area of work. In that case its totally different. Which is the same case with assembly workers too(A totally new product unknown to you will be difficult to assemble).

But imagine doing applications which have nothing more than a DB interaction layer and some business logic. You can do this sort of a job for first 6 months of your programming career, and then you can have your muscle memory built to work with nearly auto completion method out there. Soon you will see that you will be doing nothing other than assembling already well known blocks of code without putting any sort of hard intellectual effort.

Rinse-Repeat this with a few domains/programming languages/architectures. Very soon you will find that you are doing nothing more assembling reusable blocks of logical pieces.

The only difference between hard labor and something like programming is the physical tiredness. This I completely agree with you that physical labor is more demanding to your body.

But other wise there is no reason for us to believe that the nature of our work is any different than anybody else.

-----


I'd be curious to know where you've worked to form such an opinion. Sure programming CRUD apps gets repetitive and boring, but if you are literally needing to spend no mental energy on what you are doing, then you should move up the abstraction layer and write a script to do your job. If you're not using your full intelligence and capability as a programmer then you are doing it wrong (braindead body shop policies notwithstanding). This is not unique to programming by any means, but it's definitely not the same as assembly line work or taxi driving or line cook or any other rote job.

-----


As one of those who actually stood at an assembly line, I can tell you that assembling an incredibly small part of product n+1 is not, in any way, comparable to implementing CRUD application n+1.

-----


> Growth of modern day IDE's have rendered many programmers into kind of code assembly workers, autocomplete/intellisense does most of thinking these days.

Please tell me that there is irony involved in this quote. Otherwise the term "thinking" has been diluted to the point of existential crisis. What IDEs do is remembering and accounting. That's cognitive activity, but it's not something that involves sentience or thoughtfulness.

What separates the best programmers from the herd is thinking, and it's not embodied in an IDE.

-----


>>What IDEs do is remembering and accounting.

Nearly all creative work is delta improvements on remembering and accounting previous sources of knowledge.

>>What separates the best programmers from the herd is thinking, and it's not embodied in an IDE.

What makes you think there are hundreds and thousands of best programmers?

-----


> Nearly all creative work is delta improvements on remembering and accounting previous sources of knowledge.

[Citation Needed]

> What makes you think there are hundreds and thousands of best programmers?

There must be hundreds of thousands very good to pretty good programmers out there. To some extent what they do involves real thinking, though not necessarily all of it. Only the dimmest programmers are replaceable by a monkey with an IDE.

IDEs are to programmers as circular saws are to carpenters. The tools an automate a lot of work, but what distinguishes good from bad and the very best from the merely good is genuine skill and knowledge. Idiots will be quite capable of hurting themselves and incurring great expense to their employers.

-----


> Things become less intellectually challenging as your brain gets seasoned to it.

That's obviously true.

>Even coding for that matter these days has become pretty less intellectually challenging. Growth of modern day IDE's have rendered many programmers into kind of code assembly workers, autocomplete/intellisense does most of thinking these days.

I don't think this is true. Of course IDEs made certain things easier like looking up class/method/function names and their documentation but imho that's not the hardest part about programming.

Besides that I agree with you. You can't make a general statement about what is tiring for someone. I think working as a craftsman is as tiring as working as a programmer - it's just different. A craftsman's body will be tired and a programmer's brain will be tired.

-----


>>Of course IDEs made certain things easier like looking up class/method/function names and their documentation but imho that's not the hardest part about programming.

I would say this is true for programming tasks that are new to your already mastered problem domain.

But please think about this. How many times do we ever face situations where we sit down to do things that are totally new to us?

Vast majority of the programming world really writes repeated patterns of software meant solve repeated patterns of problems. And that perfectly explains why Frameworks, libraries, IDE's are such a religion these days.

Most of 'What needs to be written' and 'How it needs to be written' is already figured out. Of course this is not true for tasks that are new and require you to think a lot.

-----


"How many times do we ever face situations where we sit down to do things that are totally new to us?"

The vast majority of my day, and the vast majority of my career. If you're not, it's most likely because you're not challenging yourself, and you've got nobody to blame for that but yourself.

When I first got out into the working world, I read all the posts that said "Really, the vast majority of programming is just plugging together pre-wired components and pulling stuff out of a database to stick on the screen, and all the interesting problems have been solved already." I thought that sounded terribly depressing, but I liked programming and it paid well, so I figured I'd deal with it later. And sure enough, after spending 3 years in college working on a PHP webapp and about a year at my first job wrestling with JSF/Hibernate, I was pretty bored.

So I quit. I founded a startup to let teenagers create their own casual games, basically trying to put Macromedia Flash on the web. On the way, I learned HTML, CSS, Python, JavaScript, and ActionScript; used MySQL, Postgres, MogileFS, Munin, Monit, Pylons, Django, and JQuery; wrestled with how to persistently store a "game" in editable form (eventually settled on an AST-based representation serialized to JSON and dumped into MogileFS, with metadata stored in the DB); wrote a compiler from that AST to JavaScript and ActionScript backends; learned some image processing so people could manipulate assets for their games; and implemented all these physics & collision-detection algorithms in the runtime library. The startup ended up failing, but I guess it was impressive enough to get me hired by Google.

When I entered Google, I thought I was a hot-shit frontend engineer because I'd been working intensively with JavaScript and Flash for a year and a half. It took me about 3 weeks to discover I knew basically nothing. Because Google Search really cares about latency, which means that all JavaScript libraries were banned, and we had to count bytes in our source code to make sure our new feature wasn't slowing things down too much for users. You design programs differently when every line of code you write is a cost not just to you but to your users; you actually think about what you write instead of tossing in a 100K library because you need a couple functions. Plus, when you don't have JQuery to hide all the browser details from you, you really need to know how each different browser performs and have a large catalog in your head of what works and what doesn't work.

I've moved off my home base in Search twice, once for a short stint working with Google+, and another for a recent project that'll remain unnamed. Both have their own array of challenges. Unlike Search, G+ is not latency-constrained; they expect you to stay on the site for significant periods of time. The whole site is a massive AJAX app, though, so you have the challenge of how to manage a million+ line JavaScript codebase. The new project is developer-constrained; it has a small headcount, and so once again I find myself working with the open-source Python/Django/AppEngine/JQuery/LESS stack, but each of those tools has evolved in the 5 years since I last used them, and we now have all these HTML5 goodies to play with.

That's not even counting backend stuff. After a year and a half as a FE SWE in Search, I was starting to get pretty bored, so I asked to do backend stuff. I ended up working on an LLVM-based JIT for a templating language; the spec for Google's Authorship markup; the implementation of said markup throughout the indexing & serving system; a bunch of unstructured data-extraction tasks; and most recently some machine-learning with libsvm. All of these were new, and all were challenging.

And that's not even including soft skills like code reviews, mentoring, interviewing, managing up, product & UX design, and project planning. Having 3000 lines of code dumped on you on Wednesday when they want to get it in by Friday, needing to quickly figure out how it all works, and knowing that if you screw up you'll break google.com is something entirely different from hitting autocomplete in your IDE.

I'm beginning to think that if you know exactly what to do, you probably have no clue what you're doing. Real engineering is all about trade-offs: it's knowing that if you implement this new feature, it'll cost you a millisecond in latency and 2 months of engineer time, it'll have some unspecified effect on future productivity, and it may result in X number of happy users. And then you have to weigh those unknowns and decide "Given what I know, is this how we should do it?" If you know the answer to that immediately, your product is probably lame, because it means you didn't even consider alternatives.

-----


You are no doubt a great programmer. But that at most proves you are a great programmer not the entirety of the software world.

-----


I've heard that argument before. I don't think I did anything that other people cannot do.

My overall point is that if you start believing that programming is just rote work that takes no skill, it becomes a self-fulfilling prophecy. Because then you never take on the challenges that will get you skills, and you're unqualified for jobs that will bring you more challenges, and eventually you end up falling so far behind that it seems hopeless. It really has very little to do with ability and a lot to do with constantly looking for ways that you can make the user experience a bit better at the expense of making things a little harder for yourself.

-----


> Assembly line work might be less intellectually appealing to us, but for a lot of people it is a complex cognitive task. If you were to talk to a every day assembly worker of an iPhone, he would find assembling complex circuitry pretty intellectually challenging.

I doubt that. The way you make an assembly line efficient is by breaking down complex tasks into super-simple subtasks. Each person does one tiny thing, and does it over and over until the actions are automatic - you could practically do it in your sleep. If any task requires "intellectual challenge", you're doing something wrong; that is a bug in your assembly process that you should fix if you want a highly reliable, replicable result.

-----


I'll add to your comment just my observation of the necessity for good health. Some injuries without ready solutions disrupted my focus to the point where I simply couldn't perform at my prior level, no matter how much raw effort, willpower, caffeine, etc. I attempted.

Guard your health!

-----




Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: