Ask HN: How many hours per day do you work? | Hacker News Reader

Ask HN: How many hours per day do you work?

236 pointsAkcium176 comments

I'm trying to log my time via timer app (manually switching it on when I code). Plus I use an app which checks what apps I use every minute.

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.

View on HN

> Are there any persons who can work, say, 8+ hours? I mean, really work, not be at office.

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.

> Where does the idea come that you're only "working" when you're coding?

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

You have to look into where that overhead falls:

1) Things that everyone has to do like HR/Legal compliance.

2) Things that you should have opted to avoid like useless status meetings.

3) Things that are productive but have in-direct business value. That's largely a bug in the review process if it doesn't value those.

One huge waste of time is red tape. Corporations love adopting procedures that are directly antithetical to getting work done in a timely manner, like “IT support” tickets that consist of getting access to an internal database, even if that database contains no sensitive information. These do not affect teams in an even way, since some projects’ critical paths will depend on these labyrinthine workflows more than others.

So let's go with typical reply: if you work in such place that does not understand that and don't want to pay for it, you should pimp up your resume and find better place.

>filling out a TPS report

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

Those things like meetings, lunches, dinners, golf and social "trivialities" are really work. They do take a toll on you and they're not relaxing. Sure, it's different from intense problem solving, different from digging a ditch, but still very much work.

So if I look at facebook while sitting at my desk I am working? I don't think so.

Yet that's exactly what happens. No one is "on" or at 100% intensity all the time. Ditch diggers take breaks, so do people in cubicles. It's OK.

The way I think of it, there are two sessions a day of doing difficult coding work, before and after lunch. Maybe 3 hours each.

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.

That makes sense to me. Organizing and documenting feels a lot more creative for me than the wtf-am-I-doing orienteering-type stuff. My attitude can definitely come down to, "Okay, either me and the computer get square, or me and the people get square about what I did with the computer. But I'd like to sleep in-between those steps."

Yep, this is really well said. Do you track your deep work hours? I'd love to get your feedback on something I'm working on (trywinston.com). Email is on the website if you want to chat.

Peter Gibbons : Well, I generally come in at least fifteen minutes late, ah, I use the side door - that way Lumbergh can't see me, heh heh - and, uh, after that I just sorta space out for about an hour.

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.

I've worked in small start ups I've worked for massive beuarcracies and everytime I read about all these movements trying to get kids to code, and promising all these things to high schoolers about what their life will be like if they become a computer programmer I think of this movie. This should be required viewing in every CS101 class I maintain.

Words to live by.

(The quote is from Office Space, in case anyone else is as lost as I was.)

I don't think that the number of hours per day/week is particularly important. It's important to distinguish between efficiency and effectiveness.

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.

Some great advice here.

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

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.

I guess it depends on what the first person did with their extra 10 hours.

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

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.

This is super workplace dependent. Some places just want you to churn stuff out quickly and are unforgiving of research and time spent thinking things through. Other places value everyone taking their time, learning, and finding the right solution, even if it takes longer, rather than the solution that works right this second.

Communication is key. Once you've started working on something and it looks like it might not work out or take a lot longer than expected, discuss this with your manager and find out how they would like you to proceed.

My approach is to make my case for why I should keep working on a particular thing (especially if I feel strongly about it and/or confident I can make it work given enough time), but ultimately respecting their decision. I find this works well.

The cases where I've spent weeks/months on something are either where I was in charge of the project (during grad school, and later as an indie developer), or as an employee where my manager considered the task to be of sufficient importance to the business to continue down the path, even if it means spending more time or trying a few different approaches until I find one that works. This is especially the case with research-oriented projects where you don't know where a path is going to lead until you go down it.

There are a lot of comments about interruptions, and a couple about interesting work. I'll add two more dimensions: Agency and Rewards.

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

Which organizations would you recommend?

I have found these qualities to be more about the senior manager one reports to as opposed to company-level. Some senior managers have a great way of trying to set their teams up for success with as little BS as possible. You enjoy work more, and you win. The company gets productive employees focused on real outputs, the company wins.

When interviewing, I always try to have a 30min+ conversation with the group manager and understand their biggest projects and also their most urgent tasks and see what they can provide w/r/t rationale for these items.

> - Thinking Engineers don't care about reasons for doing things

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.

"but I sure wish it were easier to identify engineering organizations by their type ahead of hire."

You can make it easier before joining. During the interview process, ask one of the interviewers if they can share an example of how the organization makes decisions in a quantitative and/or qualitative way. If they don't mention a Mode/Amplitude/whatever report with user data and/or talk about some user interviews (and the concomitant report) then it's probably not a data-driven process. Or the data isn't shared beyond Leadership. And if they roll their eyes or say, "We just build what the CEO or Sales wants" then you have even more evidence that this might the kind of place where you'll just take direction and not get a clear reason.

>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

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.

Thats a good point, which is why I was noting 3/4 criteria were met in places where I witnessed great productivity. If it isnt interesting, people should be rewarded and at least understand why they are doing something. The hedge fund, for example, was not terribly interesting for many years. But I understood the importance of the work, the drivers for it, and I got rewarded and so did everyone else.

A company or manager might say -- well continued employment is the reward. Yes or no, depends on the situation. It is common for companies to hire people and then cut benefits (less healthcare benefits, 401k matches cut, etc.) -- well then the rewards are not being shared, especially if the cuts are not universally applied.

It is also common for companies to reward unequally. For example, many companies reward salespersons or executives yet continue to tighten rewards for Engineers/Ops/Support. As a result -- quite possibly not intentionally -- you have engineers like the ones on this comment section: noting they are finding 2 or 3hrs productive time. In an ideal world, rewards should be aligned to input and required effort -- and I've seen incredibly productive Engineers at hedge funds when they realize they have massive skin in the game with huge upsides.

Finally, with regards to respect and needs. I have never seen Engineers more unproductive than once they realize that all deadlines are false deadlines -- especially when these false deadlines are constant. I think people understand real urgency and real deadlines when they are explained, not "do it because I said so."

The problem is -- even if you pay engineers, "do it because I said so" doesnt work since there is such a creative element and so much uncertainty. You end up with 8 "productive hours" full of unnecessary bug fixes and shortsighted design because people are not bought into the vision. The worst situation is when management actually things that is real productivity -- then you know it is over.

I think I understand where you're coming from, but your responses are very specific. I don't think this is the common case. I believe, the common case is that most engineering jobs are dull and boring and are not breaking new ground. Tirelessly testing software, or polishing UI or to take my workplace (vaccine r&d) performing the same set of tests/experiments/assays/etc over and over again. I'd go far as to say that you have to be self-motivated to be successful in most jobs. There is a limit to which management can coddle you.

