Live data from Hacker News

Productivity and the Workweek (2000)

groups.csail.mit.edu

161–170 of 233 posts

Re: Productivity and the Workweek (2000)

#161

Let's reduce economics to its barest rudiments: I'm pretty sure a worker could buy a house and support a family in 1950 on a single, average 40 hour a week salary; this was probably also true even as late as 1970. How many workers in the modern economy can buy a house and support a family on 1/4 of a 40 hour a week salary? Those "productivity" numbers are obviously cooking the books bullshit. Either that or they're n…

>I'm pretty sure a worker could buy a house and support a family in 1950 on a single, average 40 hour a week salary

The average family income in 1958 was $3300. Adjusting by CPI, that has the same buying power as $36,000 today.

https://census.gov/library/publications/1952/demo/p60-009.ht...

https://www.bls.gov/data/inflation_calculator.htm

Re: Productivity and the Workweek (2000)

#162

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've begun to think most software engineering should be done remotely. Easier to get into a flow state, no need to look busy, and you can work at times when you are most focused. I transitioned to full time remote, and routinely work 5 hour days, and get more done than when I was working 8-10 hr days

Re: Productivity and the Workweek (2000)

#163

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 wish I could upvote you a hundred times. I get at most about 3 hours of intense concentration per day. The need to show constant progress on daily scrums is what made me quit my job recently.

Re: Productivity and the Workweek (2000)

#164
post #162

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've begun to think most software engineering should be done remotely. Easier to get into a flow state, no need to look busy, and you can work at times when you are most focused. I transitioned to full time remote, and routinely work 5 hour days, and get more done than when I was working 8-10 hr days

Or we just need better offices. I hate working from home and don't want to have to rent a separate office space on my own dime. Luckily for me I work somewhere where I have a real office (with a door!) and no one cares in the slightest when I come and go or whether I look busy when I'm there.

If you like remote work, that's cool, but your complaints are with shitty offices, not something inherent to onsite vs. remote work.

Re: Productivity and the Workweek (2000)

#165

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…

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…

>A reasonable measure of what it takes to stay current and relevant in this industry is twenty hours of dedicated reinvestment per week.

Which industry is that exactly? Because it's sure not mine, and I'm a software engineer, which I thought was the default assumption here.

Re: Productivity and the Workweek (2000)

#166

Earlier quoted context omitted.

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 second what the previous guy said - what could you possibly be spending 4 hours daily on? Anyone who claims to be current and moving ahead in all 8 of those areas would immediately set off red flags and signal to me that they definitely aren't current in all those areas.

I would argue that I'm current on the machine learning and practical software development side and minimally current on the others and improving.

To offer some background, on the machine learning side I've built and deployed over one hundred models using nearly every major machine learning technique available today. To stay sharp I actively compete in Kaggle and other competitions (and have won a few small competitions) and have attended over six large ML conferences over the past two years. I actively read through every major published book on machine learning and nearly an entire bookshelf dedicated to the practice. These books, as well as MOOCs contribute to the majority of my reinvestment time on this side. I turn around and directly apply this information to competitions and paid projects to help it stick. I also read through as many ML papers as I can budget time for. Arxiv Sanity Preserver is a great resource here (http://www.arxiv-sanity.com/).

On the software development side I've built and deployed over a hundred websites products and services in half a dozen languages over the last twenty years for clients or my own business. I subscribe to a litany of aggregators over python, c#, and javascript news and use that information to identify trends to focus on for the practical side. Outside of side projects to gain practice these skills I also use pluralsight, developer conferences, and (less frequently now) books to stay current on this side - which contribute to time against this daily.

On the computer science side I have a large collection of classic books I'm working through and rereading. Everything from the Intro to Algorithms to SICP. I'm currently on my second pass through MIT's 6.006 and 6.851. Much love for Erik Demaine. I own a collection of CS puzzle books including Cracking the Coding Interview and my wife tortures me weekly with dynamic programming puzzles on a whiteboard we have to keep sharp. Similarly, I also tackle LC and HR puzzles on a weekly basis.

On the marketing side I've managed a significant of marketing spend for clients and my own projects through every major marketing platform except facebook. Through this I've developed a skillset around split and multivariate testing. I've also run literally hundreds of marketing experiments to gain experience and understanding. I actively manage paid and organic marketing efforts for an array of projects which provides an additional impetus to stay current. To that end, I subscribe to a number of marketing news aggregators and I'm reading through every major marketing classic I can find. I've had more trouble finding good information on this side compared to other areas.

On the design side I'm currently taking courses through Kadenze and own every a large collection of design classics that I've been reading through. Everything from universal principles of design (strongly recommend) to the design of everyday things. Beyond thoughtful practical application of these skills in hundreds of websites and apps I've also exhibited artwork.

