Live data from Hacker News

Productivity and the Workweek (2000)

groups.csail.mit.edu

211–220 of 233 posts

Re: Productivity and the Workweek (2000)

#211

Earlier quoted context omitted.

After you collapse on the sofa for a few minutes you then get back to work keeping yourself current, right? A reasonable measure of what it takes to stay current and relevant in this industry is twenty hours of dedicated reinvestment per week. Often times this reinvestment time is not afforded at work and as much as employers want to provide this as a benefit to developers, few offer the resources or time to allow de…

That is insanity. What could you possibly study four hours a day that would be worthwhile? That's just pumping in useless trivia information that will crowd out the useful development knowledge. Is it a web development thing? Framework-of-the-week psychosis? It just sounds like a recipe to get burnt to a crisp in a few years.

I think they're on the money with the dedicating a few hours a day to study/productivity outside of work - I just can't imagine doing it for the same thing I'm already getting paid for anymore. If they're really into programming/dev studies though it's totally fine but it feels like a recipe for burnout.

A lot of people do feel bad if they waste their days just looking at Youtube or social media all night after work - I think a lot of people feel the guilt after the fact but never work to execute on it because its so easy to procrastinate/skip small commitments of studying.

When I was at a shitty job I hated that meant most of that study time went to side hustles and learning the local language to build my CV, but now that I'm free and in a good job it mostly goes toward trying out completely unconnected things like Piano or Chinese - as long as it's productive I'm fine. Playing around in new things that interest you half for fun is the best approach to not burn out I think.

Re: Productivity and the Workweek (2000)

#212

I'd be interested to know if other software developers feel their current working hours are good/positive? From feedback I've had I'm generally regarded as pretty good at my job and highly productive but my current working hours leave me completely drained, to the point I go home and collapse on the sofa, make dinner and go to bed. And that's off an 8.5 hour day. It's at the point now where it's extremely likely I'll…

exactly. pretending being busy 4-5 hours eats lot of energy. Also sometimes, you spend weeks doing nothing and then your idiot manager wants to deliver something quickly over weekend. what a waste of life. My biggest regret wasting limited time of life on these stupid things and people.

Re: Productivity and the Workweek (2000)

#213

I'd be interested to know if other software developers feel their current working hours are good/positive? From feedback I've had I'm generally regarded as pretty good at my job and highly productive but my current working hours leave me completely drained, to the point I go home and collapse on the sofa, make dinner and go to bed. And that's off an 8.5 hour day. It's at the point now where it's extremely likely I'll…

> Software to me is extremely mentally demanding and draining, it requires short burts of extreme concentration, but what is more draining is making up the remaining 4-5 hours looking busy. Well said! I haven't met a single software engineer who hasn't described something similar to me. I'm the same, I like to wake up early, enjoy my first coffee and then I feel the most productive for the first 4 hours of the day. I…

yeah hopefully, still we are young.

Re: Productivity and the Workweek (2000)

#214
post #92

Someone wrote here about whether 3 hours or so out of 8 being productive "is not just peculiar to software work. There's an old post from a photographer blogger and funny guy if somewhat controversial [1]: > The Two-Hour Rule is a law of American business which states that "no salaried employee, employed by a business to work in an office, may exceed two hours of actual work in any business day." > The Two-Hour Rule…

I was an avid reader of his blog, but never read that. Genius.

On the footnote: reading his advice over and over again made me a better photographer. I still shoot RAW, as I like editing, but his advice on just sticking with AUTO is what made me far more productive rather that fiddling with trying to get the best shutter speed/aperture.

Re: Productivity and the Workweek (2000)

#215

I'd be interested to know if other software developers feel their current working hours are good/positive? From feedback I've had I'm generally regarded as pretty good at my job and highly productive but my current working hours leave me completely drained, to the point I go home and collapse on the sofa, make dinner and go to bed. And that's off an 8.5 hour day. It's at the point now where it's extremely likely I'll…

> you can get the work done very quickly and then have large periods of unproductive time.

Totally agree, but I've also worked in codebases where I spend a huge effort and don't get anywhere (these are usually codebases with dark corners which no one knows anything about).

Re: Productivity and the Workweek (2000)

#216

I'd be interested to know if other software developers feel their current working hours are good/positive? From feedback I've had I'm generally regarded as pretty good at my job and highly productive but my current working hours leave me completely drained, to the point I go home and collapse on the sofa, make dinner and go to bed. And that's off an 8.5 hour day. It's at the point now where it's extremely likely I'll…