True actual coding? 2-3 hours on average, and usually at night when all others are offline (8pm-1am window). All the other BS like emailing, meetings, assisting with manual testing, responding to support related Slacks, fire fighting, setting up DB queries or visualizations, checking a result of some scheduled job (these last two being business asks / annoyances and don't happen daily but you get it), etc, results in 5-8 hours BS, 2-3 hours code.

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.

In general it's around 4 hours at most, although occassionally I can manage double that if I work in the morning, take the afternoon off, then work into the night from about 10pm - 2am.

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

Since WFH started I don't have to pretend to be working anymore. I get maybe 1 hour at most per day and even that is not always. The rest of time I read books, walk outside, play games, do my own stuff.

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.

I'm curious as to how this happens. I'm sure everyone's been in the situation where there's a blocker that goes on for a while or they've been assigned to a team/department but not told what to do. But this sounds different.

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?

There is Jira of course, and somehow tickets do get resolved eventually, perhaps my 3-4 hours per week is enough for that.

Daily stand ups are the funniest. I get to work on my bullshiting and improvisation skills. Sometimes I say stuff that I could have done but just could not be bothered enough. Interestingly, I found out that nobody really cares or follows up on that.

Occasionally other people reach out to me for help. Sometimes I do help them, sometimes I pretend to be too busy for that.

I think this happens because higher management are so full of themselves and genuinely believe in what they are supposedly doing that they cannot comprehend a simple idea of being useless and just not having much for others to do. There is a quote about exactly this situation, has been quite popular recently.

More or less in the same boat, but slightly different. Since WFH started I don't pretend to be working anymore when I'm actually not.

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.

If it's a hobby project I'm actually interested in, I can work all day every day. But if it's something I'm forced to do at work, 3-4 hours is the most I can do in a single stretch. If I can take a ~1 hour break after that and go to the gym or something, I can do another 3-4 hours. That's why WFH has been great for me; I can take a break as needed, and don't get bored to tears after a few hours in a cubicle farm.

I love this tweet by Shopify CEO Tobi Lutke:

"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

Four hours per day is normal. I used to work for an organization that used PSP/TSP

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.

Try using an app like RescueTime or QBserve to automate time tracking.

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.

Realistically about an hour a day of truly productive work.

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.

In this case you're choosing to be unproductive. If you're able to spend time on HN and reply during a meeting you could just as easily be fixing the root cause of development tools failing.

Protect your time, block out your calendar, and fix the root causes that create the unproductive meetings.

I'm doing that too. I am waiting for Vagrant to install Windows :)

> fix the root causes that create the unproductive meetings

BRB, fixing the org chart. /s

Unironically, this is what we did. Removed all 'layering', practically making groups of either product or tech and only 'manager' layer between that and C-level. Manager is only allowed to deal with people-stuff and PO's are only allowed to deal with product stuff. Everything else is up to the teams. Works pretty well for us! (and 'allowed' doesn't mean as a hard rule, it's just not their focus point, same goes for product vs. tech, it's not that you are walled off or something, it just means your core is very clear and how far away from that core you can get depends on your team and needs)

I'm not paid twice for working during meetings, so I don't work during meetings.

For me it really depends on what I'm working on.

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.

12 years of logging data and the answer is give or take what you said. Every hour past 7pm is exponentially worse productivity wise (aka 7 to 8 vs 9 to 10 vs 12 to 1 is night and day). There’s also a catch up factor above which subsequent periods are impaired.

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.

That's an impressive time series and some pretty interesting results. How do you log that? How do you measure productivity?

Rescue time, tag at the application level (obviously not fantastically accurate), and sub tag in chrome based on website.

It’s directionally correct at best, but still helpful.

Would also do a secondary form of manual evaluation by paying someone to text or call with a daily list of questions, but only have about 1.5 of years of data there. I ran the regressions and they are highly correlated in a time lagged way. In particular, sleep, for me, drove a lot of everything else. But from there it’s hard to say what the causality is (were you tired because of work to begin with? Or were you unproductive because of sleep?)

Would you say you're most alert in the morning or the evening?

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.

Probably varies by person. Also blood glucose and overall cortisol seems to matter. And if burnout is at play then that’s a meta aspect as well.

Being at the office is work.

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.

I've diligently tracked my actual time worked every day. That's time spent on productive tasks directly tied to my projects, not time spent in meetings, commute, and other wasted desk time.

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.

I know from experience that I am capable of working productively for 10+ hours continuously on a single project but this extreme flow seems to only happen under extremely specific and not easily reproducible circumstances that generally run counter to overall "productivity" (ie: It is usually late-night work on a pointless hobby-level program).

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.

I can work all day, but I have vast diminishing returns after hours 4 or 5. Especially if the work is intellectually complex or tiresome in any way. Oftentimes I overextend myself out of necessity - but usually work becomes exponentially stressful or futile at that point.

Depends on what I'm working on. If I'm working on something that I made from scratch and totally understand, and it's something that I'm skilled at, I can go for 11 hours. If I'm doing something totally new and trying to understand code that someone else wrote, I struggle to be productive for 2 hours.

Honestly I find your whole question rather puzzling. I mean, I get what you are asking. But the way you are asking seems as if your time is only valuable when you do 'real work' - which in this case I suppose is development work. In the same way you wonder about 'real life' but your life is as real as it gets. It is, of course, quite ordinary to not spend your whole day coding, but working on other stuff as well.

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.

Are there any persons who can work, say, 8+ hours? I mean, really work, not be at office.

Yes. Some people can, some people can't. Some people can, but they don't really need to in order to do the job that they get paid for. Some people struggle for 9 hours a day trying to do the job that someone else can do in 2.

Mental performance varies tremendously from person to person, as does athletic performance. Can someone run 4 miles in 20 minutes without stopping? Sure. Some people can keep up that pace for a marathon (26 miles).

I wouldn't worry so much about what other people are doing. Just focus on your own performance and improve it (or don't) based upon how you feel about your productivity and its impact on your life. If enhancing it is your goal, you've taken the first step of measuring it and understanding what influences it. You could cut out distractions and see how that works for you.

For me, improving my performance has always meant synching up my work with what interests me. Sometimes that can mean changing what I'm working on - when I have that flexibility. Sometimes I have to jump-start my interest in a more boring problem by trying to mentally frame it in a way that I framed other problems that have interested me in my life.

