Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some reasons to work on productivity and velocity

danluu.com

Post reply on HN
Print view View original

51–60 of 183 posts

Re: Some reasons to work on productivity and velocity

#51

Post by handrous »

agumonkey wrote: post #37
friedman23 wrote: post #22

Earlier quoted context omitted.

I used to be amazed wondering how people claimed to work 12 hours a day until I realized they consider writing emails and talking to people on the phone work (which it is). But of course me being a software engineer I imagined for some reason when they said work they meant something like coding which after 6 hours has me drained.

after doing a few kinds of jobs: - food retail: producing hundreds of sandwiches an serving hundreds of customers back to back, teaches you about productivity - landwork: 8000 picks per day teaches you about work maybe i'm masochistic, but whenever I see people relaxed at work, neither doing much nor thinking much, I consider it's not work. There's no difference between what they do and me at home chilling.

I've done tough physical labor, and repetitive physical labor. They may wear out the body (or may invigorate it, depending on the load), but the mind is fresh even after 8+ hours, in my experience. And it feels good.

After six hours of typey-typey in front of a screen I feel used up. Worthless. Dead. And that's a very good day—four is more typical for "how long can I do computer work before I just want to curl up and do nothing until I fall asleep?". I mean four hours of actually working, mind you, not screwing around, but still.

I know for a fact I don't have a general work ethic problem that prevents me from going past 4-6 hours of computer work in a day—I have a "this particular shit—computer shit—sucks the life out of me like nothing else" problem. Always been that way, even when I was young. Work? I'll do it 'till I drop and feel good about it. Computer work? Uuuuugh, if I have to, I guess, but I'll hate it the whole time and feel like shit when I'm done, which, BTW, won't take long.

But, anything I could do that wouldn't involve sitting in front of a computer much of the day would mean a 60+% pay cut, so... here I am.

Re: Some reasons to work on productivity and velocity

#52

Post by spaetzleesser »

m0zg wrote: post #20

As someone who also tracks time in some amount of detail (to bill clients for it), communication, and _written_ communication in particular takes a surprising amount of time. All those Slack threads you might not even think twice of engaging in can easily destroy half your working day, even if you ignore the cost of context switching. Emails take longer than you think. Design docs take _much_ longer than you think. C…

"Design docs take _much_ longer than you think. Code reviews take longer than you think also."

I work in medical devices and this is so true.

A thorough design doc or a thorough code review takes a very long time. It actually may take as much or more time as the actual coding. Somehow we never account for this time in planning so either things are rushed or the project will be delayed significantly. Add to that the fact we don't have good tools either for writing docs neither or for code reviews.

Re: Some reasons to work on productivity and velocity

#54

Post by m0zg »

spaetzleesser wrote: post #52
m0zg wrote: post #20

As someone who also tracks time in some amount of detail (to bill clients for it), communication, and _written_ communication in particular takes a surprising amount of time. All those Slack threads you might not even think twice of engaging in can easily destroy half your working day, even if you ignore the cost of context switching. Emails take longer than you think. Design docs take _much_ longer than you think. C…

"Design docs take _much_ longer than you think. Code reviews take longer than you think also." I work in medical devices and this is so true. A thorough design doc or a thorough code review takes a very long time. It actually may take as much or more time as the actual coding. Somehow we never account for this time in planning so either things are rushed or the project will be delayed significantly. Add to that the f…

Try actually tracking the time using a free service like Harvest. You'll be surprised just how much longer some things take objectively than subjectively. I'm not saying do retrospectives every week or whatever, but do at least a few, then take note of time sinks and weigh their utility against the time they take. I don't think one can build awareness of this without measurement, something the essay also alludes to.

Re: Some reasons to work on productivity and velocity

#56

Post by ltbarcly3 »

jdlshore wrote: post #8

The problem I have with discussions about “productivity” (including 10x engineer chest-beating) is that no one ever defines what they mean by the word. Is it lots of lines of code? Is it clean design and architecture that’s easy to maintain and extend? Responding quickly to business needs? Making a lot of money in a short time? Too often, people arbitrarily choose what they’re good at, or what someone else they admir…

Note: I only skimmed your comment, so consider this about something else.