I have similar experience as you, and what I concluded was that it was the 4-5 hours of looking busy that really made me tired, usually I was surfing the internet, switching to a new page every minute.

A better strategy is to work 15-30 minutes and then take a few minutes break where you meditate.

Re: Productivity and the Workweek (2000)

#217

Earlier quoted context omitted.

That is insanity. What could you possibly study four hours a day that would be worthwhile? That's just pumping in useless trivia information that will crowd out the useful development knowledge. Is it a web development thing? Framework-of-the-week psychosis? It just sounds like a recipe to get burnt to a crisp in a few years.

I personally study a thoughtful blend of the a number of subjects, including: 1. Machine Learning 2. Practical Software Development Tools and Techniques 3. Computer Science Fundamentals 4. Design 5. Marketing 6. Business Fundamentals 7. Strategy 8. Communication I believe all of these are elemental to being a successful software developer in 2019. Machine learning is eating conventional software development from the…

I think 8 subjects is too much too make any meaningful progress. I have 2x 30 minutes when I'm on the train, and that's just too little to study anything worthwhile. I mean, I can read a novel in three days, but anything involving math costs me about 1 hour to get into before I can really learn something.

Re: Productivity and the Workweek (2000)

#218

I'd be interested to know if other software developers feel their current working hours are good/positive? From feedback I've had I'm generally regarded as pretty good at my job and highly productive but my current working hours leave me completely drained, to the point I go home and collapse on the sofa, make dinner and go to bed. And that's off an 8.5 hour day. It's at the point now where it's extremely likely I'll…

> Software to me is extremely mentally demanding and draining, it requires short burts of extreme concentration, but what is more draining is making up the remaining 4-5 hours looking busy. Well said! I haven't met a single software engineer who hasn't described something similar to me. I'm the same, I like to wake up early, enjoy my first coffee and then I feel the most productive for the first 4 hours of the day. I…

I think this is where some of these Kalzumeus Classics come in:

https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

https://www.kalzumeus.com/2012/01/23/salary-negotiation/

The problem is most of us do not market our skills and the value we can provide. We market ourselves as being available to be handed tasks to toil on for forty hours a week.

Figuring out the value we provide, and how to explain and market that value, is hard work and higher risk, though, so many of us take the safe and easy route of a full time job sitting behind a desk for forty hours, whether or not we can fill those hours productively.

Re: Productivity and the Workweek (2000)

#219
post #88

Earlier quoted context omitted.

“Fix your estimates” I have, for a long time, been very opposed to single point estimates, especially when those estimates are going to be interpreted like this. For any task that has any kind of uncertainty to it, there’s a range of time for how long it’s going to take. If you take longer than your single point estimate, you’re going to be punished for it in some way (work late, etc). If you take less time than your…

I agree, I am assuming you know how we implemented Scrum.... We do point estimates very early to know if a story is too big and needs to be broken down and for rough release planning. The developer that volunteers for a user story will do an hours estimate when the user story is fairly well fleshed out. We do not use estimates and actual's for any management metrics, this is for the developer to gauge their workload…

> 40 hours of work for a two week sprint

You're my hero. For real!

Re: Productivity and the Workweek (2000)

#220
post #160

Earlier quoted context omitted.

The sprint is two weeks long, if you finish your user stories in a week like OP, then is a full week of downtime ok? That will encourage everyone to sandbag the work to only need to work every other week. No one is talking about milliseconds or even hours, but I don't want the developers making up stuff to do like the OP mentioned or taking stuff off the backlog that the team did not agree to for the sprint. He used…

I believe many people, including myself, are caught up on the idea of taking "someone else's work". I personally would be much more comfortable with the items you suggest if they either had not been assigned to someone (new or backlog task), or organically offered up (someone says they probably won't get to a task during standup or somesuch). Additionally, it would seem that you are assuming that the dev is doing som…

I think the root of the issue I am getting backlash on is team work vs individual work. If you are using Agile as a process to just organize work then ignore all my comments. I am using Agile/Scrum as a way to build strong development teams (not just groups of individual developers).

For the locking sprints, that is a matter of protecting the developers from management and the customer. The product backlog can be moving target all day, but the sprint backlog needs to have some backbone so the developers have focus and are not pulled different directions every day. If the sprint backlog needs to change then the developers will come to me for help. Our history is from a very chaotic environment and the developers really like having some sanity/consistency with defining the sprint and holding it still. If the customer wants something else, then we can deal with that in the next sprint.

Post reply on HN