Related to this topic, I recently listened to “Compete to Create” (https://www.amazon.com/Compete-Create-Approach-Leading-Authe...). It struck me how much time professional athletes spend on preparation and recovery relative to engineers. Even more striking, this is considered by head coaches to be a key responsibility of employees doing the work.

> An average NFL broadcast lasts well over three hours, yet it delivers a total of only 18 minutes of football action. (https://fivethirtyeight.com/features/how-much-football-is-ev...)

It’s interesting how professional sports evaluates & compensates employee performance separate from employee time at the office. I wonder if professional engineering might learn anything from this?

Coding is very feast and famine for me. Im a experimental physicist in a fairly small group so Im almost always developing solo. Sometimes there's a gap of a week or so without coding if things are happening in the lab. On average i probably work 40 hours/week, but only about half of that is spent of highly demanding tasks. I spread work pretty evenly across the full week.

However, when accelerator time is less than a month away or some other major hard deadline approaches, it can kick up to around 14 hours/day where 90% of that time is highly taxing. That can be enjoyable under the right circumstances, but it isn't sustainable long term. Pushing more than a month straight with 12+ hour workdays usually leads to burnout which can subsequently cost a few full weeks of lost time. So in the end, it averages back to around 40.

I like having variations in workload. i think it would become a grind to do exactly 9-5 m-f.

Junior faculty work more, but they are generally pretty miserable as a result.

I use wakatime.com for tracking IDE time. Generally I spend between 4 and 7 hours in an IDE.

My best days, I can hit 9-10 hours IDE time - but generally when I hit that, it's because I've spent the evening working on my own stuff.

It's incredibly difficult (and undesirable) to hit that number working entirely on my main job. Diminishing returns come in fast. Switching contexts to a project I'm personally interested in is critical.

I think the better approach to being productive is to aim for ~4 hours of IDE time, maximizing deep work as much as possible.

I use codestats.net for tracking code volume (measured in "XP"), dividing it by the IDE time in a spreadsheet to get the hourly code volume each day.

XP/hour a very noisy signal* , but not useless. For me, it usually varies between 400 and 2000 XP/hour - a very rough proxy for deep work when averaged out over long periods. I'm always trying to improve on the mean.

*e.g. debugging time yields a far lower XP/hour than greenfield development.

I work two to three days a week. I'm currently working a physically demanding, manual labor job. I prefer this to an office job. This keeps my brainpower available to focus on my own curious pursuits in my free time (which is 4 to 5 days a week). I invest most of my income, and keep some on my bank to pay bills.

My previous jobs have thought me two things

- I dislike 40hr work weeks

- I dislike sitting in an office, under fluorescent light, being surrounded by poeople. No offense to anyone who can do it (I envy you).

fluorescent lightS ended my in office career.

Would come in super early, turn lights off. Be fine for a couple hours. Others would come in and turn the lights on.

10-20 minutes later, boom massive migraine. Not the painful kind, but the IQ drop of 50+ points kind, completely drunk sensation. Work refused to make any accommodations.

This is why I hate logging time spent on individual tasks.

"Oh, so you only had 2 hours of productive time last Monday - what did you do wrong?"

I can work for 8+ hours (close to 14h), but there are a lot of caveats and the output is noticeably worse. Also, I can do it for a week or two, but after a while it takes a toll.

The number of times I spent hours on an issue in the evening only to find the solution after 30s in the morning is embarrassing.

So honestly, it's just common sense. As much as everybody fetishises long hours and 100h weeks, I don't think that's really achievable for most people.

> The number of times I spent hours on an issue in the evening only to find the solution after 30s in the morning is embarrassing.

Besides family life, this is my main argument for not working 8+ hour days.

When tired, relax.

> When tired, relax.

Agreed, it's just that in the moment, it seems like finding a solution for whatever problem I'm facing is a function of time. "If I spent hours on it, how could a break help?" It's counterintuitive that breaks help, but it is supported by science.

Before burnout I did these 8+ hours for real trying to improve software and hardware stack. It is at technical level from 90s. I wanted to have continuous integration, gigabit internet interface instead of multiple serial ports, fast DDR analog to digital converters instead of 400 kHz I2C. I coded, did project plans, calculated how quicker system will be after changes. Nobody wanted this. “Not a business case!” - I was told regularly. Then I was gone for 3 months. I came back to life and do not work more than 2 hours daily. This ancient stack recently failed very very badly, but I don’t care anymore. However, I work on my own idea for at least 4 hours daily. With longer break in the middle I can be productive for 8 hours a day.

Buracracy is never kind to the technically minded. You'd be better served working on your presentation skills than your engineering skills. Does anyone know how to make a presentation for an issue like this? Would you try to cast time saved as money made?

You are right, I should have done more presentations for non technical people in other organization and the great failure could be avoided. Normally managers should listen very good when somebody explains how to save €0.5M.

But for this particular organization can’t be helped. We ship products assembled with duct tape and that’s ok. Every piece of the electronics looks to be done by a child during first ham radio course and that’s also ok. I am glad having job during these times and don’t take it seriously anymore after my burnout.

If it's hard, mentally taxing work then likely around 4 hours total a day.

The funny thing is I also can't really do menial, brain dead work for long either. It seems to drain a different "tank" but its much smaller.

I've done factory work before and it is single handedly the worst torture on the planet. Imagine being bored when you were in pre-college level school. Now leave yourself in that state but for 12 hours. That's factory work.

3-4 hours of actual work: R&D, algo development, solution design. Max.

6 hours of writing and debugging SQL, simple linux systems maintenance, writing emails or powerpoints.

8 hours/day is just impossible for me.

On ok+ days, 6h (in two 3h sessions). Sustainably. Not just writing code, but also walking around and thinking, researching, rubber ducking, etc. I can maybe squeeze a third session, but it's 1.5h and pretty crappy.

If I'm super zoned in in a meaty problem where I could work alone (or with one person max), I can obsess about it and invest all my waking time minus some 4 hours (1h lunch, 1h dinner, 2h unwinding). This is a straining effort that requires deliberation and appropriate care (either the work is galvanizing you enough, or you're gonna need downtime after this).

This seems to be on the higher side of the bell curve, from what I've talked with other folks, but certainly not at the top. I know a person that can do 10 hours, pretty much consistently, peppered with cigarette and meal breaks. One person, in all my life. Trying to emulate them will probably be very damaging for most people. Seen multiple people having breakdowns trying to do that.

You might not be on the high side but I recommend you:

- Don't feel bad about what you can do today. Just admit it candidly to yourself.

- If you want to, train this skill, pretty much like you'd train anything else with your body. I bet it's going to be a lot like weightlifting: slow, sloggy, and needing some restraint to not push yourself into injuries.

I'm at my computer for 8 hours. I can't be productive anywhere close to that amount of time, and it's been that way forever. Once in a while I'll have a spike of 1 - 7 days where I can sit and bang out code 12 hours a day. This is usually the culmination of some long period of rumination that grows into an understanding of some large task that I finally just sit and knock out. After that, I'm weary and I have to rest (for 3 months).

I used to often get in 8+ hours of coding a day, but that was 30-35 years ago. I don't know why I don't now, because so many things that might affect this are different in my work now.

1. I was of course 30-35 years younger back then.

2. Online for me then was via a dial-up modem, generally either to services like CompuServe or to an ISP that provided Usenet and email. The web was at most just barely getting started and if I even knew it existed (which I probably didn't) I don't think there were any browsers yet for Mac or PC.

Now there is an always on internet connection while working, making it much easier to get distracted.

3. Cell phones were not yet common.

4. Projects didn't involve nearly as many different things. Most of what I coded then fell into one of these bins: disk drivers, firmware for SCSI host adapters, BIOS code, little real time operating systems for embedded systems, the SDK and reference drivers for NCR's SCSI chips, and some network stuff.

Note that for most of these, you just needed some datasheets, some specs, maybe a book or two, compiler/linker documentation, and you were good to go. You could wrap your head around all the technology involved in the project. Actually, I could do more than just wrap my head around it all--I could become an expert in all technology related to the project.

Now, projects usually involve a bunch of other systems and use many third party libraries or services, and it is much harder to keep this all in my head. And those libraries and services are being actively developed, so you have to keep up with that. It is much less likely that I'll be an expert on everything related to the project.

5. Back then I knew exactly what I had to do when I started coding. When we were going to bid on a contract, I'd write a technical spec proposing exactly what we were going to deliver. Some of these technical specs were 100 pages (maybe even 200 on occasion).

If we got the contract, that spec is what we implemented.

Nowadays, design and coding are more iterative. Someone gets a general idea of what they want, and needs to see a version of that implemented to see if it is really what they want. They see that it isn't quite what they want, so it gets changed. It's all more vague and hand wavy.

I also found I could code for about 4 hours, so after that I like to reply to messages and read and sketch out ideas for how to approach bugs on paper, just get off the screen. And after a while of that I’ll go for a walk or something and maybe circle back around to the code if I thought of something.

I don’t mind this at all, 8 hours of screen time is a killer and no doubt led to my bad eyesight and wonky posture staring at screens when I was younger.

>no doubt led to my bad eyesight

fyi, "staring at screens" being bad for your eyes is a myth.

from: https://www.health.harvard.edu/healthbeat/safeguarding-your-...

>Myth: Staring at a computer screen all day is bad for the eyes.

>Fact: Although using a computer will not harm your eyes, staring at a computer screen all day will contribute to eyestrain or tired eyes.

So the myth is true, unless for some reason you don't consider eyestrain and tired eyes "bad for the eyes".

I can pretty easily work 8-10 hours in a day, and have done somewhat frequently in the run-up to important deadlines. I try not to because it absolutely kills my productivity for the next couple of days, so its almost always counterproductive.

Sure that one day is good but if you add up the work done on (say) the next two days the total is usually less than what you'd get if I worked normally for three days.

I used to pretty work long hours (worked 2 jobs - back when I had first kid and was still under mortgage). Now I spend more time with my kids and try to work as little as I can (optimize "productivity pulse", while minimize total time on computer)

This is my data of 2018 and 2019 respectively:

- https://www.dropbox.com/s/s8881zv58wzve33/2018.png?dl=0

- https://www.dropbox.com/s/55v7g4cn7ol0ix2/2019.png?dl=0

Some personal observations:

- On average, I achieve 75% productivity pulse

- There are some crazy days where I worked over 15 hrs, with maybe 10 ~ 11hrs being productive (read: code)

- Since I was moonlighting, I was most productive on the morning (9am - noon) and after 10pm (kids went to sleep)

- I don't meditate much, but working out really really help!

If you want to find out how little work you actually do, you can do this experiment:

Set an alarm to go off every 15-30 mins.

When it goes off write down what you are doing at that moment.

Do this for 1 or 2 days.

Alarm going off 20-40 times a day would stress me out. Also, being aware of the alarm can make one feel tension and they could change the behavior.

Well it's hacker news, how about a script that spawns a pop-up reminder instead! Still, it's a pretty effective experiment if you can commit to it.

It’s pretty commonly stated that most people can’t productively perform cognitive work for more than ~6 hours per day (of +- some delta depending on the person). Sure, you may be able to sprint a little longer from time to time. But sustained performance eventually suffers and most people will tend to be less productive (per hour at first, eventually overall as burnout sinks in) when working longer hours for a long stretch.

I’ve had three or four extended periods of overwork in my career, several months of 60-100 hour weeks, and it’s caused me severe mental health distress.

It’s really a shame that burnout culture is so common in the tech industry. In so many ways we’re very privileged, but this culture is a very high cost for workers who can be pressured by it.

For those saying lass than 8h, how do you handle the office?

At home I can happily churn away while in the flow and watch a bit of twitch when recharging, but at the office I force myself to stare at work and once the energy is drained the productive part of the day is basically over.

I work maybe two hours a day. They're very productive, but I cannot be productive constantly for more than that due to having to wait on other people in order to get stuff done, and, of course, the inevitable burnout which will occur if I exceed that.

When I'm motivated I can easily do 8, 9, 10 hours of productive work in a day. That's usually the case when you are early in a big task, churning out code with rapid results showing up. Closer to the end, it's the opposite with perhhaps 1,2,3 hours of effective work in a 7-8 hour day. On average It's going to be somewhere in between.

This is how I want it to be though. Obviouslt I enjoy my work most the days when I'm in the zone producing a lot. But I also don't want any expectation of my productivity to require that. I'm in a position where I can do 2-3h of effective work per day and exceed the expectations I have on me. I like that.

I am on Slack ready to answer questions for 14 hours a day.

I attend meetings/review PRs/toss ideas around on Slack for 4-5 hours.

Productive work - varies wildly. Some days, when I'm resting after an insane week it's 0 or close to it. Other days it's 8+ hours when it's mad crunch time. A regular day is about 3-4 hours of productive work. My employer is very happy with me, keeps promoting me/giving me raises. I've found that my contributions are generally less measured in LOCs, and more in finding business problems, designing technical solutions for them, and communicating them to non-technical stakeholders.

I'm in management. While the job description always says spend a significant amount of time coding, I tend to eschew that if I can get away with it. I'm only writing code if I need to get in the trenches or things are in a such a good place that I have big blocks of free time.

My workday is 10-4:30. Of that I'm probably doing 3-4 hours of productive work a day (code review, architecture, planning, 1-1s, meetings). I don't have any useless meetings, but the real killer is the 30-60 minutes between meetings where you don't have enough time to do anything productive.

Unicorn startup in Canada.

For me it varies a lot, I think it's very easy to think you are working when you are not. But also easy to work and not realise it.

I think a lot about Joel Spolsky's post [1] on the subject. It depends on what you are doing but I think in software development you need to look at effectiveness rather than time spent.

[1] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

Now that I've started my own business and am mostly flexible on working hours, I've found that I can work a lot more by leaning into my productive times.

I'm usually at my most productive from about 7am-10am. Then I eat breakfast and relax for an hour, and afterwards I can get a couple of hours of work in before lunch (though this is usually less focused time used for more menial work).

I'm useless from lunch until about 3pm - I've always known this; at the office I would just have a huge cup of coffee and try to focus. I take a break and play videogames or read during that time, then I pick it back up for a couple of hours of focused work from 3pm-5pm.

I cook and eat dinner, and then if I have shipments to pack (I'm still very early and shipping physical product myself), I put those together after dinner. I leave that until the end of the day because it's mindless but has to be done before the morning, so it's a good way to force me to do work regardless of how I'm feeling about it.

So I'd say about 5 hours of focused work (I can get in more if I'm super excited/in the zone on something) and another 3ish of more menial stuff.

I worked several years as a feelance audio engineer. When I started out I remember beeing concerned that I didn't have enough productive working hours. I found it hard to have more than 5 hours productive work done during an 8 hour work day. Also, since I was invoicing for the hours worked I felt that I should be far more efficient. After discussing this with other freelancers I found this to be quite common. Now, many years later, I consider 6 productive hours to be a really good day, and I will invoice it as 8 hours.

Today I manage a team of developers, and my experience is that the quality of the output is much better if they are focused and well rested, and that the amount of hours worked does not directly translate to better work. So if someone on the team is tired because of their kids not sleeping or something similar, I actually tell them sleep a few more hours. It seems counterintuitive, but I find it to work better for everyone on the team.

As someone who has gathered this metric at several major software companies, you're doing well. I'm sure there are individuals that have higher "efficiency" but in aggregate all employees are much less productive.

Tons of people are saying "oh all that other non-coding stuf stuff is productivity too" but I think they're missing the broader context. Sure, Software engineers can write emails and status updates, but it's definitely not the most productive use of their time. We could also have engineers serve food at the cafe and empty out the garbage cans, but we don't because others can do that. It turns out many of the "work" things that are socially accepted can also be done by others. The one non-code thing I'm in favor of engineers doing is talking to customers and doing research. Most of that should be done by a PM, but for added context it's always useful to get some firsthand experience too.

After almost a decade I'm still unable to answer this question properly and I think it's related to the fact that this is creative work, so it can't be meaningfully described this way.

Anyway, a certain Christopher de Cinque hit the nail on the head on this matter in an interview:

http://mousertime.blogspot.com/2010/07/closure-in-moscow-int...

FTA:

How does Closure in Moscow normally write a song?

We don't write any songs ourselves so to speak. They are beamed to our conscious minds from the higher dimensional realms of our subconscious. Like a text message from god: "hey guyz, thought u might lyk this song idea. Luv God lol x". When I try to wrote lyrics it doesn't work... But the ones that come out like a bolt from the blue, autonomously, that's the good stuff.

Depending on energy levels, amount of meetings and other factors I swing between 4 hours a day up to 8 of active coding. During times of severe pressure I have had a few 12 hour days (edit: This is not healthy nor sustainable for long).

This is all active code input. Tracked using Wakatime. No affiliation, just really like the service.

I try to aim for 4-6 hours of real work a day but a lot depends on what you call work. If you mean stuff I get paid for, my workload is variable. If you mean doing productive stuff, I probably do around 8-12 hours a day.

I do a lot of writing, which means a lot of reading. Some of that writing I publish, a lot is not.

I develop my skills, not always in ways that are directly related to tasks I do for money, but they generally end up contributing to my income.

I also don't really have a weekend. If work needs doing, it gets done and I take the time when I don't have work. I worked 3 days in a row about 12 hours a day on a hardware project I'm shipping, building hardware, testing software, writing a manual, imaging cards. I'll do more of that this afternoon but I'm not working a large amount of hours today due to unrelated outages.

It depends on how you define work and also who is deciding what you work on. I am working on my own startup as a solo founder. Any time, I am not with my family, working out or eating/sleeping, I am 'working' - about 10-12 hours per day.

But not all of that time is difficult (deep) work. I code, I design, I talk to users, I read, I do research, I take notes, I think, I plan. Other than coding, none of those feel like 'work'. Coding feels like work because it is both math difficult and bodybuilding difficult - (not my words, I read them somewhere).

I enjoy the autonomy and seeing the impact of my decisions firsthand. I doubt I would have the same hours or energy if I was working where someone else was deciding what I would work on or if I was far removed from the results of the work.

Having a 1 year old and minimal daycare has taught me that I never fully appreciated the time I had prior to having a child.

I now work fewer hours, but by necessity, those hours are planned out in advance with no time wasted. Whereas before I could throw myself at a project and bash my head against code for uninterrupted hours, I now must think through problems at a different time, and work on the solution as soon as I sit down.

It is still an adjustment, as I cannot go from 0 to 100 the moment I sit down, but it's allowed me to maintain ~80% productivity with half the time.

As crypt1d says, your work is more than the minutes with the IDE open. Everything else may not be programming, but it is work, including those small bouts of decompression during work

Not a programmer, but I divide my day in something like: First hour: Morning greetings, follow up from previous workday, getting my area organized for whatever I have for the day, check HN and news. Next 3-4 hours before lunch: Tackle the most difficult problem or whatever task I really don't want to do but must. The goal is to have the task initial steps completed (planning/thinking) so I can work on it throughout the week. Next 3 hours: Continue working on the tedious task above or whatever work needs to be completed. Last 1-3 hours: Finishing up tasks that can be completed before day's end.

For personal projects, I dedicate as much time as needed as long as it doesn't hinder my family or fitness time.

I can work 8+ hours up to a few weeks in certain intense situations where:

(A) I feel like I’m making good progress

(B) I like the work

(D) few personal obligations prevent me from working as much as I can

Cases I’ve faced this include:

- writing chapters of a book

- solving a really interesting and foundational problem for my team

- creating a much needed open source tool I really believe needs to exist

- real customers that really rely on my software need a fix / support

After working intensely, I will switch to a few weeks of low effort work, and not be as productive, and being a slacker for a while. My mind needs to recharge...

Generally I do pretty poor with a consistent 40 hrs, and instead oscillate between high and low energy times.

I can do at most 4 hours of high intensity focused work in a day. But usually administrative work at my job takes up so much time (interviews, meetings, standups, etc.), that I don't have to worry about that limit anyway.

> Are there any persons who can work, say, 8+ hours? I mean, really work, not be at office.

The only time I worked continuously for 8 straight hours is when I participated a game jam (Ludum Dare). I did it several times in my life, but boy, is that exhausting. After finishing the good 48 hours, you don't even want to think anything computer related. All I wanted were flowers and baths and some yummys! A 72-hour jam was even more extreme and I actually ran out the steam in the middle. I've never run a real marathon or some sort, but I wonder if the experience is similar to those.

With no external distractions (meetings, etc.), I have the ability to consistently do 6-8 hours of focused coding per day. Under a deadline or at a hackathon, I could hit 8-10, but that would lead to burnout and the last few sessions would be unproductive.

At work, this is never the case. Between meetings, running into frustrating build errors, etc. I've found that most days I do one deep work session of two hours. On good days, I get in another one for a total of 3.5-4 hours.

PS I made a website (trywinston.com) to track deep work hours. Would love to get feedback from the HN community on it.

If I really get into a flow I will forget to eat and my dog becomes annoyed with me. That’s when I get irritated by stupid phone calls and turn off all of my messaging alerts. I used to do that sort of thing well over fifteen or sixteen hours at a time, but I have tried to curb those types of long sessions recently. I do not think the work improves just because you put in longer hours and perhaps needs even more cleaning up afterwards. so now I tend to think it is just as important to step away from things for a while and do something completely different.

That doesn't sound unusual.

Back in my coding days, I could get into the zone for 4-5 hour chunks of time, but only if uninterrupted, which was rare. I'd say a typical day had 2x 2.5-3 hour blocks of productive coding, the rest of the 8-10 hour work day was meetings/conversations/etc plus an hour or two of not-work (internet, walking outside, etc).

This varied quite a bit over time, based on team and project. Greenfield projects, usually done in a group with lots of peer-programming and fast iteration were quite different than solo maintenance of legacy codebases.

For quite a while I've used Daily which asks what you're working on every 15 minutes. I average a little under of 4 hours of deep work a day. On an absolutely fantastic day I might be able to hit 7 hours.

Keep in mind I consider myself fairly motivated and I still have days where my deep work total is an hour or two.

["https://apps.apple.com/us/app/daily-easy-time-tracking/id686..."]

I'm a phd student in physics, I'd say about 3 or 4 hours a day

I was that student once. I can't analyze or fault your work habits, especially since physics might be even harder to measure than coding. (Of course a lot of physics is coding). There's a difference between 3-4 hours of focused work surrounded by a regular day of work, and 3-4 hours of procrastinating. I was on the wrong side of that equation.

But I was up against a number of realities: 1) My project was not in fact moving forward at a sufficient rate. Work is not static, but decays if you leave it sit there, so the progress rate has to exceed the decay rate. And it wasn't. 2) I was paying through the nose in opportunity cost. 3) I wasn't happy with myself, and in fact was kind of depressed.

A stress of grad school is that you have to be self managing, and I still don't have a good formula for overcoming this problem. But I survived and eventually finished. My advisor leaving the university put a fire under my ass, because I had to finish before the lab got demolished.

But this is the other thing to know: The risk level is extreme in terms of something bad happening that sets you back or kills your project altogether.

One thing I found was that some kinds of work were easier to get into "flow" than others. Coding was easy. So I actually let coding occur in what I might actually call spare time. Interruptions weren't as much of a problem in grad school. The boring stuff was the hardest -- grinding on a supplier to get me a price quote and then grinding on the purchasing department to send out a purchase order. That's where my procrastination really kicked in.

So, enough of the scolding. If you're doing the right thing to get through, then ignore this message. You probably know better than anybody. Best of luck!

I think my situation is quite different. I do very little coding actually too! I am quite independent and a purely theoretical physicist. I've already put out a couple of papers and would be able to continue well without my supervisor.

Although I have had really bad periods of procrastination throughout my PhD, but in general I work in short sharp bursts rather than sustained periods. You mention flow, it's hard to get into the flow when you are deriving new equations or approaches to things!

I'm a beast from approximately 3pm to 5pm. I might get about an hour's worth of real work done during the rest of the day. They need a warm body during standard business hours, but honestly if I worked from 2pm to 7pm I'd probably be twice as productive as I currently am working 8am to 5pm, but alas saying "70% of of the time I'm not doing anything useful" isn't a great way to convince the higher ups that they should hire an additional person to do the busy work.

It depends on exactly what you count as 'work', but if I count all the things I do for the sake of work that tie me to the computer (so counting e.g. the team's informal chat half-hour), then about 9 hours.

If you count just mentally intensive work (writing/reviewing code, writing/reviewing designs, making plans), then it's hard to do more than 4-5 hours per day (in terms of how long I can focus - days usually don't have that much free time for "real" work!)

This: https://github.com/ActivityWatch/activitywatch

I find my "estimation" and my "reality" are always pretty far off.

You need to track this to get an accurate assessment.

This is the best tool for productivity tracking I've found; it's free, open sourced and privacy focused.

It also exposes the APIs, so you can build your own dashboard for the metrics you care about; which was EXTREMELY useful in my case.

If you spend all your time coding, then I would expect your code to be pretty bad, the wrong solution, and ultimately a waste of time. Software Development is about thinking first, coding second, learning third. The worst developers I have ever worked with were coding all day long. The best seemed to not code much however they would think hard about how to minimise the work/coding needed and then implement it in a few hours, saving months of work.

I work for at least 9 hours from Monday to Friday, including a non optional 1 hour break at lunchtime (which wildly differs among coworkers in the same timezone, creating 2-hour communication blackouts). Out of those 9 hours, I code for 2 to 4 hours on a productive day. I spend the rest of my workday in meetings, reading tech literature, and browsing codebases.

When I'm working on a personal project, I can do actual coding for more than 5 hours a day. The difference is huge.

You can go even deeper with this idea. How much of your time coding is actually coding? Surely, you're not typing all the time. If you take 10 minutes to think over a concept and explore some options before writing a block of code, how do you know if that was an appropriate amount of time or if 9 of those minutes were wasted or whether you should have taken much longer than you did? Personally, I have no way of quantifying any of this.

You could say the same for carpentry. Are you working when you're commuting to the job? No? What about when you're at the job, and putting on or removing your personal protective equipment? Or when you're walking to the job site? Or hearing the instructions before you begin? Or looking at the work and thinking what the best way to go about it is? Or when you actually make a to-do list in order? Or when you move around the site? Or when you're not moving, but don't have a hammer in hand? Or when you do have a hammer in hand, but aren't swinging it toward a nail? Or when you are swinging it, but it hasn't hit the nail yet?

I would argue that if the concept of real work shifted enough there would be people who thought only the milliseconds the hammer is pushing a nail through the wood, aggregated throughout the day, is real work. Likewise, you could only count the time the keys are on a rising edge between 0 and 1.

My rule is if you wouldn't do it if you didn't work, and it's necessary for the output of the work, it's work.

It’s not an answer to your question but in terms of technical work I do nothing of use whatsoever after lunch. When I was a SWE I compensated by not showing up to work until lunchtime. I get up early.

Accepting this was liberating.

(I attend work for 51.5 hours a week as a high school CS teacher. I do a fair amount of coding. Some of it, to their delight, live! More than a first tier manager at a tech company can jam in, although my responsibilities are similar.)

A lot but it varies a lot day to day. Some days only a few productive hours, others 12+. I have the privilege of being the founder, though, which means I mostly work on what I want to, which is a totally different ball game to being issued work by a boss or whatever. Counter to many, my most productive coding occurs on the longer days as I can keep the entire task 'loaded' into my head and that's a big timesink.

I aim for six hours a day, broken by lunch. Includes time spent in conversation, planing. I can do more in a emergency, but it is very draining and I am not paid enough.

I do my own thing after dinner, to varying degrees

I work from home. If I were in a office it would be eight hours, for the same productivity.

I work four days a week, but that is because I am paid a monthly rate and the hourly rate would drop too low at 30 hours a week! I would rather work five days.

After ~15 years in IT, I found a position where I can work with very few interruptions. I always thought that I'm unable to focus for the whole working day because of the many interruptions. However, I figured out that 4-5 hours of highly focused programming is the most I can do for work. But I'm also able to do private work before/after that, but for work-related projects, I'm done much earlier.

Anyone interested in knowing what they're doing should check out ActivityWatch, it spies on everything you do and present the data in nice graphs.

I've been approaching my record recently of 8-14 per day, but short-term burnout comes and goes, and I'm only doing it since I'm working for myself. There are definitely limits, but it varies from person to person. If I actually read dense things and program for many hours straight (8+), I often end up so exhausted I need to rest in bed for an hour or so before I can continue doing things.

That depends entirely on how many meetings I have that day.

No meetings? I can squeeze in a solid 5-6 hours of productive time.

Any meetings? I'll be lucky to squeeze in 2 hours.

For me it really depends on the project. When I joined my current company we were much much smaller (6 engineers total), and there was a lot of new stuff to be built. I could easily work 8+ hours in a day, of actual coding.

Now, I probably get closer to 5-6. Though that may be impacted as well by the pandemic, where work from home is finally catching up with my productivity (been work from home since March).

I do the same thing with the timer app. I've only worked more than 8 hours when there was a tight deadline. I was surprised by how exhausted I felt on those days. On a normal productive day I get 6 hours, on a day where I feel shitty I get 4 hours. I was actually surprised by the amount of work I get done with only 4 hours of focus per day - no complaints from my boss or anyone else

About 8. I can't imagine doing more than that. There are only so many hours in a day, and the rest are taken by: - 7 hours of sleep - 2 hours of dealing with food (cooking+eating+cleaning) - 1 hour of exercise - 1 hour of miscellaneous house chores (organization, cleaning floor and furniture, dealing with plants, etc.) - 3-4 hours of personal project / learning time

Do you mean this year? When I am sharing a home office with my wife an 6-year-old who is doing online Kindergarten?

I get a solid, uninterrupted hour of programming for 6-7am, and then I am at work for another 8 hours, but I don't think I could claim more than 4 billable hours most days.

When I was in the office the ratio was a little better, but shorter days probably resulted in similar output.

When I worked, I tried to get in 5 billable hours a day. That's all I had the mental energy for. I'd work a little longer than that but anything over 5 hours was gravy.

I know everyone says to bill by the day but I billed by the minute. If a friend called me, I would stop the clock to talk to him. Billing that way I never felt guilty taking a walk or talking to a friend.

I'm using the "forest" (http://forestapp.cc/) app to track how much 'deep work' I can do. No affiliation but a huge fan of it.

It's been quite eye-opening how much work I can actually do in a day. In a good day it's about 4 hours. Usually less though.

Slightly on a tangent, but I use Timing to automatically track my time.

On GNU/Linux, there is ActivityWatch. RescueTime works cross-platform.

Love rescue time

Productive work: probably 4-5 hours

All work related task (email / slack / reading the news / paperwork / ...): 8 hours

Time at my desk: 11 hours

Is this for real? Not being able do your main task, whether it be coding or something else, for more than 4 hours a day is a very strong signal you need to do something you are more passionate about in my opinion.

Startup founder here, I can easily code 12-13 effective hours a day when that is the top priority for the company.

before pandemic maybe 5 hours/day and 3+ hours were for casual discussions after lunch and some thinking/walking time to refresh.

while in pandemic, with lots of distractions here and there at home with kids, maybe 2 hours/day or less for coding, other part is trying to imitate productive person by answering slack messages and staying online.

My only excuse is, company hired me and in contract stated that work should be performed in an office provided by company, if you are not providing office, I am sorry, but you should cope with my distractions at home and get whatever I produce, my kids are more important to me then your automate everything for useless corporate politics game. I can't say to my kids "shut up I am working", "I am not at home", "imagine I am not here", "please shut the door" and so on.

I vaguely remember some IBM study (maybe someone has the link?) on code reviews that concluded 45 min is the average sweet spot afterwhich bugs start slipping though. It also mentioned how long one should stay away from the screen to get back to top performance. (Simple things one can do 20 hours per day ofc)

Work: 6-16 hours a day. Depends how interesting what I'm working on is.

Personal projects: as long as necessary

1-2 maximum and that's just investing and looking for opportunities. I don't see any interesting problems that I could solve with my IT background and that'd be worth sacrificing a significant part of my remaining life time for.

4-7 depends on meetings schedule. I would still code during less important meetings.

For me problem is doing high impact work. Product often priotize wrong thing or I spend my time fixing internal frameworks designed by astronaunt architects.

I'd say, accounting for all of the wasted time, and weekend hours, it's probably at least 50/week. Maybe 60. (Dev work at a startup - I am an early employee with a lot of equity.)

For me it totally depends on the job. Most days and employers are just a slog and so I can work as little as two hours a day in these conditions.

But for more interesting employers and problems, I can do 6–7h.

Scrum master here. I work at least 9-5.30pm each day, but 5.30pm would be an early sign-off. Usually it's at least 6pm.

Depending on the day, I could easily work flat out for 7-8 hrs during my day. Meetings, code debugging, code writing, co-ordinating with the team, answering bug queries, writing backlog stories and documenting processes are some of the things I do each day.

My personal backlog list is probably about 100 items long, and always growing. So there are always things to do, but this is the nature of the SM role.

Deep work happens when I am most relaxed and have a task that is somewhat creative. This could be developing a new process or idea, writing some small code improvement, or thinking about how to improve my team.

Per my work billing quota I have to work 62.5% of my time towards billable items... even if we have no billable to work on lol rest of the time goes to fun projects, yt, walks, etc

Most recent job was 60+/week. Probably closer to 80. A stealth startup. And yes, I did get burned out: total COVID isolation + hours + steep learning curve. (got let go)

Work max 2-3 hours and then it's reddit / hn all the way

I work six hours per day (and get paid for as much).

A must for me since I have three kids, all under seven.

During these hours I try to focus as much as I can. (I’m not a programmer though.)

does only coding time counts ? how about all the chores ( validating pull requests, meetings, slack/emails, writing/reading documentation, validating deploys in production, warrooms, hand holding the junior members, etc... ) ? i usually clock 45-70 hours/week, daily it varies from 8 to 18 hours a day.

actually productive work, i reckon it's around 4-5 hours a day.

VPE of a startup here. I work 10 to 15 hours a day.

Not for multiple consecutive years as measured in LinkedIn tenure years you don’t (assuming weekends get impacted too since you’re pushing 8am to 11pm daily at the edge).

I wasn't speaking in hyperbole. I have worked many 3am to 6pm days, and my typical day is 8am to 6pm. I have only had a few sane days, and I don't take breaks. I feel like shit most of the time.

Thanks for the down votes though.

I didn’t downvote :)