Programmers protest too much about 10x programmers. Saying there isn't a 10x programmer is the same as saying nobody could possibly work hard and improve enough to be that much better at something. But we know that every single activity we can objectively measure has far more than a 10x variation in performance. Why is there someone 10x better than average at assembling Ikea furniture, or shooting a bow and arrow, or juggling, or running, or even eating, but programmers are interchangeable cogs? Its a totally bizarre thing to even consider without very strong evidence, and that evidence doesn't exist. Seems like sour grapes to me.

Re: Some reasons to work on productivity and velocity

#57

Post by tshaddox »

YZF wrote: post #49
tshaddox wrote: post #45

Earlier quoted context omitted.

> Productivity is the discounted future cash flow per hour of work. That's not an unreasonable proposal, but isn't the whole point of startups that we're playing with upsides that are extremely huge and extremely unlikely? It seems like it would be extremely difficult to apply this definition to an engineer or a very small engineering team at an early-stage startup. Surely all the functionally equivalent restaurant d…

For sure. In that context, the engineer that got the product to work before the startup ran out of money and shut down by deciding to hack around some issues rather than "do it properly" is the more productive engineer. Another way to think about this is the engineer that better optimizes the expected present value (sure, there might be a pretty wide distribution of outcomes). At the very least I feel like this busin…

My point is more about the possibility that a big chunk of future cash flow is entirely independent of engineering work, at least for some reasonable bounds for what constitutes "engineering work" (e.g. you could argue that an engineer ought to judge whether their time is better spent cold calling potential clients or finding office space to rent, but those I would call "out of bounds"). Any easy example to illustrate this would be two engineers who each develop a functionally identical app for two different startups, but at one startup the founder later embezzles company funds, gets arrested, and the whole company falls apart, while the other company goes on to be successful. Was one engineer really more productive than the other in any meaningful sense?

Re: Some reasons to work on productivity and velocity

#58

Post by cratermoon »

f00zz wrote: post #26
cratermoon wrote: post #23

Earlier quoted context omitted.

> while still meeting professional obligations The unstated and unexamined assumption here is that professional obligations trump leisure and enjoyment. Do they? If so, why?

Do you have a trust fund?

No, and you raise a good point. Someone with a trust fund or other form of inherited wealth, or just with sufficient passive income, doesn't need to be productive. That person can claim as much leisure time as they want, when they want. So the argument the author of the post makes, that productivity is a necessary precondition for leisure, is really not true at all. In our society we may find that money and income are preconditions, but there's nothing inherent about the need for productivity to have those.

Re: Some reasons to work on productivity and velocity

#59

Post by auggierose »

Jensson wrote: post #39
hardwaregeek wrote: post #31

I suspect the dissenters and Dan are not as far apart as one would expect. What I see in the dissent is a rejection of the specific brand of Silicon Valley rah rah productivity cult. There's a lot of mysticism in SV style productivity, whether it's the new hottest app or the latest lifestyle craze. It's also almost always directed at squeezing more work out of someone who's already working far too much. What Dan's pr…

> Too many people are extremely static in their assessment of their skills. They make overarching claims like "oh I'm just not good at cooking" or "I just can't type very fast", when they can remedy these issues with practice. The people with the biggest blockers are those who argue along the lines of "learning skill X isn't even important, no learning skill X actually makes you worse!". That is the perspective so ma…

There is only a limited amount of time in life. It matters on what you spend it. Given that the way programming in industry is done is generally fucked up, working super hard at becoming super fast at doing that brand of programming can be a waste of time. Of course that depends on what your goals are.

Re: Some reasons to work on productivity and velocity

#60

Post by alfiedotwtf »

jeffbee wrote: post #35
es7 wrote: post #15

Earlier quoted context omitted.

Productivity: If you need an X, how quickly can you implement an X at a high level of quality? If your product manager asks for a new widget or api, can you implement it without any major bugs in 1 hour? Or will you take three days because you don't understand your programming language, your codebase and your requirements? Will the widget/api be free of major bugs, or will it fail on a variety of edge cases that coul…

Eh, there are two archetypes in this industry: One who pounds out the solution in an hour, is not smart enough to perceive its flaws. One who takes three days because they understand their language, codebase, and requirements.

... and with these architypes, the definition of a 10x-er would be - One who pounds out the solution in an hour because they understand their language, codebase, and requirements.
Post reply on HN