17 ms·

Some reasons to work on productivity and velocity

326 points by davidmckenna 5y ago

rlewkov 5y ago
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.
- crate_barre 5y ago
  But do they really care? Some of us work in processes and workflows that would alarm others. Imagine you say ‘I care about my son’s education’, yet everyday you watch this child have to sharpen their pencil with a razor, and walk blocks to a Starbucks to get free internet for research. You can solve it or look into, but you don’t. You could even say ‘I get how hard this is for you’, but instead you call the person lazy. We grow fatigued. That’s many of our shitty codebases and Agile workflows that besiege one’s cognitive capacity. Couple that with a constant ‘what have you done for me lately’ expectation, and you have a recipe for apathy. Subconsciously, the kid will internalize that and it’ll show. Your failure as this analogous business father is that at the every end, you blame the kid for not doing enough.
xupybd 5y ago
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 5y ago
  [deleted]
- andrekandre 5y ago
  > Any tips on how to get faster? quality take the time to write quality code, design quality systems, debug things the right way, don't rush, take your time before you know it, writing good code (and systems) becomes second nature and you will get faster as a result in other words, fast people/teams know how to be fast because high quality is second nature and they don't waste their time fixing bugs and retesting again and again
- caffeine 5y ago
  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.
woah 5y ago
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?
- renewiltord 5y ago
  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 5y ago
    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.
    - renewiltord 5y ago
      Yeah that makes sense. Sounded like the most likely explanation honestly.
- meowface 5y ago
  (The post, for anyone curious: https://news.ycombinator.com/item?id=28879240 https://news.ycombinator.com/item?id=28879240) Yeah, it's very similar in a lot of ways.
- hyperpape 5y ago
  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.
- deleted 5y ago
  [deleted]
cratermoon 5y ago
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.
- jai_ 5y ago
  The entire point of TFA is that the ability to go fast is a force multiplier for being productive in the first place.
  - cratermoon 5y ago
    But to what end?
    - Jtsummers 5y ago
      To get your time back while still meeting professional obligations, at least that's my "end" in being productive.
      - cratermoon 5y ago
        > 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 5y ago
        Do you have a trust fund?
        cratermoon 5y ago
        No, and you raise a good point. Someone with a trust fund or other form of inherited wealth, or just with sufficient passive income, doesn't need to be productive. That person can claim as much leisure time as they want, when they want. So the argument the author of the post makes, that productivity is a necessary precondition for leisure, is really not true at all. In our society we may find that money and income are preconditions, but there's nothing inherent about the need for productivity to have those.
jdlshore 5y ago
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.)
- Graffur 5y ago
  It's measured by tweeting, github social actions and giving talks at conferences
- karmakaze 5y ago
  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.
- foolfoolz 5y ago
  productivity is delivering value to your customers
- crate_barre 5y ago
  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 5y ago
> 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.
- Afforess 5y ago
  > 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.
- mental1896 5y ago
  >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 5y ago
  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.
  - sureglymop 5y ago
    That's true. Besides, what ethics are there in capitalism? Just thinking about it, how can someone who works and lives paycheck to paycheck ever afford to make ethical and moral decisions in or about their work? They can't afford that because they need whatever payment they can scramble together to survive. And so naturally, one must be at a very privileged position to be comfortable with the consequences of ones personal labor.
m0zg 5y ago
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.
- spaetzleesser 5y ago
  "Design docs take _much_ longer than you think. Code reviews take longer than you think also." I work in medical devices and this is so true. A thorough design doc or a thorough code review takes a very long time. It actually may take as much or more time as the actual coding. Somehow we never account for this time in planning so either things are rushed or the project will be delayed significantly. Add to that the fact we don't have good tools either for writing docs neither or for code reviews.
  - m0zg 5y ago
    Try actually tracking the time using a free service like Harvest. You'll be surprised just how much longer some things take objectively than subjectively. I'm not saying do retrospectives every week or whatever, but do at least a few, then take note of time sinks and weigh their utility against the time they take. I don't think one can build awareness of this without measurement, something the essay also alludes to.
    - 5y ago
minihat 5y ago
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 5y ago
  > 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.