That's impressive. Do you think it will get better mentally at one point?

I guess what drives it all is that the work is meaningful, am I correct?

No I will burn out and probably quit within a year if we don't hire a larger team.

Don't wait. If you're feeling the burn ask for help or find something else NOW.

Same.

I have a specific schedule that I balance with caffeine pills, antacids, and advil.

I've also developed quite a few habits and strategies that help me keep pace.

Here's my virtual fist bump in solidarity.

Thanks man

After reading few comments I just want to say that you guys are the best community ever.

This is really so interesting to learn from others experience!

12 hours a day when I am freelancing, afterwards chilling for one or two months.

8 hours a day when I am doing long-term contracts.

1-2 out of 10 office hours are actual coding. In the remaining time I do random stuff like reading HN comments.

More than 8 hours generally, but I work on different projects which I switch between.

Whatever it takes, our labs are open 24 hours.

I don't like to keep a client waiting.

With pomodoro, I can get 8-14 hours of work done in a day. This is the app I use to stay focused and take short breaks between coding sessions: https://tomato-timer.com/#

Sometimes I code 0 hours per day, on a very productive day I code 6 yours MAX (no meetings all day). 4 hours of straight coding is plenty productive, you are unlikely to focus highly for longer than that, this is fact. Work remote, office hours come from the industrial revolution, as well as capitalism to make people more likely to spend their money on their very few free time.

