Live data from Hacker News

Some reasons to work on productivity and velocity

danluu.com

11–20 of 183 posts

Re: Some reasons to work on productivity and velocity

#11
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…

productivity is delivering value to your customers

Re: Some reasons to work on productivity and velocity

#12
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…

At the moment for your typical developer in Agile Disney World, productivity is move a ticket from in-progress to done.

Identifying what is high impact, or what’s it’s important to focus on continuously is a form of autonomy that is oddly not offered too much to most of us.

Re: Some reasons to work on productivity and velocity

#13
I think they do matter from the p.o.v. of the people footing the bill for the results. I have yet to work on a product/project where mgt doesn't care about when it gets done and how much it will cost. Call it productivity, call it velocity, but the people paying care and someone always pays.

Re: Some reasons to work on productivity and velocity

#14

If you want to go fast and call that being productive, go fast and be productive. But don't gate-keep and turn personal preferences into "should" and "ought". There's a lot of world out there and not everyone wants to organize their lives around work.

He literally discusses all your points in the first paragraph:

> The top reasons I see people say that productivity doesn't matter (or is actually bad) fall into one of three buckets: 1. Working on the right thing is more important than working quickly 2. Speed at X doesn't matter because you don't spend much time doing X 3. Thinking about productivity is bad and you should "live life"

Here's his argument for your last point:

> The last major argument I see against working on velocity assigns negative moral weight to the idea of thinking about productivity and working on velocity at all. This kind of comment often assigns positive moral weight to various kinds of leisure, such as spending time with friends and family. I find this argument to be backwards. If someone thinks it's important to spend time with friends and family, an easy way to do that is to be more productive at work and spend less time working.

Personally, I deliberately avoid working long hours and I suspect I don't work more than the median person at my company, which is a company where I think work-life balance is pretty good overall. A lot of my productivity gains have gone to leisure and not work. Furthermore, deliberately working on velocity has allowed me to get promoted relatively quickly4, which means that I make more money than I would've made if I didn't get promoted, which gives me more freedom to spend time on things that I value.

Re: Some reasons to work on productivity and velocity

#15
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…

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 could have been solved ahead of time?

Productivity may not have crisp, clear lines. There's always context. But it comes down to: if you can do X in half the time at the same level of quality, you're twice as productive.

I admire Dan Luu's work and this article in particular really resonated with me.

Re: Some reasons to work on productivity and velocity

#16
post #10

If you want to go fast and call that being productive, go fast and be productive. But don't gate-keep and turn personal preferences into "should" and "ought". There's a lot of world out there and not everyone wants to organize their lives around work.

The entire point of TFA is that the ability to go fast is a force multiplier for being productive in the first place.

But to what end?

Re: Some reasons to work on productivity and velocity

#17
> An idea that's become increasingly popular in my extended social circles at major tech companies is that one should avoid doing work and waste as much time as possible, often called "antiwork", which seems like a natural extension of "tryhard" becoming an insult. The reason given is often something like, work mainly enriches upper management at your employer and/or shareholders, who are generally richer than you.

If you really are not comfortable with the consequences of your personal labor you should probably leave your job or not take it in the first place. This sounds like a decadent rationalization for highly compensated people that want to feel moral while being lazy.

Re: Some reasons to work on productivity and velocity

#18
post #10

Earlier quoted context omitted.

The entire point of TFA is that the ability to go fast is a force multiplier for being productive in the first place.

But to what end?

To get your time back while still meeting professional obligations, at least that's my "end" in being productive.

Re: Some reasons to work on productivity and velocity

#19

> An idea that's become increasingly popular in my extended social circles at major tech companies is that one should avoid doing work and waste as much time as possible, often called "antiwork", which seems like a natural extension of "tryhard" becoming an insult. The reason given is often something like, work mainly enriches upper management at your employer and/or shareholders, who are generally richer than you. I…

>you should probably leave your job or not take it in the first place

sounds like a decadent rationalization of some kind.

Re: Some reasons to work on productivity and velocity

#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. Code reviews take longer than you think also.

For me at least coding seems to take less time objectively than subjectively, but it's also quite obvious that most of my time is not spent on coding, sadly. A good chunk of it is completely unproductive bullshit that simply has to happen because that's how the company chooses to operate. I tell them it's not the only way to do things, but they insist on wasting ~1.5 person days a week on "standups" and "scrum" (the team is 12 people, excluding me). They could _easily_ move 50% faster if they shed that bullshit and just gave people sizable tasks and some degree of autonomy and personal responsibility. Instead it's down to who can _appear_ the busiest during standup.

Post reply on HN