- graperapist1480 5y ago
  Energy constrained? That’s odd. Just eat more? CICO after all. Maybe guzzle some lard? It’s very dense.
  - agent327 5y ago
    "Energy constrained" doesn't mean he lacks sugar, it means his brain isn't letting him do the work anymore because it is in the process of burning out.
    - minihat 5y ago
      Yes, this is my intended meaning. I am a PhD student working on my thesis. After a certain number of hours of doing mathematics or algorithm design, I have to switch to easier tasks like reading papers in a domain I'm familiar with, or documenting code. While I cannot speak for anyone but myself, my performance on highly challenging tasks is capped at 4-5 hours per day. At that point, it is better for me to switch to lower hanging fruit. If I am feeling especially inspired, sometimes I'll put in a 12+ hour day of hard work. Rarely, even two or more in a row. But inevitably, I will feel extra burned out in the subsequent days.
hardwaregeek 5y ago
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 5y ago
  > 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.
  - auggierose 5y ago
    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.
vasco 5y ago
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 5y ago
  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 https://youtu.be/HrWKXO1qwPM
- jmchuster 5y ago
  velocity = speed + direction If you are able to achieve speed that is 2x, then as long as your angle is less than 60 degrees off axis from the theoretical perfect direction, you're making progress towards the goal faster than everyone else. Though I wouldn't be surprised to find out that your error is not nearly that high, and given your high amount of practice/experience, you might even end up with the least amount of angular error amongst your peers.
man_from_space 5y ago
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
- vymague 5y ago
  > 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.
  - comicjk 5y ago
    https://en.wikipedia.org/wiki/Scientific_management 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.
- samth 5y ago
  Dan Luu is definitely not someone who never learns anything new or who doesn't think differently.
- jodrellblank 5y ago
  An inaccurate criticism which is addressed in the article: "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 quickly, 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."
