Ask HN: How many hours per day do you work?
It turns out that:
- I barely can code for more than 4 hours per day
- I have max. 60% of "productive" time, which means that 60% of time apps like IDE are open. The rest goes to random stuff, like messaging/youtube etc.
So I'm curious. I know that there are tons of articles saying that you can't be productive all the day.
But what's in real life?
Are there any persons who can work, say, 8+ hours? I mean, really work, not be at office.
[+] [-] crispyambulance|5 years ago|reply
Being at the office, doing office things IS WORK.
Where does the idea come that you're only "working" when you're coding?
If you're filling out a TPS report, you're WORKING. If you're sitting in mind-numbing status update meeting with a 1000 yard stare on your face, you're WORKING. If you're researching something on the internet to solve a problem for you or someone else, you're WORKING. If you're watching an HR-mandated online learning presentation about IT security consisting of Kevin Mitnick clips droning endlessly, you're WORKING. If you're thinking about work, you're WORKING.
[+] [-] kd5bjo|5 years ago|reply
When performance review time rolls around, it can be very hard to get credit for all of those other things. Coding, on the other hand, has products with direct business value that you can point to and say, "That's what I did this quarter."
[+] [-] collyw|5 years ago|reply
[+] [-] VoodooJuJu|5 years ago|reply
>sitting in mind-numbing status update meeting
Technically yeah, we are "WORKING" when we do these things, but we distinguish the types of above-quoted trivialities from "real work" because it's useful to distinguish them. Why is it useful? For one, as a kind of relaxant or a release; a release from working myself too hard, and from not feeling like something's wrong with me when I'm unable wrap my head around some code after writing for the last 12 hours straight. We'll hear from time to time about someone "WORKING" 80-hour weeks and that will lead us to think that maybe we could be "WORKING" longer, harder. Except "WORKING" to that 80-hour-a-week guy is a lot of business lunches & dinners, social media, golf, or other busywork, while "WORKING" to another guy is high-intensity focus and creative output. By qualifying their hours worked with what constitutes "WORKING", we find comfort knowing that no - something is not wrong with us if we can't engage in a 14th hour of intense-focus creative output.
[+] [-] lordnacho|5 years ago|reply
If you interrupt one of those blocks, you can't do "difficult coding work", but you can communicate with people, document your code, and organize. The easy work can take up a lot longer, it's just not part of the block, and interrupting the block means you don't have that block.
Organizing means simple stuff like moving pieces around to where it makes sense to have them, simplifying well understood issues, and automating parts of the build.
By difficult work, I mainly mean exploratory coding work, where you write new code, see if it compiles, and whether it does what you expected. Or you are debugging something that's broken and following various hypotheses about what might be wrong.
Once you've either written the new piece or discovered the bug, you can spend time doing "organizing", where you know the answer, but you just need to spend the time moving stuff around.
I'd be lucky to have a block each day.
[+] [-] byecomputer|5 years ago|reply
[+] [-] georgex7|5 years ago|reply
[+] [-] flerchin|5 years ago|reply
Bob Porter : Da-uh? Space out?
Peter Gibbons : Yeah, I just stare at my desk; but it looks like I'm working. I do that for probably another hour after lunch, too. I'd say in a given week I probably only do about fifteen minutes of real, actual, work.
[+] [-] hpoe|5 years ago|reply
[+] [-] mckirk|5 years ago|reply
[+] [-] tubularhells|5 years ago|reply
[+] [-] peterkelly|5 years ago|reply
There's been times where I've spent weeks or even months going down a path that has ultimately proven fruitless, including spending really long hours on it. That certainly counts as work, but if it results in no meaningful value being produced, then what's the point?
There's been other times when I've gone on holiday and come back refreshed and incredibly motivated, having realised the solution to a problem that I'd been struggling with because I gave my subconscious mind time to do its thing without interruption. Does spending time at the beach, exploring ancient towns in Italy, or even just taking a shower count as work? Most people would say no, but that's when I've had some of my best ideas.
Sometimes in a meeting I'll be having a discussion with a colleague and we'll come up with a solution for something we've been trying do that requires zero changes to the our codebase, something we refer to as a "no-code" solution. Those can shave off weeks of time. Technically, that meeting counted as two hours of work; is that less productive than spending a ton of time implementing a feature that turned out to be unnecessary because there was a way to avoid the need for it?
As far as when I actually sitting at my desk focusing on work, I value reading and thinking much more than implementation. Coding is the easy part; once the solution is clear, getting it into the computer is fairly straightforward, albeit quite tedious. I've spent lots of time coding the wrong thing, which with a bit more thought and research could have been avoided. I consider that time mostly wasted, except perhaps for the learning experience.
Judge your productivity by what you achieve, not how long it takes you to do it.
Edit: A thought experiment I'd like to add. Imagine you give two people the same task and ask them to complete it in one week. One person works on it four hours a day, the other six. They both get it done on time, at the same level of quality. The first person was actually _more_ productive than the second.
[+] [-] kd5bjo|5 years ago|reply
I'd argue that they were equally productive. To be more productive, they'd have to produce more work product during the week.
Especially if it's a primarily mental task, there's a good chance that the 4-hour / day person is actually making progress when they're not visibly working, which would interfere with any attempts to either move the deadline earlier or get other work done in parallel.
[+] [-] therm0|5 years ago|reply
how do you do this and not get fired? i got a lecture earlier this year about how spending two weeks on a difficult problem in a project that i'd just gotten dropped into was not befitting of a senior software developer.
[+] [-] CodeGlitch|5 years ago|reply
[+] [-] TuringNYC|5 years ago|reply
I've worked intense 10-12hour workdays in the past for long periods of time (waves of 3mo), but they all had at least three of four things in common: Agency, Interesting, Interruption, Reward.
Agency is important to me -- am I bought into what I'm doing and understand the importance+urgency and get to direct the work -- or is someone up the chain jamming some feature down to check a box for their own personal reasons w/o good reason. This encompasses Respect -- where everyone understands the rationale and why some urgent deadline is present and people are not told to go on unknown journeys "just because" or "you dont understand"
Another is Reward. When working at a hedge fund, sometimes, things were not interesting but there was a clear reward I was psychologically aligned with the reward. Same when I was Founder/CTO -- there was a clear reward (not always monetary.)
I think when you hear 2hrs/3hrs/etc per day, often it is the fault of the organization for:
- Not having good business cases
- Thinking Engineers don't care about reasons for doing things
- Not providing distraction free blocks
- Not sufficiently sharing rewards with the company
[+] [-] busterarm|5 years ago|reply
This sticks out to me. I think there's a growing dichotomy in industry among engineering managers.
There are those that don't want their engineers to care about the business reasons and just be cogs, maximizing their productivity. These tend to be prevalent in the FAANGs, in my experience.
Then there are those who prioritize like you do, maximizing engineer impact. I know that I can only function in this type of organization.
I think both sides are convinced that they are right...and maybe they are...but I sure wish it were easier to identify engineering organizations by their type ahead of hire.
[+] [-] ksk|5 years ago|reply
> - Not having good business cases
> - Thinking Engineers don't care about reasons for doing things
> - Not providing distraction free blocks
> - Not sufficiently sharing rewards with the company
In your list, it seems its the company's that's often at fault. Can you explain that a bit more?
As a manager, I expect my direct reports to do the work I assign them. As a good-faith effort I will do my best to assign work that is relevant/interesting/etc. But I accept that in the real world, there is a lot of work that is often boring, repetitive (some of that is going away thanks to automation). Especially in the scientific domain, performing the same experiment over and over isolating for some factor or the other, and there is sometimes very little intellectual stimulation. I think it would be the same in engineering fields as well.
[+] [-] afpx|5 years ago|reply
[+] [-] lwigo|5 years ago|reply
Hobby projects I can work on for 10-12 hours straight and still feel like I could go longer, but after a three day sprint of this, I have to take at least a day off to regroup my thoughts and make sure I'm not too far away from the original intention / goal, or over-engineering.
[+] [-] frereubu|5 years ago|reply
One of my most productive weeks ever was when I accompanied my wife on a work trip from London, UK, to Savannah, Georgia, which is 5 hours behind. Even though I was looking after my young daughter I go a huge amount done because my work day was:
First thing: Answer emails from the UK morning.
Morning: General admin.
Lunchtime: Answer emails from the UK afternoon.
Afternoon: A beautiful stretch of uninterrupted coding time while my daughter amused herself bum-shuffling around the room.
Even though I'm pretty good about closing my email client while working, just the knowledge that emails weren't piling up while I was coding gave me real peace of mind.
I think a huge amount of the stress of coding work is knowing in the back of your mind that there's a huge amount of crap piling up in the background that you're going to have to deal with afterwards. It reminds me of that Walter Benjamin piece about Paul Klee's painting Angelus Novus:
"This is how one pictures the angel of history. His face is turned toward the past. Where we perceive a chain of events, he sees one single catastrophe which keeps piling wreckage upon wreckage and hurls it in front of his feet. The angel would like to stay, awaken the dead, and make whole what has been smashed. But a storm is blowing from Paradise; it has got caught in his wings with such violence that the angel can no longer close them. The storm irresistibly propels him into the future to which his back is turned, while the pile of debris before him grows skyward. This storm is what we call progress."
[+] [-] uselessemployee|5 years ago|reply
I honestly believe my position and my team entirely could be fired and nothing would change for company's bottom line, perhaps it would even improve. It does hurt a bit because a number of employees were laid off recently, while they were actually useful.
I am "working" as a developer in one of bigger tech companies here in EU.
[+] [-] ingvul|5 years ago|reply
Before (at the office): arrive at 9am, leave at 17pm. Work (productively) for around 4h. 1h or so for lunch and multiple breaks. 1h or so of socializing. 2h or so wasted doing... what? I don't even remember.
Now (WFH): start at 11am, finish at around 16pm. 30min/1h break. I work the same amount of time as before Corona (in terms of productive hours), but I don't waste time anymore.
Deliverables are still the same, we still manage (as before) to push our products further.
[+] [-] rgblambda|5 years ago|reply
How are dev tickets tracked if at all? Are there daily stand ups where you and your team just bullshit for 15 seconds each? Do your superiors not expect deliverables?
[+] [-] dx87|5 years ago|reply
[+] [-] simonw|5 years ago|reply
"For creative work, you can't cheat. My believe is that there are 5 creative hours in everyone's day. All I ask of people at Shopify is that 4 of those are channeled into the company."
https://twitter.com/tobi/status/1210242188870930433
[+] [-] HeyLaughingBoy|5 years ago|reply
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid...
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid...
As a participant in that methodology, the SEI gives you access to data gathered over thousands of software development teams. One of the findings is that the average time per day spent across all development processes (from getting requirements to testing) was about 2-4 hours.
That number is surprising only to people who don't accurately and religiously track their time. Guesses are useless. We found that it took about a year for everyone to really get good at time tracking and to reinforce others ("hey, George. I was looking for you before and I noticed you weren't at your desk, but you timer was still running") to get better. After doing that, we found that our time fell into that range. The Test team was at the higher end with 6-8 hours when executing test cases for days on end and newcomers were around 4-6 which we attributed to them having fewer distractions. Experienced/senior engineers were usually around 2-4 hours/day.
So, all in all, I'm not at all surprised by your results.
[+] [-] PragmaticPulp|5 years ago|reply
I’ve been time tracking for years. It’s normal to see about 4-5 hours of productive work in an 8 hour workday. It’s difficult to log more than 5 hours of screen-on time due to meetings, conversations, phone calls, bathroom breaks, lunch, and so on.
> I have max. 60% of "productive" time, which means that 60% of time apps like IDE are open. The rest goes to random stuff, like messaging/youtube etc.
I’ve learned that it’s more important to track time spent in time wasters like YouTube or HN than it is to track productive time. The time wasters can really add up if you’re not careful. Taking breaks and relaxing is fine, but losing multiple hours in the middle of every workday to YouTube is a problem. It’s easy to lose an entire workday each week to wasted time online if you’re not careful. Only 96 minutes per day adds up to an entire lost day each week.
In a non-office environment (freelance consulting) I frequently put in 5-10 productive hours per day. It doesn’t come easy at first, but with training anyone can ramp up to similar levels. The key is to realize that it’s an acquired and trained skill, not some innate limitation of our genetics or neurochemistry. Claims that people can only focus for N hours per day should be viewed like claims that people can’t run faster than 8 minute miles. You can change your focus habits if you’re motivated to do so and willing to put in the work.
[+] [-] qz2|5 years ago|reply
The rest is eaten up with unproductive zoom meetings (I'm on one now as I post this), dealing with development tooling falling over and waiting for things.
Terrible efficiency.
[+] [-] ckdarby|5 years ago|reply
Protect your time, block out your calendar, and fix the root causes that create the unproductive meetings.
[+] [-] nickjj|5 years ago|reply
If it's something I really enjoy doing then going 8+ hours isn't a problem and I'll even feel energized afterwards and catch myself saying stuff like "I know but you need to stop, let's resume tomorrow".
When I'm able to financially afford to spend blocks of time such as working on creating programming related video courses, I've done that type of schedule for 3 months straight multiple times in a row. Basically work like that for 3 months, ship a new course, take a 2 week break and repeat. The only reason I even took those breaks was to reflect on what I learned and figure out how to do things better for the next one.
But when I'm not able to afford doing that and I need to mix in contract work, especially contract work that I feel doesn't help me in the long run because it's doing things I wouldn't necessarily do in my own projects, that shit drains me like nothing else. Just working on stuff like that for 2 hours destroys me for the rest of the day.
That and personally I find that I'm not optimized for juggling many different things at a time. I work best when I can block out large amounts of time and just plow through 1 task instead of chopping up smaller amounts of time to do things in parallel. I think it's because if I don't finish something all I do is compulsively think about it until it's solved, so trying to do that with many concurrent projects leaves me in a constant state of feeling like nothing is ever going to be done which drains me overall.
[+] [-] texasbigdata|5 years ago|reply
Basically if @20/30 hours per week it’s 70% ish productive at 60+ it’s max 50% which tells you a ton about the marginal productivity of those incremental hours.
There’s also time of week variation, time of day variation, the aforementioned burnout recovery spillover occasionally and a bit of sequencing at play.
[+] [-] leoedin|5 years ago|reply
I've always found myself alert and energised in the evening, and sluggish and unalert for the first few hours after waking. I'd be very surprised if my productivity drops exponentially in the evening. My partner on the other hand is most alert in the morning and loathes doing anything complicated after dinner.
[+] [-] Fawlty|5 years ago|reply
[+] [-] Juliate|5 years ago|reply
Being around, being available to inquiries, questions, support, anything, is work.
Even taking a coffee break and a nap in between two active coding sessions is work - if only because those two sessions are related in purpose, and because your mind still processes your work during the "break".
Even unproductive, lousy days when nothing gets accomplished are work; if only because it sometimes is only your mind reflecting on an issue that you will, it seems, "code in a matter of 2 hours", while in reality, it tooks the two previous days to get/discuss/put things in perspective to allow for these 2 hours to cristallize the solution.
Your productivity is in your context and output. Not in the exact quantity you put in.
The taylorist factory view just does not function at all with design/creative work.
[+] [-] puranjay|5 years ago|reply
I usually manage 5-6 hours of productive time each day. 7 hours on a good day. 8 hours if the problem is interesting enough.
I used to feel inadequate when I would hear stories of founders and geniuses working 16 hours/day. But now I'm convinced that outside of prodigies, specific mindless tasks, and "outside help" (like amphetamines), it's impossible to get more than 8-10 hours of real work done in a day over an extended period.
[+] [-] shuntress|5 years ago|reply
I have occasionally in my career so far had an alignment of just the right problem, just the right guidance, just the right solution, and just the right deadline to facilitate 8-uninterrupted-hour-skip-lunch-"in-the-zone" programming days.
I would assume those stories about founder geniuses are partially-exaggerated versions of that played out over a larger scale and with a more deliberate focus on facilitating that type of perfect alignment of problem & solution.
[+] [-] reedf1|5 years ago|reply
[+] [-] qntty|5 years ago|reply
[+] [-] crypt1d|5 years ago|reply
The value you bring to the table is not _just_ in the lines of code you write, or in the hours you spend in front of an IDE. The time spent chatting with colleagues about products, writing that documentation you've been putting off for months (because it not 'real work'), or even reading HN to stay in touch with the latest and greatest in tech, all amount to the value one brings to the company.