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

121–130 of 183 posts

Re: Some reasons to work on productivity and velocity

#121

Post by Graffur »

handrous wrote: post #51
agumonkey wrote: post #37

Earlier quoted context omitted.

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

Woah - that really sucks you're in a job that you hate. For your own health you should try something else that you don't hate.

Re: Some reasons to work on productivity and velocity

#122

Post by joshuacc »

graperapist1480 wrote: post #63
minihat wrote: post #30

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

Energy constrained? That’s odd. Just eat more? CICO after all. Maybe guzzle some lard? It’s very dense.

“Mental energy” is a pretty common phrase, and it refers to the ability to start and sustain work on tasks which require mental effort. Eating a candy bar can provide a temporary boost to mental energy, but it’s not an effective everyday approach.

There are many physical and psychological issues which diminish people’s mental energy. ADHD and depression being the most obvious.

Fortunately for many of those conditions there are also ways to increase the amount of mental energy you have available.

Re: Some reasons to work on productivity and velocity

#123

Post by Darkstryder »

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…

Something Dan is not talking about at all but is at the core of my personal productivity troubles is energy level management. There is a world of difference between my average productivity and my peak productivity as I tend to work in short productive bursts then need a lot of time to recharge.

My yearly work output is OKish but my daily or weekly productivity has very high variance, which has caused me some trouble in the past (especially in agile shops where constant productivity is expected).

Personally I haven’t found any magical way to meaningfully improve my average productivity. Every time I think I just found a magic bullet, it usually boils down to working closer to my peak productivity for some time (sometimes without noticing it myself) then realizing I can not sustain that on a full year / full decade / full career.

Before thinking of improving specific skills, just being able to be focused and working without distraction all day every day would be an order-of-magnitude improvement for me.

Re: Some reasons to work on productivity and velocity

#124

Post by heisenbit »

porknubbins wrote: post #68
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…

I wish I could identify a finite set of tasks at which to practice and get much faster. The tradeoff between getting faster at one thing and learning a new thing that could potentially improve my productivity even more is never really clear to me. Someone can have perfected their craft in X and then something better comes along and replaces the whole paradigm.

Your question: There is no finite set. There is no end to it. This is a process. You do it over and over. You don‘t invest into a set and be done with it (and likely over-invested in some). One step at a time. And once in a while reevaluate the territory.

Re: Some reasons to work on productivity and velocity

#125

Post by Jensson »

ZephyrBlu wrote: post #106
Jensson wrote: post #97

Earlier quoted context omitted.

Master the basic building blocks of programming. Frameworks comes and go but the basics are the same. Master as in "I do X correct the first time even without thinking" not "I know how X works". The "do without thinking" is when your subconscious is doing it for you so your conscious doesn't have to. You want to put as much as your work there as possible, it is like putting work on a GPU instead of your CPU, so every…

> To do that you write 10 changes, each about 50 lines and trivial to review since everything is super clean, otherwise you can't get through code reviews fast enough No matter how small or clean the PRs were, I'm pretty sure I couldn't get reviews for 10 in one day.

Maybe the review tooling you use aren't good enough? At google it shows all test runs related to the change, it shows linter information inline in the file diffs, you automatically associate it with tasks it is meant to solve and you write a 100 word description to explain what it is doing and why.

If the change adds tests, has proper naming, solves the issue it says it is solving in a reasonable way, doesn't solve anything it doesn't say it is solving, and none of the tools complains then you just accept it after looking at the tests being reasonable and the code not looking strange. It takes a while to get new engineers where they do this consistently before review, and then review takes time, but once you know how to write changes that are easy to review then reviews are very quick.

Edit: Btw, optimizing the code you write to reduce review time is also another aspect of productivity. It isn't productive to give a lot of extra work to others, so you practice until everything is as obvious as possible. And as people get used to your changes being easy to review it gets even quicker.

Re: Some reasons to work on productivity and velocity

#126

Post by zarkov99 »

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…

Yes, it is a common psychological defense. Rather than suffer the pain of inadequacy one either decries the whole idea of merit as meaningless/harmful or adds enough mushiness to the ranking method as to render it useless. Either way your envy subsides and you can back to living a professional life of un-examined mediocrity.