raglof 5y ago
iwouldsayiagree
vymague 5y ago
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 https://news.ycombinator.com/item?id=22253893 post has an interesting advice. Record yourself when you're coding. Watch them and identify possible improvements. Reminds me of James Woods' lawyer character in the TV show Shark. He did the same thing.
- cuddlecake 5y ago
  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?)
  - sureglymop 5y ago
    That honestly sounds exhausting.. like, just thinking about it, what if they have set their own keyboard shortcuts? I feel like ones "workstation" or "setup" is always too individual (and that's good). Who are you to know that they don't know about a certain editor feature and just don't like to use that in their workflow? And why does one even need to know vim at this point in time? Don't get me wrong, i know and use vim daily but does it differentiate me in any way from someone who uses nano or micro or whatever editor they have in their workflow? Not at all.
    - chousuke 5y ago
      What does it hurt to tell someone about a feature they could be using, especially if you're mentoring? If they don't want to, they'll tell you and that's fine, but they need to be aware of it in the first place to make that choice, and the assumption that other people know the same things as you is often wrong.
TeeMassive 5y ago
Press F9 to toggle reader view.
a_e_k 5y ago
> 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 https://en.wikipedia.org/wiki/Jevons_paradox.
ChrisMarshallNY 5y ago
I dunno. I just code every day (like, seven days a week). Seems to help me work fairly quickly, and fairly well. I write good code, quickly. I’m not at all interested in comparing myself to, or competing with, anyone else. I can get the job done to my satisfaction, and in a timeframe the I consider acceptable.
DeathArrow 5y ago
I think that being fast at coding is akin of being fast working on an assembly line. This might matter a bit, however I don't strive to do that. If it comes naturally with experience good, if not, I don't make a goal from it. Churning out code is something that bores me. I'm interested more in problem solving, computer science part of programming, optimizations, research, discovery, architecture. I am not interested so much in how I do this common thing fast, but rather in how I solve this hard or interesting problem. If a problem is already solved, can I find a better solution? How fast the code will run? How robust it will be?
- crate_barre 5y ago
  I’d also add that it’s something many of us no longer need to prove to ourselves. When you are new, you have to at least prove to yourself once that you can be this ‘machine’. Once you’ve proven it, how is that a goal anymore? I’m not interested in that anymore either. There are more optimal ways to being this machine than just slamming one’s head against a keyboard, the proverbial work smarter, not harder.
lngnmn2 5y ago
This is great example of virtue-signalling and rationalizations. No, typing speed is irrelevant related to content quality. Think of poetry - it is all about finding the right word rather than committing them into writing. He just plainly typing too much - a thick book fallacy. Truth does not require lots of verbiage, on the contrary, it requires a short, clean, precise, adequate "just right" formulation. That piece of text in in the link could be reduced 10x without losing anything meaningful (which is very sparse indeed).
ptr 5y ago
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?
- CGamesPlay 5y ago
  You can get "randomized alarm clock" apps and websites which would enable you to ask this to yourself in an automated fashion.
- maxjmartin 5y ago
  Sounds like tagtime https://github.com/tagtime/TagTime https://github.com/tagtime/TagTime
bullen 5y ago
This is doing wonders for my procrastination! But I agree that if you find out that you have been working on the only problem worth solving for 10 years you should be able to take a break because the likelyhood that anyone else is able to run past you is very small. (they would have needed to start before you without you finding out for 10 years because hard problems are not solved faster in a group)
_vvhw 5y ago
At least one way to increase velocity is to design software such that you can radically accelerate the aging process to get the software to 10+ years maturity but within a matter of weeks. For example, say you're implementing a distributed consensus protocol like Viewstamped Replication, Paxos, ZAB or RAFT. This could be several thousand lines of code, just to get something up and running, excluding testing. Then months of writing unit tests and integration tests by hand and thereafter you would still expect several years of widespread industry use and sometimes weeks of debugging per reported issue just to shake out all the non-obvious edge cases. How would you increase your velocity here? The key insight is that the implementation phase represents only several months of work, whereas the actual maturation process or debugging phase represents perhaps years of work. And, until recently, both phases were typically treated the same way—people manually writing code, and then people manually writing tests, manually running the code on real systems in real time, manually filing issues, manually classifying these issues and manually debugging issues. So, if you can accelerate the second debugging phase, automating all the manual steps, then—even if your team don't enjoy much velocity in the implementation phase—you could end up several years ahead in velocity where it really counts. If we go back to our consensus example, then you could solve the velocity problem in the testing/debugging phase by spending a little extra time upfront in the design and implementation phase to make sure that all non-deterministic resources in your consensus software (such as message passing or networking, time, timeouts and storage I/O operations) are pluggable and can be swapped out with deterministic shims. Then, when it comes to testing, you could write self-generating unit and integration tests, like Worms, Scorched Earth or SimCity. Your test would spin up a randomly generated but fully deterministic simulated cluster in a single local process on your local developer machine, and then simulate random client requests and random network/storage fault injection, with random network/storage latency/reliability properties, while hooking into where the critical things like state transitions take place and checking linearizability immediately as these state transitions happen, also checking all other invariants along the way required for your software to be correct, so that your test simulator could even tell you if an issue is a liveness bug or a correctness bug, without you having to spend time to figure that out. Then, because you're also shimming your time source, you can just speed up time, so that you can simulate hours of real-world runtime (that would otherwise have literally taken hours if you were using something non-deterministic like Jepsen) in just a few seconds. And now, if a test finds an invariant violation, you can just replay the randomly generated test, again and again, but with debugging logs turned on, to also accelarate the time it takes to reproduce and fix the issue and then verify the fix.
Rainymood 5y ago
Is there any version of Dan Luu's website with just a hint of css? Plain HTML is unreadable imho, content is usually great but I struggle to get through it because it's so damn hard on the eyes.
- rlayton2 5y ago
  On Firefox, reader view made it look quite nice and readable.
crispyambulance 5y ago
> 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.
guhsnamih 5y ago
As this seems to be about productivity from a respected person, I want to make sure I get the important ideas and I have tried. Is there a context in which this article must be read? Is it a commentary to another? Neither its introduction nor its conclusion seems to capture all of its ideas it is about. I know it is not meant to be readable but I'll appreciate any help.
- Jensson 5y ago
  It is related to this article: https://news.ycombinator.com/item?id=28879240 https://news.ycombinator.com/item?id=28879240
  - guhsnamih 5y ago
    Thanks! Your reply was helpful in giving the background although the background itself wasn't so helpful. Just to be sure, is the sole purpose of these articles to suggest why (and not how) to improve productivity? I think I am looking for the secret to 10x productivity which is still hidden somewhere inside those articles. Or is it?
    - jmchuster 5y ago
      You can probably think of it as hidden secret in the sense that, here a couple of people who believe they have greatly increased their own productivity, that it gives them an advantage relative to others, and that you need to piece together from their thoughts how you might apply such anecdata to yourself. My interpretation of these articles is that it is worthwhile to become faster and more productive, that there are real tangible benefits to your quality of life. And that you might gain a lot of productivity by deliberately training your skill at "low-level" components of your workflow, e.g. doubling your typing speed, practicing writing documents, perfecting the use of your tools.
caffeine 5y ago
How do you actually deliberately practice and improve programming? What about data science / research? Curious if anyone has suggestions.
8b16380d 5y ago
The problem is the anti work mentality and other demotivating factors are a product societal issues. What existential question is being answered by improving productivity and velocity?
aozgaa 5y ago
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.
- mrcode007 5y ago
  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 :)