A good book on this is Deep Work by Cal Newport. It is humanly impossible to achieve high focus for 8 hours....daily....

I don't understand why everyone in this thread is such a sucker for corporate that instead of answering the question on the post, they go off tangents about how "they can still work even if they can't focus that much anymore". It's stupid, it's evidence of mediocre and wasteful corporate politics. A waste of energy for everyone and everything.

Probably 5 hours

I'm not a programmer and this was some years ago at a corporate job, but it's potentially a useful data point given your actual question.

I processed accident claims and I needed to hit a weekly quota that came out to 60 counted tasks per day (this did not directly correlate to "claims completed"). There was inevitably anywhere from one to two hours worth of tasks that had to be done but didn't directly count towards quota, like phone calls to try to get a missing piece of information to try to avoid writing a letter to try to get it off your desk in minutes instead of weeks.

So I typically spent my first two hours handling those tasks, which had to be done but "didn't count," and then had six hours left to meet a quota of 60 counted tasks per day. Sometimes that first two hours resulted in zero counted tasks completed and sometimes it got me a few counted tasks completed, like four or five.

I generally went to the bathroom every hour on the hour. I had two fifteen minute breaks. Those two things together ate up roughly an hour of those remaining six hours.

So now you have five hours in which to meet quota for the day.

Team meetings, coworkers dropping by to ask questions and assorted other nonsense typically also ate away at the remaining time for accomplishing anything.