Re: Some reasons to work on productivity and velocity

#127

Post by [deleted] »

xupybd wrote: post #114

Any tips on how to get faster? I find I'm always trying to learn the new code base or tech it's built on. I hate the hours wasted trying to find out how to do something I already know how to do in another stack. Then there is the time wasted trying to learn git after mercurial and then Docker. As for typing after loads of intentional practice I seem to have plateaued at 60-70wpm. No idea how to get beyond that.

[deleted]

Re: Some reasons to work on productivity and velocity

#128

Post by crispyambulance » 

  > In part of a previous post, I described how long a tiny part of that process took and multiple people objected to that being impossibly fast in internet comments.
I remember that one. I think it was when he said he wrote up something ad-hoc to query one hundred thousand servers for some kind of performance profiling. It struck me as braggadocio. Partly, I guess, because I've _never_ worked in a place that had it's shit together to such an extent where something like that is even possible. And, it really was just too fast to be believable given the context I could imagine.

BUT there was something missing in the back-story and it's apparent in this latest post from danluu. This...

  > I find this a bit funny since I'm not a naturally quick programmer. Learning to program was a real struggle for me and I was pretty slow at it for a long time (and I still am in aspects that I haven't practiced). My "one weird trick" is that I've explicitly worked on speeding up things that I do frequently and most people have not.
He's had the foresight and latitude to be able to PRACTICE. Practice always means trying stuff out, failing, and trying it again and again. Kudos to danluu for putting himself through that and not just going on autopilot down the easy path.

Crucially IMHO, getting to danluu-speed ALSO means enjoying the grace of being able to ask questions and discuss stuff with skilled folks that is completely outside of what's on some project manager's gnatt chart. That's not usually possible in a nose-to-the-grindstone workplace unless you find the right teammates and a protective, encouraging, and tolerant manager.

Re: Some reasons to work on productivity and velocity

#129

Post by ZephyrBlu »

Jensson wrote: post #125
ZephyrBlu wrote: post #106

Earlier quoted context omitted.

> To do that you write 10 changes, each about 50 lines and trivial to review since everything is super clean, otherwise you can't get through code reviews fast enough No matter how small or clean the PRs were, I'm pretty sure I couldn't get reviews for 10 in one day.

Maybe the review tooling you use aren't good enough? At google it shows all test runs related to the change, it shows linter information inline in the file diffs, you automatically associate it with tasks it is meant to solve and you write a 100 word description to explain what it is doing and why. If the change adds tests, has proper naming, solves the issue it says it is solving in a reasonable way, doesn't solve a…

It's less about setting up for the review and more about getting teammates to review the PRs promptly.

I work remotely, so my (Small) team mostly works async even though we're in similar time zones. I doubt trying to ping them for 10 PR reviews in a single day would go well.

Async + people trying to do their own stuff + 10 interruptions is not a great combo. Comments/discussion on a PR can grind things to a halt as well.

I completely agree everything you're saying about making PRs easy to review though. My team already tend to do those things thanks to our manager.

Re: Some reasons to work on productivity and velocity

#130

Post by Jensson »

ZephyrBlu wrote: post #129
Jensson wrote: post #125

Earlier quoted context omitted.

Maybe the review tooling you use aren't good enough? At google it shows all test runs related to the change, it shows linter information inline in the file diffs, you automatically associate it with tasks it is meant to solve and you write a 100 word description to explain what it is doing and why. If the change adds tests, has proper naming, solves the issue it says it is solving in a reasonable way, doesn't solve a…

It's less about setting up for the review and more about getting teammates to review the PRs promptly. I work remotely, so my (Small) team mostly works async even though we're in similar time zones. I doubt trying to ping them for 10 PR reviews in a single day would go well. Async + people trying to do their own stuff + 10 interruptions is not a great combo. Comments/discussion on a PR can grind things to a halt as w…

Could be about incentives then. At Google the code reviews you do are tracked so doing many looks good for your performance reviews, so some people try to be fast with reviews to get more reviews. If you don't get any credit for doing code reviews then I can see it being very hard to get people to do them though.

Also as long as you have a pending review sent to you it shows up as a "you have stuff to do" icon in the google tools until you respond to it, just like if you got a message, I guess that helps as well.

Post reply on HN