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

71–80 of 183 posts

Re: Some reasons to work on productivity and velocity

#71

Post by cuddlecake »

vymague wrote: post #67

I was going to ask how to identify the "hotspots". But I guess, for most people, the mentioned learn how to touch-type fast and editor shortcuts are good enough first steps. And of course there's the obvious improve your programming knowledge and skills. One of the linked HN https://news.ycombinator.com/item?id=22253893 post has an interesting advice. Record yourself when you're coding. Watch them and identify possib…

Recording oneself is also a common strategy for improving musicianship.

When I was drumming, it sometimes helped me see exactly where my movements where improper, hesitant, or superfluous/exaggerated.

When I look over junior developers' shoulders while they code, i kind of do something similar, where I point out small improvements in their "movement from one state of code to another", like IDE functions for refactoring, keyboard shortcuts to delete a line or to go back to the previous editing position.

(I always wonder, when is the right time to introduce someone to vim?)

Re: Some reasons to work on productivity and velocity

#72

Post by vymague »

man_from_space wrote: post #53

OMG, another man with ideas rooted in Taylor's books. Measure everything, be a robot and at the end realize a fact you don't know anything new because you never had 30min slack time during the workweek to think differently

> Taylor's books

What is the book title? This article or the previous Dan Luu's "Some reasons to measure" doesn't seem to mention his name. Googling "Taylor measure" just gave me some pure math textbooks.

Re: Some reasons to work on productivity and velocity

#73

Post by a_e_k »

> I think that part of this is because getting faster at X can actually increase time spent on X due to a sort of virtuous cycle feedback loop of where it makes sense to spend time.

This sounds exactly like an instance of Jevon's paradox: https://en.wikipedia.org/wiki/Jevons_paradox.

Re: Some reasons to work on productivity and velocity

#74

Post by Rapzid »

friedman23 wrote: post #22
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 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.

How much sleep do you get?

Re: Some reasons to work on productivity and velocity

#75

Post by fddhjjj »

auggierose wrote: post #59
Jensson wrote: post #39

Earlier quoted context omitted.

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

Interesting POV. Can you elaborate on an alternative to the way of industry programming? Or more simply, list some of the ways in which industry brand programming is flawed?

Re: Some reasons to work on productivity and velocity

#76

Post by crate_barre »

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…

No one argued against that. We argue that the value proposition is dependent on defeating the other. I prefer not to because, how many others will I race against in life? The indefinite race is unfulfilling. More commonly, we call this the rat race.

I’ve beaten people in the race, and have been beaten myself. My career as a perpetual online matchmaking ranked game is … in so many words, not what I want.

To be forever racing, in age, under duress, or worse, needlessly, villages are not built this way.

Agile pits people against each other in an ultimate form of relativism. The constant question is ‘what did you do yesterday’, every single day. Hey, I did what I could, with the constant retort being ‘oh, but the other did this’, it’s gladiators. Forever stuck in the coliseum. And there will always be the other.

They use the simplest shittiest psychological tactic.

Re: Some reasons to work on productivity and velocity

#77

Post by megameter »

crate_barre wrote: post #76
Jensson wrote: post #39

Earlier quoted context omitted.

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

No one argued against that. We argue that the value proposition is dependent on defeating the other . I prefer not to because, how many others will I race against in life? The indefinite race is unfulfilling. More commonly, we call this the rat race. I’ve beaten people in the race, and have been beaten myself. My career as a perpetual online matchmaking ranked game is … in so many words, not what I want. To be foreve…

I think the rat-race idea got baked deep into SV largely because of the setup of the post-1970 economy, and specifically California's rules: every startup had to be "fast" and "hit the ground running" not just because of literal business pressures, but because implicitly, everyone intends to exit and move on to the next thing immediately, so a slow-moving part-time effort would be a no-go. That derived just from mundane realities about the market, legal and financial environment, and protections afforded towards workers and businesses - everyone knows that we moved in the direction of corporations squeezing the workforce because they "couldn't afford" to build them up. Therefore career mindsets filtered to accommodate only those with the gold rush viewpoint, because the only way to win that game was to strike it rich and retire.

Re: Some reasons to work on productivity and velocity

#78

Post by [deleted] »

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…

[deleted]

Re: Some reasons to work on productivity and velocity

#79

Post by comicjk »

vymague wrote: post #72
man_from_space wrote: post #53

OMG, another man with ideas rooted in Taylor's books. Measure everything, be a robot and at the end realize a fact you don't know anything new because you never had 30min slack time during the workweek to think differently

> Taylor's books What is the book title? This article or the previous Dan Luu's "Some reasons to measure" doesn't seem to mention his name. Googling "Taylor measure" just gave me some pure math textbooks.

https://en.wikipedia.org/wiki/Scientific_management, also known as "Taylorism" after Frederick Winslow Taylor. I don't think Dan Luu is saying anything like this, though.

Re: Some reasons to work on productivity and velocity

#80

Post by crate_barre »

megameter wrote: post #77
crate_barre wrote: post #76

Earlier quoted context omitted.

No one argued against that. We argue that the value proposition is dependent on defeating the other . I prefer not to because, how many others will I race against in life? The indefinite race is unfulfilling. More commonly, we call this the rat race. I’ve beaten people in the race, and have been beaten myself. My career as a perpetual online matchmaking ranked game is … in so many words, not what I want. To be foreve…

I think the rat-race idea got baked deep into SV largely because of the setup of the post-1970 economy, and specifically California's rules: every startup had to be "fast" and "hit the ground running" not just because of literal business pressures, but because implicitly, everyone intends to exit and move on to the next thing immediately, so a slow-moving part-time effort would be a no-go. That derived just from mund…

I’m fascinated by who is downvoting you without an explanation.
Post reply on HN