326 points by davidmckenna 5y ago

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.

crate_barre 5y ago
But do they really care? Some of us work in processes and workflows that would alarm others. Imagine you say ‘I care about my son’s education’, yet everyday you watch this child have to sharpen their pencil with a razor, and walk blocks to a Starbucks to get free internet for research. You can solve it or look into, but you don’t. You could even say ‘I get how hard this is for you’, but instead you call the person lazy. We grow fatigued. That’s many of our shitty codebases and Agile workflows that besiege one’s cognitive capacity. Couple that with a constant ‘what have you done for me lately’ expectation, and you have a recipe for apathy. Subconsciously, the kid will internalize that and it’ll show. Your failure as this analogous business father is that at the every end, you blame the kid for not doing enough.

xupybd 5y ago

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 5y ago
[deleted]
andrekandre 5y ago
> Any tips on how to get faster? quality take the time to write quality code, design quality systems, debug things the right way, don't rush, take your time before you know it, writing good code (and systems) becomes second nature and you will get faster as a result in other words, fast people/teams know how to be fast because high quality is second nature and they don't waste their time fixing bugs and retesting again and again
caffeine 5y ago
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.

woah 5y ago

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?

renewiltord 5y ago
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 5y ago
  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.
  - renewiltord 5y ago
    Yeah that makes sense. Sounded like the most likely explanation honestly.
