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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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

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.

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.

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?

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.

"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

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.

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.

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.

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

BRB, fixing the org chart. /s

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.

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.

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.

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

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

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.

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.

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

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.

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.

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

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.

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

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.

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

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.

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.

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.

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

8 hours/day is just impossible for me.

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.

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

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.

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.

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!

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.

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.

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.

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

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.

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/

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.

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.

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.

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.

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

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.

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.

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

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

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

(B) I like the work

(C) the work has a meaningful (not BS) near term deadline or milestone to achieve that I care about

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

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.

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.

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.

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

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!

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!

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!)

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.

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

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.

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

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.

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.

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

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.

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.

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

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

Time at my desk: 11 hours

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

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.

Personal projects: as long as necessary

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.

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

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

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

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 for the down votes though.

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

This is really so interesting to learn from others experience!

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

I don't like to keep a client waiting.

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.

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.

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.

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.