It's a similar story for the remaining areas. Mostly paid courses, conferences, and classic textbooks (I budget about 20k a year for these resources). I also use Anki for remembering important concepts.

I've been at this (reinvesting continuously in all of these areas) for over ten years and averaging 15-20 hours per week of dedicated reinvestment with nearly no breaks for at least the past three years.

Re: Productivity and the Workweek (2000)

#167
post #98

Earlier quoted context omitted.

Yeah, honestly, I think soccer/basketball are better analogies. The team remains in formation. Doing too much is far worse than doing too little, because it pushes everything else out of sync. A big part of the work is sometimes just fixing/improving workflow. There are tests to write, documentation, refactoring, warnings to look at, plugins to update, that wonky button padding to fix, all these little things that ar…

There is a much bigger point here, though, about idle time. Idle time is not just about healing the psyche. It also does that. But you run into problems from not having idle time much sooner than burnout, typically. What is at stake is that the greedy algorithm for optimization does NOT work for complex systems. “I will make every individual person efficient, everyone is always working on something, look how good of…

(also if you want a longer overview a bunch of related concepts are talked about in Dominica DeGrandis’s book Making Work Visible, and the advice on managing by the critical path method comes from a makes-my-eyes-roll-a-little-but-still-pretty-solid business novel by Eli Goldratt called Critical Chain, which applies the reasoning from another less-eye-rolls business novel by the same author to the “project context” that we find ourselves in when writing software.)

Re: Productivity and the Workweek (2000)

#168

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…

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…

Lmao, this is just so absolutely ridiculous. Nobody needs to spend that long outside of work keeping yourself current... it's much more effective to just try to transition your actual work-work to being current and maybe spend a few hours here and there working on something interesting.

If your current job isn't keeping your skills up to date, you need to switch ASAP. But even if it's not and you can't switch... jesus, it doesn't take 20hr/week to learn some new stuff

Re: Productivity and the Workweek (2000)

#169

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.

My first thought when reading your comment was "How could you possibly fit everything there is to learn into 4 hours a day?", but I think the disconnect is in two different conceptions of what a job is - For most people, a job is something where you are hired to do a specific task for a specific wage, using specific skills that you learn once and then apply many times. "Make this button green." "Move the navbar 20px…

I've done both of these types of jobs and I definitely feel different about them.

An example is if you work in any service industry. You don't have to think much, you just do when things need to be done. There's a lot of repetition so you just do without thinking. Or in an office job there's generally a set of tasks that you get done and this very clear path of how to do these things. I do think more time generally leads to more output for these jobs (maybe not in service if we're adding more time into the times of day when there isn't a demand for service, but I think everyone gets the point).

In my last job I worked as a researcher and I'm now in grad school. I feel like for the most part I accomplish way more when I'm not tied to a clock (I still like deadlines and think they are beneficial). But some days are just worthless. Some days 10hrs is nothing and I've forgotten to eat. But most days I'm productive in the morning then do other things mid day, be productive again, hang out with friends, then do research at night. These breaks help me end up getting a lot done. The problem I'm working on is far away (though I'm positive some part of my mind is working on it in the background). But as soon as I'm tied to a clock I feel like I get less done. In those moments where I'm drained I end up just looking busy or do something like browse HN. The thing is that these actions don't allow me to recover, so it's harder to get back to work and be as productive as I was in the morning.

I think that's the trick here. Recovery. In mentally demanding jobs we don't consider rest. It'd be like working heavy duty construction all day every day. It's not sustainable. Or asking pro athletes to train at their max every day. Recovery is an essential part of training and being effective. I think you can train to get more hours of productivity in a day, but as long as we don't actually rest that will never happen because we don't recover.

But idk. Do others feel this way? Often I feel like many don't, but maybe people are just looking busy and we're caught in a feedback loop.

Re: Productivity and the Workweek (2000)

#170
post #43

Earlier quoted context omitted.

Another phenomenon that makes most programmers unable to achieve flow state is technology diversity - brain can get into flow state only when one is using familiar tools - and than happens rarely, at least for me (I work on a project for 6-12 months and ten move to other and tools and main technologies aren't chosen by me usually).

Work on one project for 6-12 months? Sounds wonderful. Try context switching between 7 different application's codebases with different technology stacks / system architecture in a single iteration (well, sometimes just 3 or 4). Our department was eviscerated and software that had dedicated people on them all got put in my lap to maintain and support. I have to reboot in my head how each application works a couple ti…

Yup, maybe 6-12 moths is wonderful comparing to what you have to deal with, but still not enough for me to get into flow. I consider myself average programmer, so in your environment I'd feel like in hell ;)
Post reply on HN