Ask HN: How do you decide when you've done enough work for the day?

I generally try to get as much work done (in life) as I can. Some projects I can work for 12 hours a day on, others I'm tapped out at 6, so I just maximize output. If output is below the debugging cost of that code or something, I stop. Could be 2pm or 10pm.

Once I get 5 billable hours in the rest is just gravey. I’m a consultant though so I get paid by the hour.

I always stop at 5pm. I take some kids for a walk to decompress. Around 9pm, after kids go to bed, then I’ll do another hour if I’m working on something fun.

I love coding, and I would be coding if no one was paying me, but there’s more to life than just that.

What's going to happen to your life is you're going to learn what other people's natural speeds are, what yours is, and what is needed for your specific job, and you're going to have a much better barometer for that. That's going to happen naturally over the next 2-3 years.

In the meantime, you can:

* Try to incrementally improve. Keep a daily log (wish I had started this my first year), write down your stupid mistakes, false starts, other things. Re-read entries sometimes. Try not to make the same mistake twice and to be doing more complex tasks over time.

* Do the "butt in seat" thing without beating yourself up. A good one is to try to work ~40h a week (even 35), except if you can see an immediate career benefit not to by working the extra hours on a side project or stretch assignment. It doesn't have to be 8 hours every day it can be 12 on one day then 4 the next. Log your hours (remote people should always do this) and note patterns. For example, if you are consistently working less than 40h, try working harder, more than 40h, reconsider your approach or appeal to your manager.

* Ask for feedback. You can set up a meeting with someone (for example lead, manager or just someone more senior you work with) and ask "what do you think I should do to be more useful to the project?". Alternately you can wait until a more social occasion or a lull when working 1:1 with someone and just ask "so how do you think the project is going?" If they think you have a time management issue, they'll tell you, if not, you're good. Side note, you may hear stuff like work on your soft skills, have better work life balance. It doesn't strictly mean "work less" but it means your coworkers think you're too focused on individual achievement.

How strict is your employer about butt-in-seat schedule?

If you have full flexibility, I’d suggest aiming to hit 40 hours on a weekly basis rather than 8 on a daily basis. That gives you the flexibility to work, say, 10 hours one day because you’re really on a roll, and to stop at 6 hours the next afternoon when you’re tired and distracted without feeling guilty.

Don’t go over 40 hours on a regular basis. That’s a recipe for burnout. A week of crunch time every 3 months is one thing. But regular 50-hour weeks aren’t sustainable for most people.

I’d also suggest setting goals in the morning for what you want to accomplish in a day. Put down your work when you reach the goal, unless you’ve got several more hours in the day. In that case, set another goal for the remaining hours. If it becomes clear that you won’t reach your goal within a reasonable number of hours for the day, put your work down whenever you hit a stopping point close to the time you’d planned to wrap up for the day.

More experience should help you make increasingly accurate estimates of what you can accomplish in a day, so you’ll hone this process as time passes. Plus it’s great practice at estimating, which is a difficult and valuable skill.

It’s unusual to hire junior engineers fully remote in part for this reason: more experience in a “typical” work environment give you more context for these sorts of judgement calls.

I own a small start-up and struggle with work life balance. I'm a night owl and generally not terribly productive in the morning, but once I hit my stride in the afternoon/evening, my productivity continues to increase and I often find myself plugging away at 3-5am. I have found that it's in my best interest for throughput to continue when I'm "in the zone", but it does create some friction with the spouse.

I'm very interested in how to define the "enough work for the day" question. Or we could just listen to Dan Reeder: https://www.youtube.com/watch?v=xNWhiXxdbWk

When the clock hits 4pm, I have a daily standup meeting. About half the time, this meeting occurs, and I go home afterwards immediately. If it doesn't happen, a quorum of people had something better to do. If I don't have anything actually urgent or interesting, I tend to bail with the others. Otherwise, I work away until maybe 5:15, then I go home.

I'm basically paid to be on-hand 9-5, so that's what I do. I don't check email outside work hours as a rule. If there's something technically interesting, or is important to do but cannot be done within the constraints of a business workday (basically, anything that involves deep thought, concentration, and sustained effort), I may choose to do it when that's convenient for me. And I know things; I remember, and I've been around long enough to know the whys and wherefores and sequences of events that led up to the present state of things.