meowface 5y ago
(The post, for anyone curious: https://news.ycombinator.com/item?id=28879240 https://news.ycombinator.com/item?id=28879240) Yeah, it's very similar in a lot of ways.
hyperpape 5y ago
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.
deleted 5y ago
[deleted]

cratermoon 5y ago

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.

jai_ 5y ago
The entire point of TFA is that the ability to go fast is a force multiplier for being productive in the first place.
- cratermoon 5y ago
  But to what end?
  - Jtsummers 5y ago
    To get your time back while still meeting professional obligations, at least that's my "end" in being productive.
    - cratermoon 5y ago
      > 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 5y ago
        Do you have a trust fund?
        cratermoon 5y ago
        No, and you raise a good point. Someone with a trust fund or other form of inherited wealth, or just with sufficient passive income, doesn't need to be productive. That person can claim as much leisure time as they want, when they want. So the argument the author of the post makes, that productivity is a necessary precondition for leisure, is really not true at all. In our society we may find that money and income are preconditions, but there's nothing inherent about the need for productivity to have those.

jdlshore 5y ago

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

Graffur 5y ago
It's measured by tweeting, github social actions and giving talks at conferences
karmakaze 5y ago
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.
foolfoolz 5y ago
productivity is delivering value to your customers
crate_barre 5y ago
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 5y ago

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

Afforess 5y ago
> 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.
mental1896 5y ago
>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 5y ago
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.
- sureglymop 5y ago
  That's true. Besides, what ethics are there in capitalism? Just thinking about it, how can someone who works and lives paycheck to paycheck ever afford to make ethical and moral decisions in or about their work? They can't afford that because they need whatever payment they can scramble together to survive. And so naturally, one must be at a very privileged position to be comfortable with the consequences of ones personal labor.

m0zg 5y ago

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.

spaetzleesser 5y ago
"Design docs take _much_ longer than you think. Code reviews take longer than you think also." I work in medical devices and this is so true. A thorough design doc or a thorough code review takes a very long time. It actually may take as much or more time as the actual coding. Somehow we never account for this time in planning so either things are rushed or the project will be delayed significantly. Add to that the fact we don't have good tools either for writing docs neither or for code reviews.
- m0zg 5y ago
  Try actually tracking the time using a free service like Harvest. You'll be surprised just how much longer some things take objectively than subjectively. I'm not saying do retrospectives every week or whatever, but do at least a few, then take note of time sinks and weigh their utility against the time they take. I don't think one can build awareness of this without measurement, something the essay also alludes to.
  - 5y ago

minihat 5y ago

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 5y ago
> 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.
graperapist1480 5y ago
Energy constrained? That’s odd. Just eat more? CICO after all. Maybe guzzle some lard? It’s very dense.
- agent327 5y ago
  "Energy constrained" doesn't mean he lacks sugar, it means his brain isn't letting him do the work anymore because it is in the process of burning out.
  - minihat 5y ago
    Yes, this is my intended meaning. I am a PhD student working on my thesis. After a certain number of hours of doing mathematics or algorithm design, I have to switch to easier tasks like reading papers in a domain I'm familiar with, or documenting code. While I cannot speak for anyone but myself, my performance on highly challenging tasks is capped at 4-5 hours per day. At that point, it is better for me to switch to lower hanging fruit. If I am feeling especially inspired, sometimes I'll put in a 12+ hour day of hard work. Rarely, even two or more in a row. But inevitably, I will feel extra burned out in the subsequent days.

hardwaregeek 5y ago

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 5y ago
> 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.
- auggierose 5y ago
  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.

vasco 5y ago

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 5y ago
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 https://youtu.be/HrWKXO1qwPM
jmchuster 5y ago
velocity = speed + direction If you are able to achieve speed that is 2x, then as long as your angle is less than 60 degrees off axis from the theoretical perfect direction, you're making progress towards the goal faster than everyone else. Though I wouldn't be surprised to find out that your error is not nearly that high, and given your high amount of practice/experience, you might even end up with the least amount of angular error amongst your peers.

man_from_space 5y ago

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

vymague 5y ago
> 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.
- comicjk 5y ago
  https://en.wikipedia.org/wiki/Scientific_management 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.
samth 5y ago
Dan Luu is definitely not someone who never learns anything new or who doesn't think differently.
jodrellblank 5y ago
An inaccurate criticism which is addressed in the article: "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 quickly, 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."

raglof 5y ago

iwouldsayiagree

vymague 5y ago

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 https://news.ycombinator.com/item?id=22253893 post has an interesting advice. Record yourself when you're coding. Watch them and identify possible improvements. Reminds me of James Woods' lawyer character in the TV show Shark. He did the same thing.

cuddlecake 5y ago
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?)
- sureglymop 5y ago
  That honestly sounds exhausting.. like, just thinking about it, what if they have set their own keyboard shortcuts? I feel like ones "workstation" or "setup" is always too individual (and that's good). Who are you to know that they don't know about a certain editor feature and just don't like to use that in their workflow? And why does one even need to know vim at this point in time? Don't get me wrong, i know and use vim daily but does it differentiate me in any way from someone who uses nano or micro or whatever editor they have in their workflow? Not at all.
  - chousuke 5y ago
    What does it hurt to tell someone about a feature they could be using, especially if you're mentoring? If they don't want to, they'll tell you and that's fine, but they need to be aware of it in the first place to make that choice, and the assumption that other people know the same things as you is often wrong.

TeeMassive 5y ago

Press F9 to toggle reader view.

a_e_k 5y ago

> 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 https://en.wikipedia.org/wiki/Jevons_paradox.

ChrisMarshallNY 5y ago

I dunno. I just code every day (like, seven days a week). Seems to help me work fairly quickly, and fairly well. I write good code, quickly. I’m not at all interested in comparing myself to, or competing with, anyone else. I can get the job done to my satisfaction, and in a timeframe the I consider acceptable.

DeathArrow 5y ago

I think that being fast at coding is akin of being fast working on an assembly line. This might matter a bit, however I don't strive to do that. If it comes naturally with experience good, if not, I don't make a goal from it. Churning out code is something that bores me. I'm interested more in problem solving, computer science part of programming, optimizations, research, discovery, architecture. I am not interested so much in how I do this common thing fast, but rather in how I solve this hard or interesting problem. If a problem is already solved, can I find a better solution? How fast the code will run? How robust it will be?

crate_barre 5y ago
I’d also add that it’s something many of us no longer need to prove to ourselves. When you are new, you have to at least prove to yourself once that you can be this ‘machine’. Once you’ve proven it, how is that a goal anymore? I’m not interested in that anymore either. There are more optimal ways to being this machine than just slamming one’s head against a keyboard, the proverbial work smarter, not harder.

lngnmn2 5y ago

This is great example of virtue-signalling and rationalizations. No, typing speed is irrelevant related to content quality. Think of poetry - it is all about finding the right word rather than committing them into writing. He just plainly typing too much - a thick book fallacy. Truth does not require lots of verbiage, on the contrary, it requires a short, clean, precise, adequate "just right" formulation. That piece of text in in the link could be reduced 10x without losing anything meaningful (which is very sparse indeed).

ptr 5y ago

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?

CGamesPlay 5y ago
You can get "randomized alarm clock" apps and websites which would enable you to ask this to yourself in an automated fashion.
maxjmartin 5y ago
Sounds like tagtime https://github.com/tagtime/TagTime https://github.com/tagtime/TagTime

bullen 5y ago

This is doing wonders for my procrastination! But I agree that if you find out that you have been working on the only problem worth solving for 10 years you should be able to take a break because the likelyhood that anyone else is able to run past you is very small. (they would have needed to start before you without you finding out for 10 years because hard problems are not solved faster in a group)

_vvhw 5y ago

At least one way to increase velocity is to design software such that you can radically accelerate the aging process to get the software to 10+ years maturity but within a matter of weeks. For example, say you're implementing a distributed consensus protocol like Viewstamped Replication, Paxos, ZAB or RAFT. This could be several thousand lines of code, just to get something up and running, excluding testing. Then months of writing unit tests and integration tests by hand and thereafter you would still expect several years of widespread industry use and sometimes weeks of debugging per reported issue just to shake out all the non-obvious edge cases. How would you increase your velocity here? The key insight is that the implementation phase represents only several months of work, whereas the actual maturation process or debugging phase represents perhaps years of work. And, until recently, both phases were typically treated the same way—people manually writing code, and then people manually writing tests, manually running the code on real systems in real time, manually filing issues, manually classifying these issues and manually debugging issues. So, if you can accelerate the second debugging phase, automating all the manual steps, then—even if your team don't enjoy much velocity in the implementation phase—you could end up several years ahead in velocity where it really counts. If we go back to our consensus example, then you could solve the velocity problem in the testing/debugging phase by spending a little extra time upfront in the design and implementation phase to make sure that all non-deterministic resources in your consensus software (such as message passing or networking, time, timeouts and storage I/O operations) are pluggable and can be swapped out with deterministic shims. Then, when it comes to testing, you could write self-generating unit and integration tests, like Worms, Scorched Earth or SimCity. Your test would spin up a randomly generated but fully deterministic simulated cluster in a single local process on your local developer machine, and then simulate random client requests and random network/storage fault injection, with random network/storage latency/reliability properties, while hooking into where the critical things like state transitions take place and checking linearizability immediately as these state transitions happen, also checking all other invariants along the way required for your software to be correct, so that your test simulator could even tell you if an issue is a liveness bug or a correctness bug, without you having to spend time to figure that out. Then, because you're also shimming your time source, you can just speed up time, so that you can simulate hours of real-world runtime (that would otherwise have literally taken hours if you were using something non-deterministic like Jepsen) in just a few seconds. And now, if a test finds an invariant violation, you can just replay the randomly generated test, again and again, but with debugging logs turned on, to also accelarate the time it takes to reproduce and fix the issue and then verify the fix.

Rainymood 5y ago

Is there any version of Dan Luu's website with just a hint of css? Plain HTML is unreadable imho, content is usually great but I struggle to get through it because it's so damn hard on the eyes.

rlayton2 5y ago
On Firefox, reader view made it look quite nice and readable.

crispyambulance 5y ago

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

guhsnamih 5y ago

As this seems to be about productivity from a respected person, I want to make sure I get the important ideas and I have tried. Is there a context in which this article must be read? Is it a commentary to another? Neither its introduction nor its conclusion seems to capture all of its ideas it is about. I know it is not meant to be readable but I'll appreciate any help.

Jensson 5y ago
It is related to this article: https://news.ycombinator.com/item?id=28879240 https://news.ycombinator.com/item?id=28879240
- guhsnamih 5y ago
  Thanks! Your reply was helpful in giving the background although the background itself wasn't so helpful. Just to be sure, is the sole purpose of these articles to suggest why (and not how) to improve productivity? I think I am looking for the secret to 10x productivity which is still hidden somewhere inside those articles. Or is it?
  - jmchuster 5y ago
    You can probably think of it as hidden secret in the sense that, here a couple of people who believe they have greatly increased their own productivity, that it gives them an advantage relative to others, and that you need to piece together from their thoughts how you might apply such anecdata to yourself. My interpretation of these articles is that it is worthwhile to become faster and more productive, that there are real tangible benefits to your quality of life. And that you might gain a lot of productivity by deliberately training your skill at "low-level" components of your workflow, e.g. doubling your typing speed, practicing writing documents, perfecting the use of your tools.

caffeine 5y ago

How do you actually deliberately practice and improve programming? What about data science / research? Curious if anyone has suggestions.

8b16380d 5y ago

The problem is the anti work mentality and other demotivating factors are a product societal issues. What existential question is being answered by improving productivity and velocity?

aozgaa 5y ago

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.

mrcode007 5y ago
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 :)