We aren't quite down to the Office Space quote of "I only do about ten minutes of real work a week" but this was a high pressure environment that they had trouble finding qualified people for. In my class of about 20 students for training for this entry level job, there were only five or six actual new hires and one of them couldn't hack it and washed out. The others were internal promotions, returning employees (one military wife was back in town, having moved away for a while when they were stationed elsewhere, and they were thrilled to see her) and transfers from other departments.

One of my coworkers on my team set a goal of getting a job at this Fortune 500 company and it took her like five years to get in. Another had a background in EMS and also set a goal of getting a job -- any job -- at this company.

I'm telling you all that to try to give some context because this is the only full-time paid job I have ever had. I was a homemaker for a lot of years and I've done freelance work since.

My understanding is this was "the best of the best of the best" at a highly competitive, award-winning company and a good day for me was about 4.5 hours of uninterrupted work with serious concentration.

I now do freelance work (and my own projects). If I spend part of the day "piddling productively" and at least four hours focused on really getting shit done, I'm extremely happy. I know from experience that's actually pretty kick ass.

I code for 8+ hours regularly, but that means I'm on the computer for 10-12+ hours.

TLDR: coding != learning, coding for 4h = easy, learning for 4h = hard, take care of your body, delegate what you can, automate the rest, save your attention