What you are looking for here is primarily a feedback mechanism issue. This is something that is a hard problem, since good, useful feedback is never quite as simple as just asking someone. Employees are looking for it. Managers are looking for it. Executives are looking for it.

With respect to work time and workload there's always an element of presentism - if "enough" surfaced activity happens over the course of each week and the work is not obviously deficient, then most managers won't ask questions. And you already know that much, since you had many years of school to get that idea in your head. And when it's on-site, it's simple to get to that level - if you're in the office, you're at work, even if it isn't time-on-task.

But there is always going to be a level beyond that, of taking on tasks that are a good combination of "builds up a career" and "builds up the company" - stuff where you can act more independently, and likewise fail independently. You can easily fall into work that does neither or only one of those things, or convince yourself into workaholic behavior and sacrifice everything else. Nobody can offer a clear bright line of "this is the best possible course of action". But there is a "better" out there somewhere!

So if you can measure yourself by whether you did something of both career and company and other life things each day, then you already have a more balanced self-measurement than "quantities of issues" or "lines of code" or "hours in seat".

Try to know how many hours of "deep work" you can do before losing steam. Usually it's ~4 hours, once you get past that point, do some tickets that are not too demanding, and preparation for the next day. That should be around 6 hours of work and that's more than enough, almost no dev does 8 hours of solid work a day, a part of it ends up being browsing the internet and reading articles.

This is the question of the next few decades. How much do we keep the "x amount of hours a each day" thing built into our culture.

When the end of the day approaches, start finishing up whatever you were working on, and mentally prepare for what you'll be doing the next day. Then forget everything until tomorrow morning.

There's a huge amount of variability between developers, so don't think that the "workaholics" doing 50+ hour weeks are necessarily being more productive than you; unless you actually compare, they could really be struggling and just trying their hardest to keep up with everyone else. In the past, I've solved problems in minutes that someone else on the team had spent many long-houred weeks and eventually given up on.

As a remote developer, setting a schedule for yourself is really important -- at least when you are getting started. Once you have an established work pattern that you are happy with you can experiment to see how things work.

I recommend doing what you are doing until you feel like, "OK. I'm in a rhythm and things are going well." Perhaps you are already at that point.

Next, when you have one of those days where you are feeling good and want to continue, work an extra hour. Then play with how you are going to use that hour the next day. Will you start late, or leave early or have a long lunch, or whatever? Tell your coworkers that you're going to do it. "I worked late today, so I'm going to X tomorrow". This keeps them informed so that they don't panic if they are looking for your help the next day.

Evaluate the progress. Did it feel good to you? For example, starting late does not work for me. I'm a morning person and taking an hour or two off in the morning means that I will get started on my side projects... and never stop. Then I end up working my "day job" until midnight --- no good!

Also, evaluate the reaction on your team. Were they OK with your behaviour? Every team is different. It's important to try to work with the team and not just stubbornly go your own way. I've worked with people who have the attitude, "It's my right to do whatever I want. I'll come in at 2pm and leave at 4pm and make up the time when it suits me". I hate working with people like that because programming is a team sport and I have to accommodate your weird schedule.

