[HN Gopher] Productivity and Velocity
___________________________________________________________________
Productivity and Velocity
Author : davidmckenna
Score : 78 points
Date : 2021-10-15 19:28 UTC (3 hours ago)
(HTM) web link (danluu.com)
(TXT) w3m dump (danluu.com)
| minihat wrote:
| The actionable advice in this post: 1) Track where you spend your
| time 2) Apply deliberate practice to improve where you are
| weak/slow
|
| I am typically energy constrained rather than time constrained,
| as I imagine is the case for many working in engineering/science.
| Yet, the author's advice remains useful. Deliberate practice
| should provide gains to both time and energy costs of tasks.
|
| For me most productivity advice, including this post, ultimately
| reduces to "try to get better at your trade, and track your
| progress".
| Jensson wrote:
| > I am typically energy constrained rather than time
| constrained, as I imagine is the case for many working in
| engineering/science.
|
| I've found that being energy constrained is much easier to
| track than time constrained. You notice instantly when a task
| takes a ton of your energy, you start hating the task so you
| work hard to ensure you don't have to do the task any more.
| Compare that to someone who mostly wastes time, they'd happily
| sit and waste tons of time every day since you don't really
| feel your time slip away.
| hardwaregeek wrote:
| 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 proposing is a
| much more concrete, much more grounded sense of productivity.
| It's the difference between trying to get an overworked line cook
| to fulfill the job of 3 regular workers and watching a master
| chef work with no extra movements, no wasted energy.
|
| I'm sympathetic to the analogy of practice. 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. Of course they aren't obligated to do so, but it's
| a useful mindset to see weaknesses as potential places of
| improvement instead of permanent failings. It's also true that if
| you're racing against someone who doesn't see it as a race,
| you'll win. Granted they probably won't care, but sometimes
| people get to the end, realize they did care about the race, and
| were just never clued into the fact that it was a race.
| Jensson wrote:
| > 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 many here takes on becoming faster at
| programming. They actually argue that practicing being fast
| will actually make you worse at your job! Such people will
| never improve, they are stuck where they are forever.
| jdlshore wrote:
| 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 admire is good at, call that
| "productivity," and then come up with a post-hoc rationalization
| of why that's good.
|
| Note: I only skimmed the article, so consider this a comment on
| productivity discussions in general rather than the specific
| article.
|
| (Oh, and a pet peeve: the agile concept of "velocity" originally
| introduced by Extreme Programming is absolutely not a measure of
| productivity. It's a way of predicting your capacity for the next
| iteration. I've taken to calling it "capacity" instead of
| velocity for that reason.)
| es7 wrote:
| 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.
| jeffbee wrote:
| 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.
| Jensson wrote:
| The thinking pattern "I don't want to get faster, I prefer
| writing quality code" is a false dichotomy. The fastest
| programmers writes quality code, since quality code is much
| easier to get right and working with which are the most
| important factors for being a fast coder.
| jeffbee wrote:
| I agree there's not a natural tension between quality and
| speed, but the speed part is really hard to measure. You
| _must_ consider the time of all future readers and
| maintainers of the code you are writing. Spending time to
| write a test or comment today is an investment that pays
| back in future fast iteration. Saving time by skipping
| code review, dashing off weird and confusing interfaces
| or variable names without revisiting them in a second
| pass, that type of thing is the opposite: it can appear
| to save you time today, but is costing you future time.
| Jensson wrote:
| > Saving time by skipping code review, dashing off weird
| and confusing interfaces or variable names without
| revisiting them in a second pass, that type of thing is
| the opposite
|
| Nobody here is saying you should do this, it is a
| strawman. Rather being fast means that you can revisit
| your interfaces 10 times rather than 2 times, spend more
| time thinking about your names, have more time to write
| tests, review everything several times before code review
| so no issues are found etc, ultimately producing much
| higher quality code.
|
| It seems like you think this article is about "I write
| code quickly by not doing things properly", rather than
| "I practice to become faster".
| jeffbee wrote:
| I have no disagreements with the article at all. I only
| disagree with the idea that "doesn't understand the
| language/codebase/requirements" can only cause slowness.
| That condition is at least equally likely to cause the
| fast solution.
|
| The real "10x programmers" I have known spend practically
| all of their time deleting and refactoring code. A
| handful of fake 10x'ers I have met in my career, who
| enjoyed a reputation of rapidly dashing off MVPs, were
| stone-cold idiots, one of whom wrecked an entire company
| with his 10x-ness.
| handrous wrote:
| This is _sometimes_ true. On a project long-term, will
| you keep velocity up by writing quality code? Yes. In
| certain, narrow areas (very "mathy" code, perhaps, that
| doesn't interact much with he world) might you go faster
| by writing quality code from the beginning? Maybe.
|
| However, can one also go _much_ faster by: not writing
| tests one ought to have written; ignoring security
| issues; ignoring input edge-cases; ignoring output edge-
| cases; treating a variety of variables as constant, or as
| having bounds that they actually do not; not writing
| enough documentation; et c.? Oh my god, yes. Of course.
|
| Anyone who's ever seen a "we're really happy with the
| output of our outsourced team on this Rails 'app',
| they've gotten this MVP ready so fast!" codebase knows
| that's _definitely_ also a way to be fast, and that a
| team writing actual quality code and not putting in a
| _ton_ more hours couldn 't have matched that team's
| "productivity", because they'd have been doing _way more
| work_.
| Jensson wrote:
| That has to do with managers being bad at telling how
| productive a team is, it is a completely different
| problem.
| karmakaze wrote:
| 10x engineer: one that produces 10x the solutions, or creates
| 1/10th the problems, or a mix of the two--over a long enough
| time span to include second-order effects.
|
| The weak version of the term is one that enables the team to
| produce 10x, or ..., which I personally don't go for, it's
| watering down a difference in abilities which acknowledging
| makes people uncomfortable. I would call them sqrt(10)-x
| engineers who do 3x and let the team do 3x.
| friedman23 wrote:
| 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.
| agumonkey wrote:
| 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.
| handrous wrote:
| 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.
| gliese1337 wrote:
| Somehow, this never really clicked for me before.
|
| Mind blown.
|
| Thanks!
| YZF wrote:
| I'm gonna try. Productivity is the discounted future cash flow
| per hour of work.
|
| Here's what it's not: It's not about how much code you write.
| It's not about the quality of the code. It's not about clever
| engineering solutions. All these can (and should) be part of
| the above, or they may not. Sometimes sucky code that can bring
| in a billion dollars is better than great code that brings in
| nothing. Technical debt is fine as long as the "interest" on
| that debt is << the profit you made by taking on that debt.
| Just like any other debt.
|
| A business pays you $X an hour, what are they getting out of
| you $-wise?
|
| To be clear, that doesn't mean that e.g. someone working on
| internal tooling can't be productive, but their productivity is
| measured by the impact on someone else who eventually uses the
| tooling to make money somehow.
|
| This is incredibly difficult/impossible to measure perfectly,
| certainly on an individual level, but I still think it's
| worthwhile to look at it like this...
|
| EDIT: I totally agree with the spirit of "sharpen your axe" and
| "be good at what you do". I spent a lot of time as a teenager
| learning to type fast. I did coding competitions to learn how
| to code _real_ fast. This is part of what being a craftsman is
| about. But the leverage there is really limited. I liked what
| one of my ex-CEOs used to say, that just because he types fast
| doesn 't mean he should do his secretary's work. So after you
| know what you're doing, you have the right approach, you're the
| right person to do this, all the other business factors, you
| should definitely excel at doing it.
| tshaddox wrote:
| > 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
| delivery apps (at least those above some reasonable baseline
| of engineering competence) had very similar engineering going
| on in the early days, yet most of them you barely remember
| while a very small number of them are unicorns. But could you
| really have looked at an engineer in the early days and
| picked out the difference?
| YZF wrote:
| 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 business /economic context is very
| important, and often ignored. Without it it's very hard to
| say because in a different context the engineer that
| creates the very same hack maybe just cost the company a
| lot of $'s in future maintenance work.
| foolfoolz wrote:
| productivity is delivering value to your customers
| crate_barre wrote:
| 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.
| 21eleven wrote:
| > _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.
| mental1896 wrote:
| >you should probably leave your job or not take it in the first
| place
|
| sounds like a decadent rationalization of some kind.
| joe_the_user wrote:
| _If you really are not comfortable with the consequences your
| personal labor you should probably leave your job or not take
| it in the first place._
|
| Oh really? I don't think you're going to get anything like sort
| of "ethical" behavior until there's something like UBI
| implemented. Until then, people are going to hold onto high
| paid jobs they don't like, especially if they can slack off at
| them.
| Afforess wrote:
| > _If you really are not comfortable with the consequences 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._
|
| Three words that trap many: Employer Provided Healthcare.
| m0zg wrote:
| 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.
| woah wrote:
| This is incredibly similar (but not verbatim) to another blog
| post on the front page right now. Did one of these bloggers
| drastically improve their blogging velocity by rewriting a post?
| [deleted]
| hyperpape wrote:
| At the bottom of this post, Dan thanks Jamie (the author of the
| other post). Dan's been posting about the topic on Twitter as
| well. So basically they talked about it and both wrote up their
| takes.
| renewiltord wrote:
| My first thought was that people were linking related stuff.
| But the two posts were written within a day of each other.
| Perhaps one was inspired by the other or perhaps the authors
| know each other.
|
| Dan Luu is a pretty prolific blogger / tweeter about
| engineering and this one is the later blogpost. I find it
| unlikely it was a "repurpose".
| dochtman wrote:
| Both bloggers know each other (this is pretty obvious if you
| read some of their online stuff), so Dan Luu probably
| reviewed the other post early and thought it interesting
| enough to add his own take.
| meowface wrote:
| (The post, for anyone curious:
| https://news.ycombinator.com/item?id=28879240)
|
| Yeah, it's very similar in a lot of ways.
| cratermoon wrote:
| 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.
| saeranv wrote:
| 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.
| cratermoon wrote:
| Yeah but he doesn't recognize that his entire argument is
| personal choice elevated to moral imperative.
|
| > an easy way to do that is to be more productive at work and
| spend less time working
|
| Why is need to be more productive at work framed as a
| prerequisite to spending less time working? Just spend less
| time working. His moral stance, which he never reflects on,
| is that working is good, and relaxing is predicating on
| completing the work first. None of that is necessarily true,
| but it does fit well with the Protestant Work Ethic, which
| is, of course, a moral framework for putting work before
| leisure.
| Jensson wrote:
| You will get fired if you don't get enough done at work.
| Higher productivity means you can accomplish enough tasks
| to not get fired in less amount of time.
| cratermoon wrote:
| But that's just taking the moral argument another level
| deeper. Why should a person's leisure be subject to the
| whims of employment?
|
| > you can accomplish enough tasks to not get fired in
| less amount of time.
|
| And how many employers will look at the work you got done
| in less time and tell you to go home for the rest of the
| week because you've finished everything assigned?
| Jensson wrote:
| > But that's just taking the moral argument another level
| deeper. Why should a person's leisure be subject to the
| whims of employment?
|
| This isn't a philosophical discussion, fact is that
| either you produce enough value at work or you get fired.
|
| > And how many employers will look at the work you got
| done in less time and tell you to go home for the rest of
| the week because you've finished everything assigned?
|
| You don't have to tell them you are done, you can just
| relax and browse HN or whatever. Being very productive at
| work gives you a lot more freedom at work, even if that
| freedom isn't 100% fairly allocated to you it still
| improves your situation.
| jai_ wrote:
| The entire point of TFA is that the ability to go fast is a
| force multiplier for being productive in the first place.
| cratermoon wrote:
| But to what end?
| Jtsummers wrote:
| To get your time back while still meeting professional
| obligations, at least that's my "end" in being productive.
| cratermoon wrote:
| > while still meeting professional obligations
|
| The unstated and unexamined assumption here is that
| professional obligations trump leisure and enjoyment. Do
| they? If so, why?
| f00zz wrote:
| Do you have a trust fund?
| Jtsummers wrote:
| I mean, you could choose a different employer with lower
| expectations or reduced obligations if that's an option
| where you live. But no employer is required to keep you
| employed if you don't get your work done. It may be
| harder to fire people in some places and in some
| industries, but it's rarely impossible. If you want to be
| able to have leisure and enjoyment, you probably need
| money, which means being employed, and to remain employed
| you need to meet your obligations.
|
| So be unproductive and risk getting fired but go home at
| a reasonable time. Be unproductive and work long hours to
| meet the obligations and not get your leisure and
| enjoyment. Or be efficient and go home at a reasonable
| hour and have your leisure and enjoyment. I choose the
| third, because it's sensible. Unlike my 90-hour workweek
| colleagues who stress about everything.
| orangecat wrote:
| Presumably you're working on something that is intended to
| benefit somebody.
| vasco wrote:
| Working on the right thing means driving in the right direction.
| Velocity is the speed at which you get there. Anyone that says
| velocity doesn't matter is wrong and there should be no debate.
| somishere wrote:
| That's debatable. Seriously tho your comment reminded me of one
| of my favourite TV ads for road safety from a few years ago
| https://youtu.be/HrWKXO1qwPM
| rlewkov wrote:
| 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.
___________________________________________________________________
(page generated 2021-10-15 23:00 UTC)