By coding I mean: reading errors logs, stack overflow, and the actual code/test/debug loop.

I've got two jobs and a small side project, so here are my directives: - minimize meetings and do quick syncs once a day, ask for priorities and responsibilities, make your own tasks, ignore the rest (all hands, HR bullshit, random groups, etc) - get down to business, keep your main goals in mind, think of a solution, research the docs/snippets/common solutions and then jump to the code. - have more then one context, I'm a sr devops, a sr data engineer and got a side project. Sometimes one job gets boring, and I'm excited about the other. I rarely get bored at both jobs at the same time. So I'm always motivated and never afraid of getting fired. - This is the most important: stay healthy, walk, drink water, eat well. This will give you energy, repair some of your posture flaws and prevent your body from breaking down from such heavy workload. - delegate mundane tasks: 2 incomes means, I don't cook, wash, clean, nothing. - automate everything, make filters for your inbox, use a calendar to remind you of stuff, - Attention+focus = gold, don't spend it on shit. silence notifications, uninstall social media, put you phone on do not disturb, silence all channels on slack, create alerts for keywords in slack for stuff you actually need to know. e.g: jenkins, your_name, project names

My time is spent as:

Mon-Fri - exercise: 1hour - job1: 4-6hours - job2: 4-6hours - sleep: 5-7hours - food, drink, hygiene, general body maintenance: 2h Sat-Sun: - exercise: 1hour - sleep: 8-10hours - pick up some slack from the week, study something I need for work, work on one of my sideprojects: 2-3hours - relax, fun, games: whatever is left