I work time shifted by 9 hours from the rest of my team. I know it impacts them and I do whatever I can to help them -- including working late nights sometimes (even though I'm a morning person). But you do what you can. Some of my colleagues can't get up early in the morning, so I'm happy to accommodate them, just like they are happy to accommodate my choice to live on the other side of the world. There is a give and take there, and as long as you are aware of it (and not always taking), then I think it's fine.

Deciding whether or not to work late is always a judgement call. My advice is to consider 2 things.

1: Is it truly and emergency? The server is on fire and you are losing customers. Somebody needs to work on it. You should stay if at all possible. Even staying around to provide moral support for your colleagues can make a big difference. Sometimes there is nothing you can do, but if you hang around and read slack (or however you communicate) and make occasional comments, it can really help the team. Nothing is more lonely than sitting in front of a melting down server, not having a clue what to do and everybody has buggered off for beer.

Sometimes people say it's an emergency and it really isn't. In those cases, consider the cost of saying no. There will be a cost if someone asks (or hints strongly) for you to stay and you say no. It sucks. It's not what it should be. But it's very common. If you can afford to pay the price, then feel free to draw the boundary. If you can not, then do what you have to -- and then try to get yourself into a situation where you can afford to say no the next time.

2: If you just feel like working, then go for it. Keep in mind that this comes after you have established a "normal" working day for yourself and when you know how to take back the time later. But stopping yourself from having fun (even if it's making other people money) is just silly.

Always keep in mind your own health, though. When I was younger, I seemed to be able to work a lot of hours and still stay very energised. As I've gotten older, I can not longer do that. I have to pay attention to my energy level, because a 12 hour stint can wreck me for the next 2 days. That's no good for anyone.

Finally, I o...

To me, it's more about making sure that you accomplish while pushing your learning curve up. This is easier when you work for an employer, but hard when you work for yourself as you always want to push more in less time. Another thing in a virtual work model is to make sure that you are engaged with your other coworkers throughout a regular basis especially if there are some others that are not working remotely. I think it's more about making sure that the team has a good feeling of the virtual model. I wouldn't be too worried about keep tracking of the exact clock in/out.

Using TDD (Test Driven Development) I tend to stop working when fatigue sets in and I'm tempted to skip unit tests for the sake of immediate gratification.

I use rescuetime to track my computer usage and aim for a certain number of “productive” hours a day. This way I don’t feel guilty for procrastinating or falling into a hacker news hole, that time is not counted toward the productive time goal.

>> I'm a relatively junior software engineer, a little over a year out from university, with a cushy remote job working for big-co. And I never know how much work to do on a given day.

Protip: Optimize for consistent performance. It's better to close 3 tickets every day, than close 30 tickets on Monday and one or two every other day, even though the latter scenario adds up to more tickets.

(Obviously, replace "tickets" with your own measure of productivity.)

I'm always objective focused with my team...

1. we breakdown issues/bugs into 2 - 4 hour increments where we write test(s) to replicate. Then share with team. Hopefully there can be a fix in that time, else create a new issue.

2. we breakdown new tasks into 2 - 4 hour increments with a new function(ality) + necessary tests

Then we spend ~1 hour a day doing code reviews. Some days I can get through multiple issues, some days it's just 1. In either case, we can assume 5 - 8 tasks / issues a week are completed. How everyone does it is up to them; so that's how you decide how much work you need to do.

Unfortunately, estimating can be poor for these tasks, but that's why we time box it and require a team notification for any issues (plus tests). It works relatively well, and everyone checks for open PRs or code reviews between each task -- so blockers don't occur.

I recommend trying something like that.

I'm remote and have been prone to workaholism in the past. Here are my techniques:

- I do track my progress on key long term objectives. If I'm getting behind I need to know, and burn the candle at both ends until I catch up. This should be rare.

- I try to set a daily goal or two of stuff to get done to make sure I stay focused on something productive and don't get distracted with yak-shaving or non-work.

- I stop hourly-ish and assess what I've achieved in the last hour. Sometimes I'm just not getting anything done and I'm better off calling it a day to get some real rest and diversion.

I try to not go over 20k keystrokes a day

I know cause I start to get slow at programming and find it hard to solve problems.

Switching context has a cost. Resuming work has a cost.

If it is already end of day, it may be reasonable to start your next task tomorrow rather than spending time next morning trying to resume your work.

The night before I make the list of the three MUST-DO items, always three. Once those are done, I can bail whenever and feel good about my work product.

I have a similar expecting from my employees.

These items are the detail, the standing orders still remain (answer phones, do meetings, email, etc)

Having had my first tate of work in an agile shop there’s a lot of nuggets of wisdom here.

You need to plan. Merely having sprints will not make your days shorter!

Think what's your 1 day, 3day, 5 day, biweekly, monthly, quarterly, yearly, and 5 year goals for yourself, team, product and company. What unknowns may influence decisions or are strategies? What assumptions need to be confirmed? How often are we checking ourselves on our progress? When do we get to change our mind?Do these things and how much should you with in a day becomes very clear.

Best thing in my opinion is to have something external that limits your schedule.

For me and few it of my coworkers it definitely were our children. I know I want to be at home by 18:00, so that I can have dinner with my family. One colleague was starting at 7:00 and and finished by 15:00, because he was pisking up his kid from preschool at 15:30 most days :)

I am not suggesting for you to get a kid :P but knowing that every day I want to end by $HOUR because I have a $THING does wonders :-)