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

41–50 of 183 posts

Re: Some reasons to work on productivity and velocity

#41

Post by YZF »

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…

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 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.

Re: Some reasons to work on productivity and velocity

#42

Post by handrous »

Jensson wrote: post #38
jeffbee wrote: post #35

Earlier quoted context omitted.

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.

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.

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.

Re: Some reasons to work on productivity and velocity

#43

Post by Jensson »

jeffbee wrote: post #40
Jensson wrote: post #38

Earlier quoted context omitted.

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.

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 revi…

> 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".

Re: Some reasons to work on productivity and velocity

#45

Post by tshaddox »

YZF wrote: post #41
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…

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 f…

> 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?

Re: Some reasons to work on productivity and velocity

#46

Post by orangecat »

cratermoon wrote: post #16
jai_ wrote: 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?

Presumably you're working on something that is intended to benefit somebody.

Re: Some reasons to work on productivity and velocity

#47

Post by Jensson »

handrous wrote: post #42
Jensson wrote: post #38

Earlier quoted context omitted.

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.

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 o…

That has to do with managers being bad at telling how productive a team is, it is a completely different problem.

Re: Some reasons to work on productivity and velocity

#48

Post by jeffbee »

Jensson wrote: post #43
jeffbee wrote: post #40

Earlier quoted context omitted.

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 revi…

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

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.

Re: Some reasons to work on productivity and velocity

#49

Post by YZF »

tshaddox wrote: post #45
YZF wrote: post #41

Earlier quoted context omitted.

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 f…

> 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 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.

Re: Some reasons to work on productivity and velocity

#50

Post by somishere »

vasco wrote: post #44

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.

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
Post reply on HN