job1-job2: I start at 9:00 and I usually work until 22:00. That means I'm always on slack/teams and I do overlap the two jobs.

I make regular 10min breaks every 50-100min, and I stop for lunch (eat, power nap, back at it).

exercise: walking is fine, go to a gym if you can, don't overdo it so you can do it tomorrow.

sleep: I don't get sleep deprived but I do get tired by Friday, which makes the weekend so much more enjoyable

You can be productive all day, just like you can be a long distance runner, start small and keep progressing. In you first days of running/programming/* you are mostly learning a bunch os stuff and figuring out the profession, yourself and your strengths and weaknesses. So it takes more energy because most of it is spent on learning about your trade and about you.

Know thyself. I like programming, I like math, I like learning, I like hard stuff. I'm not a design guy, I don't do UI, and I won't be a project manager. So I place myself in jobs/tasks/places I can maximize my output with minimal effort.

Doing a full day of devops is easy to me, but I'd cry after 2h coding a react app. Devops I know, so it's more time outputting solutions and less time inputting knowledge. React, I've got to basically learn every step of the way, so it's 10 times more exhausting.

So, True, you can't be productive all day. But you can 100% go way above 4hours coding.

I want to get maximum return for minimal work. I don't work during meetings, for example. My camera is off and I'm painting miniatures. I can pay attention to speech and do that, but coding uses a similar part of the brain than speech, so I cannot pay attention to both.

People complain about red tape and useless corporation time wasters, and I get you, it's draining. But you can learn to use those hours for your own stuff. Vacuuming the house while the all staff meeting is going on in your ears, or hell, you are attending but not listening. Just have a friend in the company who can brief you.

This all changes when you are an expensive contractor, where you can bill 8 hours when the job only took 4. Still, you have to be attentive and present so that you represent value. Clients pay for the illusion of professionalism, but you do the same work their devs do, just with fewer meetings and for 3 times the wage.

Anyway, what do I mean by all this? You should ask yourself what you want. I comfy seat at a corp with a 9-5 that is really just 2-5 hours of effort, or more money for more effort and more agency by being able to say no to meetings and work when you want to work. That works is called consulting. They have their pros and cons.

You can easily do routine work for 8+ hours daily. The sort of work that can potentially be automated one day. What you call "coding" is routine enough in my book.

But if you're doing something novel and solving hard problems, I think 4-5 hours would be a maximum for sure.

How can you presume to know if their coding is "routine" or not?

I 'think' they mean the universal you. Sometimes replaced with 'one'.

Exactly. :)

What qualifies ad routine coding and hard problem solving in your book?

I would call routine coding something like you have a set of constraints and you just have to manipulate code to fit these constraints.

Reply on news.ycombinator.com