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

161–170 of 183 posts

Re: Some reasons to work on productivity and velocity

#161

Post by YZF »

tshaddox wrote: post #57
YZF wrote: post #49

Earlier quoted context omitted.

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

My point is more about the possibility that a big chunk of future cash flow is entirely independent of engineering work, at least for some reasonable bounds for what constitutes "engineering work" (e.g. you could argue that an engineer ought to judge whether their time is better spent cold calling potential clients or finding office space to rent, but those I would call "out of bounds"). Any easy example to illustrat…

That is a good point. I guess for the purpose of this definition we need to make some more assumptions. But decoupling software development from the business completely is going too far the other way.

Re: Some reasons to work on productivity and velocity

#162

Post by andrekandre »

jai_ wrote: post #10
cratermoon wrote: post #7

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.

  > the ability to go fast is a force multiplier for being productive
and what is the force multiplier for being fast?

Re: Some reasons to work on productivity and velocity

#163

Post by tharkun__ »

Jensson wrote: post #132
ZephyrBlu wrote: post #131

Earlier quoted context omitted.

Interesting. We don't track code reviews as far as I'm aware, and we use GitHub so you just get an email if you're tagged as a reviewer. I would say it's not uncommon to have to wait a day for reviews.

The the first thing to do if you want to improve that is to ensure you track code reviews. Meaning, you can see what changes each person reviewed and not just submitted, and then you can use that data to talk about performance etc. If one person does all the reviews then he should get a ton of credit since that is hard important work. Typically lead programmers do more reviews and juniors writes more changes, so a pe…

There's a huge problem with this. The incentive you are describing isn't to do good code reviews. The incentive there is to do a lot of code reviews. Those two are not the same and while they are not mutually exclusive, just by tracking this metric and rating people on it, you are not giving an incentive for good code review. Only for fast review. But you really want both. You want fast and you want good and thorough.

I completely agree that senior and lead people should be doing more reviews and thus help everyone else, ultimately benefiting other programmers and the whole organization overall.

Re: Some reasons to work on productivity and velocity

#165

Post by mrcode007 »

aozgaa wrote: post #164

What methods should be used to measure/track personal productivity and find areas for improvement? The only example I see in the post is a typing test. One comment mentioned a time-tracking app called Harvest.

I think productivity can only only measured towards a goal. Setting different goals will require different metrics and tools for improvement. If your goal is to become for example, a Factorio expert, you can measure your productivity towards this goal by the number of hours spent playing the game. If on the other hand, you are considering becoming a VHDL expert, you could improve your productivity by gaining proficiency in language constructs, syntax rules, and design abstractions so they become second nature and you could do this by copying existing educational designs, attending trainings, reading books.

If yet on on the other third hand, your goal is to maximize your free(idle) time, then you can measure your productivity by rejecting tasks thrown at you and spending less time on hacker news :)

Re: Some reasons to work on productivity and velocity

#166

Post by caffeine »

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.

I’m looking for tips around this too, but a couple things that I have noticed helping me are:

- Extend your competence at least one layer below where you are working. So if you’re using Java, read through the code for the SDK data structures, understand the JVM, etc. If you’re using Rust, learn the Nomicon. If you’re using an asynchronous networking framework, read the Linux man pages for epoll.

- Separate speed runs and quality coding into different passes. Write it once as fast as you can with no concern for quality, error handling, maintainability, etc. Just get the functionality right. Then basically just delete that and write it again using what you’ve learned, and doing it “properly”. That is faster “batch mode” than trying to write it perfectly all at once.

Re: Some reasons to work on productivity and velocity

#167

Post by paleite »

Jensson wrote: post #150
Dudeman112 wrote: post #147

Earlier quoted context omitted.

>The fastest programmers writes quality code I've spent effective years of my life unfucking code written by fast programmers because no one can extend, change or understand their code. As far as I am concerned the probability that a fast programmer also writes quality code is approximately 0. There are outliers out there. But if you tell me someone is a fast programmer I'm not betting they write quality code.

If you tell me a programmer wrote a thing in a month, and another programmer wrote a similar thing in a year, I'd assume the 1 month project is easier to understand and work with. Fast programmers writes most shitty code, yes, but that is because fast programmers writes most code period. I have seen nothing to suggest that an average slow programmer actually produces quality code when given the time, it seems to be t…

If you tell me a programmer wrote a thing in a month, and another programmer wrote a similar thing in a year, I'd assume nothing about either, because there’s too many parameters at play.

If a project took only 1 month, I’d be very cautious with calling it easier to work with, because it likely means fewer tests (leading to lower velocity long-term) and fewer hours spent by other developers trying to understand it, and giving feedback on how to improve legibility.

Creating something quickly can be really important in specific contexts, but actually KEEPING something flexible to work with, hard to break, and easy to understand is more important when dealing with software that’s supposed to last over many developers and a long period of time.

Maintaining velocity requires you to spend more time on keeping the code base healthy.

I find the notion of being a fast programmer irrelevant in a business-context. Because there I think it’s more valuable to be a programmer that can ensure business goals are met on time, ensuring the correct problems are solved, ensuring contracts aren’t broken, while still keeping the code base professional (i.e. well-tested, clean, consistent).

Being a fast programmer is great and all, but being reliable is the more favorable trait if I had to pick one. Both require huge amounts of active training.

Re: Some reasons to work on productivity and velocity

#168

Post by saeranv »

necovek wrote: post #87
saeranv wrote: post #14

Earlier quoted context omitted.

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

While Dan Luu's post resonates with me to an extent, I think you are missing the GP's point. In practice, if you improve your productivity at work, it's going to be mostly for your employer's benefit (other than bragging rights and some personal satisfaction). Gaining time back is not always possible, and that is the core desire for most people (as your OP quote suggests you could do): incentive to improve significan…

> In practice, if you improve your productivity at work, it's going to be mostly for your employer's benefit (other than bragging rights and some personal satisfaction).

This is true if you're bagging groceries, but certainly not true for most software developers. To quote the post again:

"I'm sympathetic to the argument and agree that upper management and shareholders capture most of the value from work. But as much as I sympathize with the idea of deliberately being unproductive to "stick it to the man", I value spending my time on things that I want enough that I'd rather get my work done quickly so I can do things I enjoy more than work. Additionally, having been productive in the past has given me good options for jobs, so I have work that I enjoy a lot more than my acquaintances in tech who have embraced the "antiwork" movement."

> But GP is making a point that it should be perfectly acceptable to not want to (significantly) improve at work while meeting the bar for staying employed.

I don't see any point in Dan's post against this idea... it's the GP who is elevating this into a moral choice, i.e. from his/her response to mine:

> Yeah but he doesn't recognize that his entire argument is personal choice elevated to moral imperative.

Re: Some reasons to work on productivity and velocity

#169

Post by CGamesPlay »

ptr wrote: post #104

Does anybody know if there’s a Mac app that randomly pops up a “what are you currently working on?” dialog? No automatic stuff like trying to find out using the foreground application and no explicit starting and stopping of activities, just simple sampling?

You can get "randomized alarm clock" apps and websites which would enable you to ask this to yourself in an automated fashion.

Re: Some reasons to work on productivity and velocity

#170

Post by novok »

Jensson wrote: post #97
porknubbins wrote: post #68

Earlier quoted context omitted.

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.

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…

What are the 'chunks' of competitive programming? Like knowing how to make a graph, use hash tables / arrays well, a typical dynamic programming solution and so on?
Post reply on HN