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.
I was fearing/expecting someone to mention ADHD. I have never been formally diagnosed but everything I read about it feels suspiciously similar to the way my brain is wired. I might have to look into it more seriously. I’m currently 33.
We didn't evolve to sit and focus for hours per day, some people can still do it but others need medicine. The main thing the medicine does is tell your brain "now is the time to focus, don't look for something else!". If being able to do that would feel life changing to you rather than just helpful then you should go get tested.
I agree with your general message and positivity but it is worth mentioning that Adderall, and stimulants, work differently in an ADHD brain vs. a neurotypical brain. The biggest effect I notice is not focus in a pill but instead a calming effect on the brain.
This has a profound effect on things not related to focus like background anxiety, mild depression, impulsivity, managing relationships etc.
Do thorough research first, so you don’t just look like a drug seeker if you do decide to talk to a doctor. Highly recommend Dr. Russell Barkley’s YouTube videos, as well as Edward Hallowell’s still-relevant book Driven to Distraction.
Nothing to fear, if you do have it your brain has always been this way so in a sense nothing has changed. That said a diagnosis can bring a lot of clarity, understanding, and help you form strategies to do better.
If you seek evaluation, seek it from someone with a lot of experience with Adult ADHD. If you get a diagnosis, make sure you work with a doctor who starts you at the lowest dose and slowly ups it as needed.
How to ADHD is a great YouTube channel, if you are curious.
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 think the rat-race idea got baked deep into SV largely because of the setup of the post-1970 economy, and specifically California's rules: every startup had to be "fast" and "hit the ground running" not just because of literal business pressures, but because implicitly, everyone intends to exit and move on to the next thing immediately, so a slow-moving part-time effort would be a no-go. That derived just from mundane realities about the market, legal and financial environment, and protections afforded towards workers and businesses - everyone knows that we moved in the direction of corporations squeezing the workforce because they "couldn't afford" to build them up. Therefore career mindsets filtered to accommodate only those with the gold rush viewpoint, because the only way to win that game was to strike it rich and retire.
I don't think you're allowed to reply to a comment and also downvote it.
Suffice it to say, the comment is not rooted in any reality of what Silicon Valley was like, it is pure uninformed speculation, salted with a heavy dose of facile anti-capitalist talking points. It's lazy and factually incorrect.
First, things weren't that fast in the past. They were more fast relative to the old system of being employed for life. You know, that system of hierarchy where even the office furniture you were allowed to have was spelled out in a corporate handbook that assigned levels to everyone and created a rigid hierarchy. So who broke that system? It was the treacherous eight. They broke it, and they started Silicon Valley.
Second, it was about empowering the worker. When the treacherous 8 left Schockley's Lab, they were told they would never work again because you don't go and quit your boss because you don't like him or disagree with his technical roadmap. You are supposed to be loyal and stay. They called and wrote to hundreds of businesses begging them to invest in their idea and couldn't find anyone until Fairchild took a chance on them. Their success changed that old system of workers being morally obligated to stay with their boss, and the boss being morally obligated to find something for them to do.
Third, workers were actually empowered with stock options. Something unheard of at the time. It was called communism. That investors and entrepeneurs would give a share of their company to their workers. That system originated in SV during this period, and it led to a lot of churn as start ups began to try to outbid each other and established companies for workers, draining talent from those companies that refused to play along and give stock options. Yes, this led to an emphasis on speed and higher employee turnover. But it was because firms kept outbidding each other to lure away workers by dangling stock options in front of them.
This is why Noyce left Fairchild semiconductor - not because he wanted stock options, he was already wealthy from the buyout, but because he couldn't retain his best employees, and Fairchild was morally opposed to the idea of stock options. All these workers leaving and staring their own companies and then luring away their coworkers led to skyrocketing wages rather than all the wealth leaving Silicon Valley and being distributed back to shareholders in Wall Street. A lot of that wealth was put in the pockets of workers for the first time. This is what led to the price of a bungalow in Palo Alto costing three million dollars. That's what happens when you dump so much money on workers.
I could go on and on actually talking about the history, but what's the point when someone reads a pamphlet about how unfair capitalism is, and decides to go on a rant about how oppressed SV workers must have been in the 70s. The 70s in general were bad for capital, great for labor, with rising wages and rising inflation, as well as massive investment -- extreme levels of investment. The 60s were a boom time for corporate profits, but not the 70s. Anyway, this is all part of basic econ history people should know before waxing about how workers were being abused, etc. So in most cases people just downvote statements like the GPs post and move on, without refuting each misconception in detail.
If you want to know more, check out the American Experience episodes on Silicon Valley. They are pretty good.
I wish I could identify a finite set of tasks at which to practice and get much faster. The tradeoff between getting faster at one thing and learning a new thing that could potentially improve my productivity even more is never really clear to me. Someone can have perfected their craft in X and then something better comes along and replaces the whole paradigm.
Your question: There is no finite set. There is no end to it. This is a process. You do it over and over. You don‘t invest into a set and be done with it (and likely over-invested in some). One step at a time. And once in a while reevaluate the territory.
I offer nothing definitive, but one of the greatest benefits of StackOverflow has been to quantifiably classify most of the common problems in computer science, programming, analytics (and to a lesser extent the other StackExchange communities ...)
If you go there, search for a tag, sort by popularity, etc. - most of those techniques and approaches and patterns are, if not timeless, then mostly timeless and relevant.
Master the basic building blocks of programming. Frameworks comes and go but the basics are the same. Master as in "I do X correct the first time even without thinking" not "I know how X works". The "do without thinking" is when your subconscious is doing it for you so your conscious doesn't have to. You want to put as much as your work there as possible, it is like putting work on a GPU instead of your CPU, so every reusable programming trick and pattern should be there. This also helps you reason about code since now your sub consciousness can build code on its own and therefore help you reason in much larger chunks.
A person who hasn't mastered loops and conditionals will fail FizzBuzz. That is bad, you recognise that I hope. But it doesn't end there, you can master so many more powerful parts of programming and get as fast as you were at FizzBuzz att many other much more complicated tasks as well. Ultimately programming takes time due to all the parts you didn't master, but when you have mastered enough parts then you can fit just about any problem into parts you have mastered and code them up extremely quickly.
So the speedup you see is roughly the speedup you saw from at first struggling a lot with loops and conditionals early on when learning programming, to today when you do them effortlessly and instantly. Now the other things to master aren't as simple patterns as loops or conditionals, but the end result is the same improvement in speedup and effort.
For example, competitive programming is about mastering a ton of such chunks. You don't memorize solutions to get fast, you master thousands of such chunks and compose them to solve problems in 5 minutes that would take regular programmers 5 hours if they can solve it at all. I went that route and it is similar to how people master chess, a grandmaster makes better moves after a few seconds of thinking than a typical chess player who has played for years thinking for many minutes.
It took about a year and then I could solve hard problems at similar pace as the best in the world with basically no errors, compare that with spending 4 years in college, I think the practice is worth it, I have never needed to practice that again as the chunks I mastered doesn't go away, it is like learning how to ride a bike. You forget the details, but your subconscious wont forget those chunks. Of course I can't solve hard competitive programming problems in 5 minutes today, but I can solve most leetcode "hard" problems I haven't seen before in under 15 minutes and basically all of them in under 30 even though I haven't practiced these things for many years.
Now, this wont solve all your programming woes, you still need to understand requirements, talk to customers, learn API's etc. But at least you are no longer bottle necked by composing programs. Instead you can throw together MVP's quickly, show prototypes to make discussions more fruitful etc. Also most jobs doesn't requires this level of mastery, only do it if you aim to join top teams using your technical skills if you really get good at this then many teams that wouldn't care about you before now gets very interested in you since so few are this fast, or if you want to build your own products on your own, or if you find mastering things fun.
Edit: Sorry for edits, but here is last bit. When I worked at a high performing team at Google I averaged over 500 lines of code a day going through code review and running in production when I wasn't constrained on non-programming bits like understanding the problem etc. To do that you write 10 changes, each about 50 lines and trivial to review since everything is super clean, otherwise you can't get through code reviews fast enough. Code reviews, unit tests, fixing edge cases etc, none of that are excuses for being slow. Now it is still fine to be slow, I don't blame people, I'm just saying it is possible to be fast if you deliberately practice a lot to be fast.
> To do that you write 10 changes, each about 50 lines and trivial to review since everything is super clean, otherwise you can't get through code reviews fast enough
No matter how small or clean the PRs were, I'm pretty sure I couldn't get reviews for 10 in one day.
Maybe the review tooling you use aren't good enough? At google it shows all test runs related to the change, it shows linter information inline in the file diffs, you automatically associate it with tasks it is meant to solve and you write a 100 word description to explain what it is doing and why.
If the change adds tests, has proper naming, solves the issue it says it is solving in a reasonable way, doesn't solve anything it doesn't say it is solving, and none of the tools complains then you just accept it after looking at the tests being reasonable and the code not looking strange. It takes a while to get new engineers where they do this consistently before review, and then review takes time, but once you know how to write changes that are easy to review then reviews are very quick.
Edit: Btw, optimizing the code you write to reduce review time is also another aspect of productivity. It isn't productive to give a lot of extra work to others, so you practice until everything is as obvious as possible. And as people get used to your changes being easy to review it gets even quicker.
It's less about setting up for the review and more about getting teammates to review the PRs promptly.
I work remotely, so my (Small) team mostly works async even though we're in similar time zones. I doubt trying to ping them for 10 PR reviews in a single day would go well.
Async + people trying to do their own stuff + 10 interruptions is not a great combo. Comments/discussion on a PR can grind things to a halt as well.
I completely agree everything you're saying about making PRs easy to review though. My team already tend to do those things thanks to our manager.
Could be about incentives then. At Google the code reviews you do are tracked so doing many looks good for your performance reviews, so some people try to be fast with reviews to get more reviews. If you don't get any credit for doing code reviews then I can see it being very hard to get people to do them though.
Also as long as you have a pending review sent to you it shows up as a "you have stuff to do" icon in the google tools until you respond to it, just like if you got a message, I guess that helps as well.
The the first thing to do if you want to improve that is to ensure you track code reviews. Meaning, you can see what changes each person reviewed and not just submitted, and then you can use that data to talk about performance etc. If one person does all the reviews then he should get a ton of credit since that is hard important work. Typically lead programmers do more reviews and juniors writes more changes, so a person doing a lot of reviews is associated with seniority and something to strive for rather than avoid. Also I bet your manager would be interested in that information as well, so maybe you just need to suggest it to them.
There's a huge problem with this. The incentive you are describing isn't to do good code reviews. The incentive there is to do a lot of code reviews. Those two are not the same and while they are not mutually exclusive, just by tracking this metric and rating people on it, you are not giving an incentive for good code review. Only for fast review. But you really want both. You want fast and you want good and thorough.
I completely agree that senior and lead people should be doing more reviews and thus help everyone else, ultimately benefiting other programmers and the whole organization overall.
The incentives for reviewing code should be exactly the same as the incentives for writing code.
So the most important part is that the reviewer should be just as visible in all processes and tools as the writer of the code. That way both gets recognition and both gets the blame when the code is bad or adds technical debt. And for performance reviews you don't just look at all the code they wrote, you also look at all the code they reviewed.
You are right that it is dumb to just count the number and say more is better, but the same goes for code submissions. They are very similar problems though so you can just use the same process for both of them.
And that last part unfortunately is what happens in a lot of companies. Basically taking something like your comment I replied to: "Look at metric X" and verbatim looking at that metric and only that metric (or maybe that and 2 or 3 others) and there's your performance review.
You mentioned another metric "code submissions", so say the number of reviews done is augmented by number or PRs merged. You've just created another incentive to just get a lot of code out fast.
After all, that's the point of the metrics, right? Have a few numbers that accurately describe the "value" of that employee. </sarcasm> No qualitative analysis needed, that would take time and money we don't have. Been there, had to do that (or write huge amounts of text to say why I think that this employee is actually really good at what they do and the number of PRs they did was low because they got the short end and worked on the hardest problems in the worst parts of our code base and did an amazing job especially given they were new.
If that's not how it's actually done where you work, great!
What are the 'chunks' of competitive programming? Like knowing how to make a graph, use hash tables / arrays well, a typical dynamic programming solution and so on?
No, its mostly how to structure the full computation flow for different things. If there were an easy set of patterns then it would already be in some book, these things are skills you can't put in a book.
For example, when is it useful to create a function instead of writing the code inline? Many times the amount of code grows exponentially with problem size unless you properly create good functions, so you need to learn to get good at that. Code reuse also greatly improves how fast you can write the solution and reduces bugs, so it is good even when it isn't absolutely necessary.
Where should the data be, who should own what data, how is the data supposed to be found where you need it? And so on. Many problems requires you to create quite elaborate data structures and relationships, finding the right data in a reasonable amount of time is one of the hardest problems to solve even in competitive programming.
Caching and lazy computations as well, it is used everywhere in competitive programming. The fastest solution is where you don't do anything at all, so you get good at understanding how and when to cache results, when to throw out caches in order to handle new data etc.
Writing proper tests, since you get no credit if your code fails for any case you need to write tests that stresses all parts of the code you are unsure about. This teaches you to get really good about understanding the weaknesses in the code you write, debugging and creating solutions that are bug free.
Stuff like that is really important to get good at competitive programming, you need to be able to get good answer those questions in minutes for complex problems if you want to compete with the best in the world. Now you might notice that many basic data structures and algorithms are just solutions to the above problems, the point is to learn many generic cases of the above so you can compose your own data structures and algorithms as everyone of the harder problems requires you to do that.
And as you can realize these things are very useful for any sort of program, not just competitive programming. Managing data layouts and when it is useful to create functions is the majority of normal programming, if you can do those really quickly then there isn't much left that will take time.
Now, the bad rep competitive programming has is mostly that people just do the easy problems that can be summarized as "implement this basic algorithm". Real competitive programming isn't like that at all. Of course you need to be able to do the simple algorithms, but knowing how to implement the algorithms is just table stakes.
"Don't I practice these things when writing normal programs?"
Not in the same way. Competitive programming is about doing these in their pure form. In normal programming there are so many other things that it is hard to focus on the code, while in competitive programming all you have is code and then a really good test suite you can do to verify your solution once you think you are done. This way you practice a huge range of programming chunks really quickly, compared to trying to test them out and learn them in real world codebases.
Edit: Btw, last time I checked Leetcode didn't have many questions that stresses these important points, its mostly just useful to learn algorithms used in these interviews, it isn't good to learn programming. There are many good competitive programming sites to use instead. Leetcode is good if you want to pass interviews with minimal effort right now, but it isn't good if you want to get good. Also you just get good at chunks, you will still need to practice writing and structuring larger programs and solutions. But practicing that is way easier when you have mastered these chunks.
Out of curiosity. What would be the best way to learn these skills in your opinion?
What are these "many good competitive programming sites" that you recommend?
It has the widest selection and types of problems as far as I know but that was a while ago. It runs competitions all the time, the problem descriptions are well defined unlike leetcode which often misses a lot of requirements, it has way more kinds of problems than topcoder, you can test yourself against old competitions as if they ran real time to properly ensure you don't take too much time or accidentally cheat etc.
> What would be the best way to learn these skills in your opinion?
I think today it is hard to practice without competitive programming. Ideally someone would make a similar format pushing your limits like this but without so much focus on complex algorithms and maths, but since that doesn't exist competitive programming is what we are left with. The competition aspect is really important since it is how people push each others limits. It is easy to think "you can't get much better than this" when you just sit and code by yourself, but in programming competitions you see how fast and accurately others can solve problems, so you realize that you could get just as fast and accurate with a bit of practice.
And no, it is not memorization. Consider this easy problem which mediocre competitive programmer manages to solve but those below mediocre fails at (we can see that from how well people did on it in the competition):
There is no algorithm you have to know for that, it is just good old logic and some coding. It is really easy and I could solve in in a few minutes even my todays rusty self, but you can't memorize solutions to such problems, you just have to be fast both with the reasoning and the code. Note "mex" is not a standard term, it is just something they made up for that problem.
I feel the same way, but I also think that in all of the time I've spent thinking about it, I could have learned a bit of Vim or better typing, or something.
There is only a limited amount of time in life. It matters on what you spend it. Given that the way programming in industry is done is generally fucked up, working super hard at becoming super fast at doing that brand of programming can be a waste of time. Of course that depends on what your goals are.
Interesting POV. Can you elaborate on an alternative to the way of industry programming? Or more simply, list some of the ways in which industry brand programming is flawed?
For starters, even super big companies like Apple don't have any formal semantics for their APIs.
Of course there is a reason for that, it is just too hard with current tools for formal mathematics to achieve anything of the scale Apple needs.
So what will you spend your time on? Learn how to super fast crank out SwiftUI apps? Or solve the problem of doing formal mathematics properly so that companies can actually use it?
SwiftUI is pretty buggy still, by the way. Given that Apple controls its entire stack, why is that? Exactly, because they are following industry best practices, which are just not very good. Becoming super productive under these circumstances just means digging yourself deep into a local optimum that is not very good globally.
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.
The thinking pattern "I don't want to get faster, I prefer writing quality code" is a false dichotomy. The fastest programmers writes quality code, since quality code is much easier to get right and working with which are the most important factors for being a fast coder.
This is sometimes true. On a project long-term, will you keep velocity up by writing quality code? Yes. In certain, narrow areas (very "mathy" code, perhaps, that doesn't interact much with he world) might you go faster by writing quality code from the beginning? Maybe.
However, can one also go much faster by: not writing tests one ought to have written; ignoring security issues; ignoring input edge-cases; ignoring output edge-cases; treating a variety of variables as constant, or as having bounds that they actually do not; not writing enough documentation; et c.? Oh my god, yes. Of course.
Anyone who's ever seen a "we're really happy with the output of our outsourced team on this Rails 'app', they've gotten this MVP ready so fast!" codebase knows that's definitely also a way to be fast, and that a team writing actual quality code and not putting in a ton more hours couldn't have matched that team's "productivity", because they'd have been doing way more work.
OK, what you're saying definitely applies when we incentivize speed and forget everything else, or when we compare ourselves to others without knowing the whole story. But this current discussion is in the context of someone's personal goals to improve their own productivity from their existing baseline. Valuing that doesn't necessarily mean they have to stop valuing quality or maintainability.
If you tell me a programmer wrote a thing in a month, and another programmer wrote a similar thing in a year, I'd assume the 1 month project is easier to understand and work with.
Fast programmers writes most shitty code, yes, but that is because fast programmers writes most code period. I have seen nothing to suggest that an average slow programmer actually produces quality code when given the time, it seems to be the opposite, most slow programmers have terrible mental models and create even bigger messes if you give them the time to do it.
Are there slow programmers who produce quality code? Yes, but in my experience those are the exception and are even rarer than fast programmers who produce quality code.
If you tell me a programmer wrote a thing in a month, and another programmer wrote a similar thing in a year, I'd assume nothing about either, because there’s too many parameters at play.
If a project took only 1 month, I’d be very cautious with calling it easier to work with, because it likely means fewer tests (leading to lower velocity long-term) and fewer hours spent by other developers trying to understand it, and giving feedback on how to improve legibility.
Creating something quickly can be really important in specific contexts, but actually KEEPING something flexible to work with, hard to break, and easy to understand is more important when dealing with software that’s supposed to last over many developers and a long period of time.
Maintaining velocity requires you to spend more time on keeping the code base healthy.
I find the notion of being a fast programmer irrelevant in a business-context. Because there I think it’s more valuable to be a programmer that can ensure business goals are met on time, ensuring the correct problems are solved, ensuring contracts aren’t broken, while still keeping the code base professional (i.e. well-tested, clean, consistent).
Being a fast programmer is great and all, but being reliable is the more favorable trait if I had to pick one. Both require huge amounts of active training.
I agree there's not a natural tension between quality and speed, but the speed part is really hard to measure. You must consider the time of all future readers and maintainers of the code you are writing. Spending time to write a test or comment today is an investment that pays back in future fast iteration. Saving time by skipping code review, dashing off weird and confusing interfaces or variable names without revisiting them in a second pass, that type of thing is the opposite: it can appear to save you time today, but is costing you future time.
> Saving time by skipping code review, dashing off weird and confusing interfaces or variable names without revisiting them in a second pass, that type of thing is the opposite
Nobody here is saying you should do this, it is a strawman. Rather being fast means that you can revisit your interfaces 10 times rather than 2 times, spend more time thinking about your names, have more time to write tests, review everything several times before code review so no issues are found etc, ultimately producing much higher quality code.
It seems like you think this article is about "I write code quickly by not doing things properly", rather than "I practice to become faster".
I have no disagreements with the article at all. I only disagree with the idea that "doesn't understand the language/codebase/requirements" can only cause slowness. That condition is at least equally likely to cause the fast solution.
The real "10x programmers" I have known spend practically all of their time deleting and refactoring code. A handful of fake 10x'ers I have met in my career, who enjoyed a reputation of rapidly dashing off MVPs, were stone-cold idiots, one of whom wrecked an entire company with his 10x-ness.
... and with these architypes, the definition of a 10x-er would be - One who pounds out the solution in an hour because they understand their language, codebase, and requirements.
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've done tough physical labor, and repetitive physical labor. They may wear out the body (or may invigorate it, depending on the load), but the mind is fresh even after 8+ hours, in my experience. And it feels good.
After six hours of typey-typey in front of a screen I feel used up. Worthless. Dead. And that's a very good day—four is more typical for "how long can I do computer work before I just want to curl up and do nothing until I fall asleep?". I mean four hours of actually working, mind you, not screwing around, but still.
I know for a fact I don't have a general work ethic problem that prevents me from going past 4-6 hours of computer work in a day—I have a "this particular shit—computer shit—sucks the life out of me like nothing else" problem. Always been that way, even when I was young. Work? I'll do it 'till I drop and feel good about it. Computer work? Uuuuugh, if I have to, I guess, but I'll hate it the whole time and feel like shit when I'm done, which, BTW, won't take long.
But, anything I could do that wouldn't involve sitting in front of a computer much of the day would mean a 60+% pay cut, so... here I am.
I've always had a somewhat weird work process. I probably spend a large amount of time just plain fucking around. But it's interspersed with exploring solutions to the problem.
The fuckaround time is important. It lets me re-evaluate the problem with a clearer mind.
Oftentimes this looks like I'm doing nothing for a day or two. Then by day 3 I just write everything that needs to be written in an hour or so.
Now there may be bio/psychological differences here, you (and I) seem to enjoy physical activity. Some might very well not.. I'd say it mostly depend on how the activity fits the person too (speed, effort, balance of type of efforts, sense of improving skills and not just mindless sweating).
I like computing work, but it depends the context, if it's grinding through obscure and unreliable program semantics .. it's less fun. Unless you approach it mathematically (like scientific inquiry trying to discover how it may work), it's gonna be grinding.
If you have simple building blocks and you can just unleash creativity.. then it's different, it's pleasurable. You're the only limit.
Now even in that case, my best days is when I can alternate thinking hard, and sport. 20 min of jogging whenever I'm stuck on a feature branch helped me a lot getting stuck mentally and emotionally.
And in a way, thinkers rarely sit down, they move around, it's vibrant.. it's not just grinding on a keyboard.
I think when you begin to work on something, there's the phase where you are "stuck" and need understand the problem well enough to generate an acceptable initial idea to get started. To me, this is the draining part. However, once I have that understanding and can start exploring it, I can easily work for hours; it still requires mental energy and is still draining if I go overboard and don't stop in time, but it's not the soul-crushing kind that being stuck on a problem can be.
I'll add that it's different when I'm coding and have full autonomy - I could practically go all day on personal projects.
When I have to yield to hierarchy, maintain "agile" processes, and put up with other bs, it drains the work drive and gets tiring real quick. It's not just toll from hard mental labor but also from bad environments - which can exist in any industry.
It does teach you about effort and pragmatic productivity, which is a general skill.
I've spent years trying to design code that would give me some benefits but in reality they were taking too much time for low use-case value. When you have time pressure, you write code very differently. You aim at the smallest patch that can solidly implement a feature. It minimizes code changes, patch size, bug introduction, time spent, client happiness. Also mentally beneficial to see tiny regular results.
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?
For sure. In that context, the engineer that got the product to work before the startup ran out of money and shut down by deciding to hack around some issues rather than "do it properly" is the more productive engineer. Another way to think about this is the engineer that better optimizes the expected present value (sure, there might be a pretty wide distribution of outcomes). At the very least I feel like this business/economic context is very important, and often ignored. Without it it's very hard to say because in a different context the engineer that creates the very same hack maybe just cost the company a lot of $'s in future maintenance work.
My point is more about the possibility that a big chunk of future cash flow is entirely independent of engineering work, at least for some reasonable bounds for what constitutes "engineering work" (e.g. you could argue that an engineer ought to judge whether their time is better spent cold calling potential clients or finding office space to rent, but those I would call "out of bounds"). Any easy example to illustrate this would be two engineers who each develop a functionally identical app for two different startups, but at one startup the founder later embezzles company funds, gets arrested, and the whole company falls apart, while the other company goes on to be successful. Was one engineer really more productive than the other in any meaningful sense?
That is a good point. I guess for the purpose of this definition we need to make some more assumptions. But decoupling software development from the business completely is going too far the other way.
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.
No, you have it backwards. The original claim about “10×” engineers is in the book Peopleware. The author specifically claimed that they had observed at least an order of magnitude difference between the best and the worst software engineers. This is very much talking about variation between individuals, not comparing the extremes to the average. The average engineer is I guess somewhere around 3×, but note that this was a qualitative statement rather than a quantitative one; I chose the geometric mean because we are talking about multiples, but we shouldn’t forget that this isn’t based on concrete numbers. The average could be 2× or 5× or anything else.
Note that they are referring to the worst software engineers that could keep their jobs; these people probably still had net positive productivity for their companies. Note also that this was across many companies that the author had consulted for; any individual company likely had a narrower range of ability. Because of company policies, management styles (aka manglement), mistakes, cost–cutting, or whatever, there are companies that absolutely fill up with 1× programmers. Also, the best and worst programmers are not necessarily at the same stage of their career; the 10× engineer is much more likely to be a greybeard who has seen it all and knows how to get results, while the 1× engineers are much more likely to be fresh out of college.
The whole point of the book is that we can deliberately set up an environment where engineers are allowed to grow and succeed, or we can set up an environment that drives away anyone with skill. If management can do the former, then the company can succeed. Too often management sets up a system that is actively hostile to success, and then has to hire consultants to come and tell them how to fix it.
Great, thanks for the detailed clarification — I wasn't aware of the book reference: it was my impression that everybody compares to an "average engineer" when talking about 10x, so perhaps it has entered "common knowledge" as a misinterpretation (or maybe it's just my misinterpretation, which is most likely).
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.
And yet this advice is not necessarily wrong. We spend a significant fraction of the calories we eat operating our brain. I have personally measured a significant increase in my ability after a good lunch compared to just an hour or two prior.
"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.
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.
> 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.
I am mentoring Junior Developers, working students, trainees and interns who are at the very beginning of their career, they don't have _their_ setup yet. I watch them do something very tedious, and then I point out that there is a shortcut or IDE function for that. They have always been grateful, so far.
> And why does one even need to know vim at this point in time?
I was thinking about this a lot last night. I have learned drumming, bass guitar, guitar and I am learning piano now, so I may not be an authority on practicing, but I know that practice usually leads to a certain degree of improvement.
And very early in my career, I also practiced coding, more specifically I practiced using the IDE, and later I practiced using vim.
Both of these things give me confidence in the "writing and editing" aspects which let me focus on the other aspects of coding, like the abstract/ideas and the stack.
So I don't think it's important to know about vim, but it is important to at some point have deliberately practiced with the tools one uses daily for years to come.
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.
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?
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.
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.
It is still useful for you to know. That "overhead" often does very little to advance your career or even just advance _you_ professionally. And until you measure how much overhead you're incurring, you wouldn't even know.
Much like how people didn't know they're spending 4+ hours on Instagram and YouTube every day until Apple started cataloging and surfacing phone usage. When I saw my own usage I was horrified, and I have cut it down significantly since then, and closed FB and Instagram accounts entirely.
To translate that into the professional domain, there may be some optional bullshit activities you participate in solely because you don't see their cost. You'd be able to identify them and cut down on your participation, possibly either improving your career situation, or improving work/life balance, or both.
There was a time when I worked at a BigCo where there was so much bullshit during the day, I only could do work from home in the evenings. So I worked ~14 hours a day for years - 8 hours spent on bullshit, then another 6 at home on actual work. That wasn't fun at all.
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.
> In practice, if you improve your productivity at work, it's going to be mostly for your employer's benefit (other than bragging rights and some personal satisfaction).
This is true if you're bagging groceries, but certainly not true for most software developers. To quote the post again:
"I'm sympathetic to the argument and agree that upper management and shareholders capture most of the value from work. But as much as I sympathize with the idea of deliberately being unproductive to "stick it to the man", I value spending my time on things that I want enough that I'd rather get my work done quickly so I can do things I enjoy more than work. Additionally, having been productive in the past has given me good options for jobs, so I have work that I enjoy a lot more than my acquaintances in tech who have embraced the "antiwork" movement."
> But GP is making a point that it should be perfectly acceptable to not want to (significantly) improve at work while meeting the bar for staying employed.
I don't see any point in Dan's post against this idea... it's the GP who is elevating this into a moral choice, i.e. from his/her response to mine:
> Yeah but he doesn't recognize that his entire argument is personal choice elevated to moral imperative.
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.
While I agree with your point that it should be perfectly acceptable to not invest oneself fully in getting the best performance in a job as long as you can do the job you are hired for, I think you are mistaking OP's statement for an absolute one: these are from an opinion piece on a personal blog, and the arguments they bring up resonate with them.
Nowhere did I see any judgement for those who don't agree with them: they merely proclaim what you can easily achieve with deliberate observation and practice and how it matters to them.
You will get fired if you don't get enough done at work. Higher productivity means you can accomplish enough tasks to not get fired in less amount of time.
But that's just taking the moral argument another level deeper. Why should a person's leisure be subject to the whims of employment?
> you can accomplish enough tasks to not get fired in less amount of time.
And how many employers will look at the work you got done in less time and tell you to go home for the rest of the week because you've finished everything assigned?
> But that's just taking the moral argument another level deeper. Why should a person's leisure be subject to the whims of employment?
This isn't a philosophical discussion, fact is that either you produce enough value at work or you get fired.
> And how many employers will look at the work you got done in less time and tell you to go home for the rest of the week because you've finished everything assigned?
You don't have to tell them you are done, you can just relax and browse HN or whatever. Being very productive at work gives you a lot more freedom at work, even if that freedom isn't 100% fairly allocated to you it still improves your situation.
> Why should a person's leisure be subject to the whims of employment?
Even the leisure time of fish and rabbits are subject to eating leaves and kelp. Time is useful. Your work may give 100x more leisure time to thousands of people. And even if it doesn’t, it’s still necessary - who will maintain the back ends for the porn sites? The mind reels to think of what would happen if Netflix’s sysadmins became simple bumbling 1xers. So many kdramas unwatched! One slip up in 2010 and million basic whitegirls not knowing be soft touch of The Office!
every moral imperative is also a personal choice. And honestly, if being a better coder saves 100k people a few hours in wasted time once, that’s ten person years - coming close to moral imperative! If your productivity tool’s new feature enables some engineering collaboration that builds a new bridge in Kenya, that saves a thousand person years?
I mean, you could choose a different employer with lower expectations or reduced obligations if that's an option where you live. But no employer is required to keep you employed if you don't get your work done. It may be harder to fire people in some places and in some industries, but it's rarely impossible. If you want to be able to have leisure and enjoyment, you probably need money, which means being employed, and to remain employed you need to meet your obligations.
So be unproductive and risk getting fired but go home at a reasonable time. Be unproductive and work long hours to meet the obligations and not get your leisure and enjoyment. Or be efficient and go home at a reasonable hour and have your leisure and enjoyment. I choose the third, because it's sensible. Unlike my 90-hour workweek colleagues who stress about everything.
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.
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'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.