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.
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.
> 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.
I solved this problem by going to a psychiatrist, getting diagnosed with ADHD (at age 35), and starting medication.
Not an exaggeration—I struggled with compulsive video gaming for almost my entire life; now on medication that issue has just completely vanished.
Very well put. This was sort of my attitude to programming years ago - to try to get really good at the craft. But the question is, is that going to be rewarded or recognized at all? Who makes more, the programmer dedicated to their craft and domain getting better every day, or the leetcode expert who jumps from one FAANG to another getting 30% raises each time? What is the track for promotion at most companies - being a better programmer or learning project management and becoming a manager/lead who only spends 10% of their day coding?
I could try to get really good at programming. I could try to really learn something like databases or systems programming extremely well. But is a recruiter looking at my resume going to see that? Is a management chain that doesn’t really understand software going to reward that? Does the 100th startup building your average webapp need that skillset at all? Does your manager even look at a pull request and have any idea of the quality of your code, or do they simply evaluate # tickets / day?
I have never worked at a FAANG or any of these beautiful environments with amazing people dedicated to the craft of engineering. I have worked in places where great engineering is not recognized, or (more often) just not as important as okay engineering + project management + communication + being friends with the right people. The job of a modern software developer in most places is only partly about programming. Pure programmers are just low value cogs in an assembly line, and being a great programmer only makes you a slightly better low value cog because it won’t be recognized. Your average manager sees you do the task in X days and assumes it was about X days worth of work - they have 0 idea if it would’ve taken someone else 5X the time. Its a luxury to work somewhere where your job really is just engineering and good engineering is recognized and rewarded. When your chances of working somewhere like that are low and you have limited time, maybe its not worth investing time and energy into leveling up as an engineer.
I think you're kind of mythologizing both FAANGs and Leetcode here. Leetcode won't get you further than doing amazing work and making your co-workers and colleagues happy. The OP is about how to get serious upgrades in the work you do. Leetcode is a thing that gets you in the door.
Likewise, FAANGs are not in every case "beautiful environments with amazing people dedicated to the craft of engineering." The most toxic person I ever met in my life spent years at Google, and he was not an impressive engineer by any stretch of the imagination. Amazon, Microsoft, and to a lesser extent Netflix are all notorious for having Squid Game cultures where everybody knows somebody will get fired soon and they're working hard to make sure it's not them.
Also, this is just false:
Pure programmers are just low value cogs in an assembly line, and being a great programmer only makes you a slightly better low value cog because it won’t be recognized.
I'm not saying it isn't true at any company. But as a statement about the overall industry, it's false. Great architectural decisions can add substantial amounts to a company's bottom line.
Likewise, this feels very naive to me personally:
What is the track for promotion at most companies - being a better programmer or learning project management and becoming a manager/lead who only spends 10% of their day coding?
Principal engineer can be an astonishingly lucrative role.
You should not expect a better payment from your company because you are a better programmer. Payment is according to demand and offer. Your company will mostly demand what you say: OK engineering, management skills, good communication skills, getting well along with your colleagues.
But from being a better programmer you can still derive better monetary gains. Instead of striving to become a lead or manager or product owner, you can either become an entrepreneur or search for a company where being a better programmer is a highly desired skill.
If your motivation is to be able to work "at a FAANG or any of these beautiful environments with amazing people dedicated to the craft of engineering", then maybe it's more useful to think of the advice in terms of, making it easy to get a job "where your job really is just engineering and good engineering is recognized and rewarded". Or is this not actually your motivation and it's more to lightly mock people who grinded to get such jobs? If you've never worked at a company that has amazing people, that was a beautiful environment, that had dedication to craft, then it might be difficult to believe that such companies do exist. But once you enjoy it and recognize it, then that just becomes your standard for companies, so you'll only interview at companies that you think might meet that standard, you carefully evaluate them during the process, and you switch if you find that not to be the case.
> What is the track for promotion at most companies
A point he hammers home in the article is that he likes to be more productive so that he can go home earlier and do what he loves.
> Pure programmers are just low value cogs
The idea of improving productivity here is not only applicable to programming. One example he mentions is improving meetings. If you're a business person, you could improve at spreadsheet jockeying.
> 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.
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.
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.
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.
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.
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.)
Productivity: If you need an X, how quickly can you implement an X at a high level of quality?
If your product manager asks for a new widget or api, can you implement it without any major bugs in 1 hour? Or will you take three days because you don't understand your programming language, your codebase and your requirements?
Will the widget/api be free of major bugs, or will it fail on a variety of edge cases that could have been solved ahead of time?
Productivity may not have crisp, clear lines. There's always context. But it comes down to: if you can do X in half the time at the same level of quality, you're twice as productive.
I admire Dan Luu's work and this article in particular really resonated with me.
> If you need an X, how quickly can you implement an X at a high level of quality?
That's the wrong question for anyone who's not a new grad junior engineer. If these are the only kinds of question you're addressing, you're probably replaceable by a Ukrainian dev shop.
In reality depending on your particular role and organization the questions you need to answer range from "How do I find product-market fit" at an early-stage startup to "How do I meet my client's requirements" to "How do I move the needle on X metrics" at a big company.
The key difference between these kinds of questions is that there can be many different routes, and measuring "productivity" in one metric limits the ability to explore. For example, "How fast can you implement a chat widget" doesn't allow for the exploration of alternative ways to engage with customers -- emailing them directly might've been much better.
Even assuming you are very "focused" on pure engineering, measuring the speed of implementing X doesn't account for "productivity" on a personal level, i.e. perhaps you built it in 5 days but now you're burnt out for the next month. Or you had other projects you didn't end up working on. Or you neglected your family. By the way, you handwaved over "X level of quality" but I'm sure we all know that this in itself is nontrivial to gauge.
There are many goals that may count as "productivity", and you don't necessarily even know all of them. Therefore its quantification is nontrivial.
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.
- 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'm gonna try. Productivity is the discounted future cash flow per hour of work.
Here's what it's not: It's not about how much code you write. It's not about the quality of the code. It's not about clever engineering solutions. All these can (and should) be part of the above, or they may not. Sometimes sucky code that can bring in a billion dollars is better than great code that brings in nothing. Technical debt is fine as long as the "interest" on that debt is << the profit you made by taking on that debt. Just like any other debt.
A business pays you $X an hour, what are they getting out of you $-wise?
To be clear, that doesn't mean that e.g. someone working on internal tooling can't be productive, but their productivity is measured by the impact on someone else who eventually uses the tooling to make money somehow.
This is incredibly difficult/impossible to measure perfectly, certainly on an individual level, but I still think it's worthwhile to look at it like this...
EDIT: I totally agree with the spirit of "sharpen your axe" and "be good at what you do". I spent a lot of time as a teenager learning to type fast. I did coding competitions to learn how to code real fast. This is part of what being a craftsman is about. But the leverage there is really limited. I liked what one of my ex-CEOs used to say, that just because he types fast doesn't mean he should do his secretary's work. So after you know what you're doing, you have the right approach, you're the right person to do this, all the other business factors, you should definitely excel at doing it.
> Productivity is the discounted future cash flow per hour of work.
That's not an unreasonable proposal, but isn't the whole point of startups that we're playing with upsides that are extremely huge and extremely unlikely? It seems like it would be extremely difficult to apply this definition to an engineer or a very small engineering team at an early-stage startup. Surely all the functionally equivalent restaurant delivery apps (at least those above some reasonable baseline of engineering competence) had very similar engineering going on in the early days, yet most of them you barely remember while a very small number of them are unicorns. But could you really have looked at an engineer in the early days and picked out the difference?
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.
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.
Note: I only skimmed your comment, so consider this about something else.
Programmers protest too much about 10x programmers. Saying there isn't a 10x programmer is the same as saying nobody could possibly work hard and improve enough to be that much better at something. But we know that every single activity we can objectively measure has far more than a 10x variation in performance. Why is there someone 10x better than average at assembling Ikea furniture, or shooting a bow and arrow, or juggling, or running, or even eating, but programmers are interchangeable cogs? Its a totally bizarre thing to even consider without very strong evidence, and that evidence doesn't exist. Seems like sour grapes to me.
You went from "10x the average" (which the claim is about) to 10x between arbitrary people: it's obvious why the latter is true (some people just need to terribly suck at something), it's harder to buy into the 10x the average performance because of... how hard it is to define (improvement in) performance when you are not starting off of (near) zero.
I actually think that defining the metrics is half of the game for productivity. Once you define the metrics, it's relatively easy to game it.
That said, I think software development is a relatively well defined task. There's typically some clear need from clients, and there's some restriction. Your problem space is somewhat confined.
Now, corollary is this: the more restriction you have, the easier you can be productive (or invent a way to be productive). Specialists can be generally more productive than generalists because they can have a more precise definition of "being productive".
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".
> 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.
“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.
"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.
> 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.
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.
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.
> 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.
> 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.
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.
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
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 possible improvements. Reminds me of James Woods' lawyer character in the TV show Shark. He did the same thing.
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?)
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.
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.
> 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.
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?
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?
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.
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".
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.
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)
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.
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?
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.
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.
Working on the right thing means driving in the right direction. Velocity is the speed at which you get there. Anyone that says velocity doesn't matter is wrong and there should be no debate.
That's debatable. Seriously tho your comment reminded me of one of my favourite TV ads for road safety from a few years ago https://youtu.be/HrWKXO1qwPM
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.
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?
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 :)
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?
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.
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.
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.
"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.
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.
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.
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 last point:
> The last major argument I see against working on velocity assigns negative moral weight to the idea of thinking about productivity and working on velocity at all. This kind of comment often assigns positive moral weight to various kinds of leisure, such as spending time with friends and family. I find this argument to be backwards. If someone thinks it's important to spend time with friends and family, an easy way to do that is to be more productive at work and spend less time working.
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 quickly4, 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.
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 significantly is not there in a job (even Luu acks this in his blog).
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.
Not that GP and OP are not really in opposition: Luu is arguing for why it's ok to work on your speed/performance with deliberate practice, GP is arguing that it is ok not to. And I agree with both.
Yeah but he doesn't recognize that his entire argument is personal choice elevated to moral imperative.
> an easy way to do that is to be more productive at work and spend less time working
Why is need to be more productive at work framed as a prerequisite to spending less time working? Just spend less time working. His moral stance, which he never reflects on, is that working is good, and relaxing is predicating on completing the work first. None of that is necessarily true, but it does fit well with the Protestant Work Ethic, which is, of course, a moral framework for putting work before leisure.
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).
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
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."
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.
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.
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.
> 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.
I solved this problem by going to a psychiatrist, getting diagnosed with ADHD (at age 35), and starting medication.
Not an exaggeration—I struggled with compulsive video gaming for almost my entire life; now on medication that issue has just completely vanished.
5 replies →
Very well put. This was sort of my attitude to programming years ago - to try to get really good at the craft. But the question is, is that going to be rewarded or recognized at all? Who makes more, the programmer dedicated to their craft and domain getting better every day, or the leetcode expert who jumps from one FAANG to another getting 30% raises each time? What is the track for promotion at most companies - being a better programmer or learning project management and becoming a manager/lead who only spends 10% of their day coding?
I could try to get really good at programming. I could try to really learn something like databases or systems programming extremely well. But is a recruiter looking at my resume going to see that? Is a management chain that doesn’t really understand software going to reward that? Does the 100th startup building your average webapp need that skillset at all? Does your manager even look at a pull request and have any idea of the quality of your code, or do they simply evaluate # tickets / day?
I have never worked at a FAANG or any of these beautiful environments with amazing people dedicated to the craft of engineering. I have worked in places where great engineering is not recognized, or (more often) just not as important as okay engineering + project management + communication + being friends with the right people. The job of a modern software developer in most places is only partly about programming. Pure programmers are just low value cogs in an assembly line, and being a great programmer only makes you a slightly better low value cog because it won’t be recognized. Your average manager sees you do the task in X days and assumes it was about X days worth of work - they have 0 idea if it would’ve taken someone else 5X the time. Its a luxury to work somewhere where your job really is just engineering and good engineering is recognized and rewarded. When your chances of working somewhere like that are low and you have limited time, maybe its not worth investing time and energy into leveling up as an engineer.
I think you're kind of mythologizing both FAANGs and Leetcode here. Leetcode won't get you further than doing amazing work and making your co-workers and colleagues happy. The OP is about how to get serious upgrades in the work you do. Leetcode is a thing that gets you in the door.
Likewise, FAANGs are not in every case "beautiful environments with amazing people dedicated to the craft of engineering." The most toxic person I ever met in my life spent years at Google, and he was not an impressive engineer by any stretch of the imagination. Amazon, Microsoft, and to a lesser extent Netflix are all notorious for having Squid Game cultures where everybody knows somebody will get fired soon and they're working hard to make sure it's not them.
Also, this is just false:
Pure programmers are just low value cogs in an assembly line, and being a great programmer only makes you a slightly better low value cog because it won’t be recognized.
I'm not saying it isn't true at any company. But as a statement about the overall industry, it's false. Great architectural decisions can add substantial amounts to a company's bottom line.
Likewise, this feels very naive to me personally:
What is the track for promotion at most companies - being a better programmer or learning project management and becoming a manager/lead who only spends 10% of their day coding?
Principal engineer can be an astonishingly lucrative role.
1 reply →
You should not expect a better payment from your company because you are a better programmer. Payment is according to demand and offer. Your company will mostly demand what you say: OK engineering, management skills, good communication skills, getting well along with your colleagues.
But from being a better programmer you can still derive better monetary gains. Instead of striving to become a lead or manager or product owner, you can either become an entrepreneur or search for a company where being a better programmer is a highly desired skill.
If your motivation is to be able to work "at a FAANG or any of these beautiful environments with amazing people dedicated to the craft of engineering", then maybe it's more useful to think of the advice in terms of, making it easy to get a job "where your job really is just engineering and good engineering is recognized and rewarded". Or is this not actually your motivation and it's more to lightly mock people who grinded to get such jobs? If you've never worked at a company that has amazing people, that was a beautiful environment, that had dedication to craft, then it might be difficult to believe that such companies do exist. But once you enjoy it and recognize it, then that just becomes your standard for companies, so you'll only interview at companies that you think might meet that standard, you carefully evaluate them during the process, and you switch if you find that not to be the case.
> What is the track for promotion at most companies
A point he hammers home in the article is that he likes to be more productive so that he can go home earlier and do what he loves.
> Pure programmers are just low value cogs
The idea of improving productivity here is not only applicable to programming. One example he mentions is improving meetings. If you're a business person, you could improve at spreadsheet jockeying.
> 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.
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.
5 replies →
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.
18 replies →
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.
4 replies →
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.
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.)
Productivity: If you need an X, how quickly can you implement an X at a high level of quality?
If your product manager asks for a new widget or api, can you implement it without any major bugs in 1 hour? Or will you take three days because you don't understand your programming language, your codebase and your requirements?
Will the widget/api be free of major bugs, or will it fail on a variety of edge cases that could have been solved ahead of time?
Productivity may not have crisp, clear lines. There's always context. But it comes down to: if you can do X in half the time at the same level of quality, you're twice as productive.
I admire Dan Luu's work and this article in particular really resonated with me.
> If you need an X, how quickly can you implement an X at a high level of quality?
That's the wrong question for anyone who's not a new grad junior engineer. If these are the only kinds of question you're addressing, you're probably replaceable by a Ukrainian dev shop.
In reality depending on your particular role and organization the questions you need to answer range from "How do I find product-market fit" at an early-stage startup to "How do I meet my client's requirements" to "How do I move the needle on X metrics" at a big company.
The key difference between these kinds of questions is that there can be many different routes, and measuring "productivity" in one metric limits the ability to explore. For example, "How fast can you implement a chat widget" doesn't allow for the exploration of alternative ways to engage with customers -- emailing them directly might've been much better.
Even assuming you are very "focused" on pure engineering, measuring the speed of implementing X doesn't account for "productivity" on a personal level, i.e. perhaps you built it in 5 days but now you're burnt out for the next month. Or you had other projects you didn't end up working on. Or you neglected your family. By the way, you handwaved over "X level of quality" but I'm sure we all know that this in itself is nontrivial to gauge.
There are many goals that may count as "productivity", and you don't necessarily even know all of them. Therefore its quantification is nontrivial.
1 reply →
Eh, there are two archetypes in this industry:
One who pounds out the solution in an hour, is not smart enough to perceive its flaws.
One who takes three days because they understand their language, codebase, and requirements.
13 replies →
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.
after doing a few kinds of jobs:
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.
11 replies →
Somehow, this never really clicked for me before.
Mind blown.
Thanks!
How much sleep do you get?
1 reply →
I'm gonna try. Productivity is the discounted future cash flow per hour of work.
Here's what it's not: It's not about how much code you write. It's not about the quality of the code. It's not about clever engineering solutions. All these can (and should) be part of the above, or they may not. Sometimes sucky code that can bring in a billion dollars is better than great code that brings in nothing. Technical debt is fine as long as the "interest" on that debt is << the profit you made by taking on that debt. Just like any other debt.
A business pays you $X an hour, what are they getting out of you $-wise?
To be clear, that doesn't mean that e.g. someone working on internal tooling can't be productive, but their productivity is measured by the impact on someone else who eventually uses the tooling to make money somehow.
This is incredibly difficult/impossible to measure perfectly, certainly on an individual level, but I still think it's worthwhile to look at it like this...
EDIT: I totally agree with the spirit of "sharpen your axe" and "be good at what you do". I spent a lot of time as a teenager learning to type fast. I did coding competitions to learn how to code real fast. This is part of what being a craftsman is about. But the leverage there is really limited. I liked what one of my ex-CEOs used to say, that just because he types fast doesn't mean he should do his secretary's work. So after you know what you're doing, you have the right approach, you're the right person to do this, all the other business factors, you should definitely excel at doing it.
> Productivity is the discounted future cash flow per hour of work.
That's not an unreasonable proposal, but isn't the whole point of startups that we're playing with upsides that are extremely huge and extremely unlikely? It seems like it would be extremely difficult to apply this definition to an engineer or a very small engineering team at an early-stage startup. Surely all the functionally equivalent restaurant delivery apps (at least those above some reasonable baseline of engineering competence) had very similar engineering going on in the early days, yet most of them you barely remember while a very small number of them are unicorns. But could you really have looked at an engineer in the early days and picked out the difference?
3 replies →
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.
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.
Note: I only skimmed your comment, so consider this about something else.
Programmers protest too much about 10x programmers. Saying there isn't a 10x programmer is the same as saying nobody could possibly work hard and improve enough to be that much better at something. But we know that every single activity we can objectively measure has far more than a 10x variation in performance. Why is there someone 10x better than average at assembling Ikea furniture, or shooting a bow and arrow, or juggling, or running, or even eating, but programmers are interchangeable cogs? Its a totally bizarre thing to even consider without very strong evidence, and that evidence doesn't exist. Seems like sour grapes to me.
You went from "10x the average" (which the claim is about) to 10x between arbitrary people: it's obvious why the latter is true (some people just need to terribly suck at something), it's harder to buy into the 10x the average performance because of... how hard it is to define (improvement in) performance when you are not starting off of (near) zero.
4 replies →
I actually think that defining the metrics is half of the game for productivity. Once you define the metrics, it's relatively easy to game it.
That said, I think software development is a relatively well defined task. There's typically some clear need from clients, and there's some restriction. Your problem space is somewhat confined.
Now, corollary is this: the more restriction you have, the easier you can be productive (or invent a way to be productive). Specialists can be generally more productive than generalists because they can have a more precise definition of "being productive".
It's measured by tweeting, github social actions and giving talks at conferences
productivity is delivering value to your customers
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".
> 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.
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.
1 reply →
"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.
1 reply →
> 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.
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.
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.
> 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.
>you should probably leave your job or not take it in the first place
sounds like a decadent rationalization of some kind.
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...
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.
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.
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
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 possible improvements. Reminds me of James Woods' lawyer character in the TV show Shark. He did the same thing.
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?)
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.
2 replies →
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.
On Firefox, reader view made it look quite nice and readable.
> 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.
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?
Sounds like tagtime https://github.com/tagtime/TagTime
You can get "randomized alarm clock" apps and websites which would enable you to ask this to yourself in an automated fashion.
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?
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.
(The post, for anyone curious: https://news.ycombinator.com/item?id=28879240)
Yeah, it's very similar in a lot of ways.
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".
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.
1 reply →
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)
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.
It is related to this article:
https://news.ycombinator.com/item?id=28879240
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?
1 reply →
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.
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.
How do you actually deliberately practice and improve programming?
What about data science / research?
Curious if anyone has suggestions.
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.
Working on the right thing means driving in the right direction. Velocity is the speed at which you get there. Anyone that says velocity doesn't matter is wrong and there should be no debate.
That's debatable. Seriously tho your comment reminded me of one of my favourite TV ads for road safety from a few years ago https://youtu.be/HrWKXO1qwPM
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.
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?
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 :)
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?
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.
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.
Press F9 to toggle reader view.
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.
"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.
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.
2 replies →
iwouldsayiagree
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.
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 last point:
> The last major argument I see against working on velocity assigns negative moral weight to the idea of thinking about productivity and working on velocity at all. This kind of comment often assigns positive moral weight to various kinds of leisure, such as spending time with friends and family. I find this argument to be backwards. If someone thinks it's important to spend time with friends and family, an easy way to do that is to be more productive at work and spend less time working.
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 quickly4, 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.
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 significantly is not there in a job (even Luu acks this in his blog).
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.
Not that GP and OP are not really in opposition: Luu is arguing for why it's ok to work on your speed/performance with deliberate practice, GP is arguing that it is ok not to. And I agree with both.
1 reply →
Yeah but he doesn't recognize that his entire argument is personal choice elevated to moral imperative.
> an easy way to do that is to be more productive at work and spend less time working
Why is need to be more productive at work framed as a prerequisite to spending less time working? Just spend less time working. His moral stance, which he never reflects on, is that working is good, and relaxing is predicating on completing the work first. None of that is necessarily true, but it does fit well with the Protestant Work Ethic, which is, of course, a moral framework for putting work before leisure.
6 replies →
The entire point of TFA is that the ability to go fast is a force multiplier for being productive in the first place.
and what is the force multiplier for being fast?
But to what end?
6 replies →
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).
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
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."
Dan Luu is definitely not someone who never learns anything new or who doesn't 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.