[HN Gopher] Some reasons to work on productivity and velocity
___________________________________________________________________
Some reasons to work on productivity and velocity
Author : davidmckenna
Score : 297 points
Date : 2021-10-15 19:28 UTC (1 days ago)
(HTM) web link (danluu.com)
(TXT) w3m dump (danluu.com)
| Rainymood wrote:
| Is there any version of Dan Luu's website with just a _hint_ of
| css? Plain HTML is unreadable imho, content is usually great but
| I struggle to get through it because it 's so damn hard on the
| eyes.
| rlayton2 wrote:
| On Firefox, reader view made it look quite nice and readable.
| minihat wrote:
| The actionable advice in this post: 1) Track where you spend your
| time 2) Apply deliberate practice to improve where you are
| weak/slow
|
| I am typically energy constrained rather than time constrained,
| as I imagine is the case for many working in engineering/science.
| Yet, the author's advice remains useful. Deliberate practice
| should provide gains to both time and energy costs of tasks.
|
| For me most productivity advice, including this post, ultimately
| reduces to "try to get better at your trade, and track your
| progress".
| Jensson wrote:
| > I am typically energy constrained rather than time
| constrained, as I imagine is the case for many working in
| engineering/science.
|
| I've found that being energy constrained is much easier to
| track than time constrained. You notice instantly when a task
| takes a ton of your energy, you start hating the task so you
| work hard to ensure you don't have to do the task any more.
| Compare that to someone who mostly wastes time, they'd happily
| sit and waste tons of time every day since you don't really
| feel your time slip away.
| graperapist1480 wrote:
| Energy constrained? That's odd. Just eat more? CICO after all.
| Maybe guzzle some lard? It's very dense.
| joshuacc wrote:
| "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.
| db48x wrote:
| 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.
| agent327 wrote:
| "Energy constrained" doesn't mean he lacks sugar, it means
| his brain isn't letting him do the work anymore because it is
| in the process of burning out.
| minihat wrote:
| Yes, this is my intended meaning. I am a PhD student
| working on my thesis. After a certain number of hours of
| doing mathematics or algorithm design, I have to switch to
| easier tasks like reading papers in a domain I'm familiar
| with, or documenting code.
|
| While I cannot speak for anyone but myself, my performance
| on highly challenging tasks is capped at 4-5 hours per day.
| At that point, it is better for me to switch to lower
| hanging fruit.
|
| If I am feeling especially inspired, sometimes I'll put in
| a 12+ hour day of hard work. Rarely, even two or more in a
| row. But inevitably, I will feel extra burned out in the
| subsequent days.
| hardwaregeek wrote:
| 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.
| Darkstryder wrote:
| 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.
| jkhdigital wrote:
| > 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.
| Darkstryder wrote:
| Thank you.
|
| 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.
| Jensson wrote:
| 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.
| jkhdigital wrote:
| 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_.
| Jensson wrote:
| > 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.
| zarkov99 wrote:
| 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.
| auggierose wrote:
| 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.
| fddhjjj wrote:
| 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?
| bigbluedots wrote:
| Not the poster, but IMO we are craftspeople being made to
| work like assembly line workers.
| peytoncasper wrote:
| I would argue that assembly line workers were once
| craftspeople.
|
| Craftsmanship still exists, but it's specialized and
| focused on products that can demand the higher price.
|
| Is this not the same with software?
|
| CRUD work is almost infinite and demands higher output at
| the expense of quality.
|
| Contrast that with unique OSS projects, and defining
| product features.
| auggierose wrote:
| 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.
| crate_barre wrote:
| 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.
| megameter wrote:
| 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.
| crate_barre wrote:
| I'm fascinated by who is downvoting you without an
| explanation.
| rsj_hn wrote:
| 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.
| rhapsodic wrote:
| _> I don 't think you're allowed to reply to a comment
| and also downvote it._
|
| Not true. Now I will remove the down vote I just gave you
| to test your claim.
| waterhouse wrote:
| > I don't think you're allowed to reply to a comment and
| also downvote it.
|
| Close. You're not allowed to downvote a comment that is a
| reply to your comment. (Or a comment >24hrs old, or if
| your karma < 500 (IIRC).)
| porknubbins wrote:
| 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.
| heisenbit wrote:
| 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.
| Zababa wrote:
| 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.
| Jensson wrote:
| 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.
| ZephyrBlu wrote:
| > _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.
| Jensson wrote:
| 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.
| ZephyrBlu wrote:
| 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.
| Jensson wrote:
| 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.
| ZephyrBlu wrote:
| Interesting. We don't track code reviews as far as I'm
| aware, and we use GitHub so you just get an email if
| you're tagged as a reviewer.
|
| I would say it's not uncommon to have to wait a day for
| reviews.
| Jensson wrote:
| 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.
| tharkun__ wrote:
| 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.
| kthejoker2 wrote:
| 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.
| zaptheimpaler wrote:
| 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.
| DeathArrow wrote:
| 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.
| jmchuster wrote:
| 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.
| tessierashpool wrote:
| 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.
| bckr wrote:
| > 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.
| man_from_space wrote:
| 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
| jodrellblank wrote:
| 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._"
| vymague wrote:
| > Taylor's books
|
| What is the book title? This article or the previous Dan Luu's
| "Some reasons to measure" doesn't seem to mention his name.
| Googling "Taylor measure" just gave me some pure math
| textbooks.
| comicjk wrote:
| https://en.wikipedia.org/wiki/Scientific_management, also
| known as "Taylorism" after Frederick Winslow Taylor. I don't
| think Dan Luu is saying anything like this, though.
| samth wrote:
| Dan Luu is definitely not someone who never learns anything new
| or who doesn't think differently.
| xupybd wrote:
| 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.
| caffeine wrote:
| 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.
| [deleted]
| andrekandre wrote:
| > Any tips on how to get faster?
|
| quality
|
| take the time to write quality code, design quality systems,
| debug things the right way, don't rush, take your time
|
| before you know it, writing good code (and systems) becomes
| second nature and you will get faster as a result
|
| in other words, fast people/teams know how to be fast because
| high quality is second nature and they don't waste their time
| fixing bugs and retesting again and again
| caffeine wrote:
| How do you actually deliberately practice and improve
| programming?
|
| What about data science / research?
|
| Curious if anyone has suggestions.
| jdlshore wrote:
| 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.)
| es7 wrote:
| 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.
| jeffbee wrote:
| 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.
| Jensson wrote:
| 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.
| Dudeman112 wrote:
| >The fastest programmers writes quality code
|
| I've spent effective _years_ of my life unfucking code
| written by fast programmers because no one can extend,
| change or understand their code.
|
| As far as I am concerned the probability that a fast
| programmer also writes quality code is approximately 0.
|
| There are outliers out there. But if you tell me someone
| is a fast programmer I'm not betting they write quality
| code.
| Jensson wrote:
| 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.
| paleite wrote:
| 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.
| jeffbee wrote:
| 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.
| Jensson wrote:
| > 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".
| jeffbee wrote:
| 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.
| handrous wrote:
| 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_.
| Jensson wrote:
| That has to do with managers being bad at telling how
| productive a team is, it is a completely different
| problem.
| tdeck wrote:
| 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.
| [deleted]
| alfiedotwtf wrote:
| ... 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.
| throwawaygh wrote:
| There are also a freaking ton of mediocre programmers who
| take three days to pound out flawed solution.
|
| See: the recent story about Missouri revealing SSNs of
| teachers.
| personjerry wrote:
| > 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.
| bckr wrote:
| > "How fast can you implement a chat widget" doesn't allow
| for the exploration of alternative ways to engage with
| customers
|
| If you make a list of alternatives, and you don't know
| which one is the best, having higher overall velocity
| allows you to try more options.
| ltbarcly3 wrote:
| 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.
| necovek wrote:
| 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.
| db48x wrote:
| No, you have it backwards. The original claim about "10x"
| 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 3x, 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 2x or 5x 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 1x programmers. Also, the best and worst programmers
| are not necessarily at the same stage of their career; the
| 10x engineer is much more likely to be a greybeard who has
| seen it all and knows how to get results, while the 1x
| 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.
| necovek wrote:
| 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).
| db48x wrote:
| It's a very, very common misinterpretation. People see
| the number 10x and immediately go to the straw-man of the
| mythical average programmer.
| Jensson wrote:
| The study they referred to removed all cases where the
| student didn't finish the project, so it doesn't have any
| data points for the worst engineers.
| karmakaze wrote:
| 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.
| friedman23 wrote:
| 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.
| agumonkey wrote:
| after doing a few kinds of jobs: - food
| retail: producing hundreds of sandwiches an serving hundreds
| of customers back to back, teaches you about productivity
| - landwork: 8000 picks per day teaches you about work
|
| maybe i'm masochistic, but whenever I see people relaxed at
| work, neither doing much nor thinking much, I consider it's
| not work. There's no difference between what they do and me
| at home chilling.
| handrous wrote:
| 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.
| agumonkey wrote:
| 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.
| sumnole wrote:
| 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.
| chousuke wrote:
| 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.
| bcrosby95 wrote:
| 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.
| Graffur wrote:
| Woah - that really sucks you're in a job that you hate.
| For your own health you should try something else that
| you don't hate.
| Graffur wrote:
| None of that experience translates to programming work imo
| agumonkey wrote:
| 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.
| Rapzid wrote:
| How much sleep do you get?
| friedman23 wrote:
| My problem isn't sleep, my problem is skipping meals which
| screws with my energy. I always get at least 8 hours of
| sleep.
| gliese1337 wrote:
| Somehow, this never really clicked for me before.
|
| Mind blown.
|
| Thanks!
| YZF wrote:
| 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.
| tshaddox wrote:
| > 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?
| YZF wrote:
| 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.
| tshaddox wrote:
| 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?
| YZF wrote:
| 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.
| foolfoolz wrote:
| productivity is delivering value to your customers
| crate_barre wrote:
| 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.
| Graffur wrote:
| It's measured by tweeting, github social actions and giving
| talks at conferences
| euske wrote:
| 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".
| guhsnamih wrote:
| As this seems to be about productivity from a respected person, I
| want to make sure I get the important ideas and I have tried. Is
| there a context in which this article must be read? Is it a
| commentary to another? Neither its introduction nor its
| conclusion seems to capture all of its ideas it is about. I know
| it is not meant to be readable but I'll appreciate any help.
| Jensson wrote:
| It is related to this article:
|
| https://news.ycombinator.com/item?id=28879240
| guhsnamih wrote:
| Thanks! Your reply was helpful in giving the background
| although the background itself wasn't so helpful. Just to be
| sure, is the sole purpose of these articles to suggest why
| (and not how) to improve productivity? I think I am looking
| for the secret to 10x productivity which is still hidden
| somewhere inside those articles. Or is it?
| jmchuster wrote:
| 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.
| 8b16380d wrote:
| 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?
| raglof wrote:
| iwouldsayiagree
| a_e_k wrote:
| > 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.
| 21eleven wrote:
| > _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.
| mental1896 wrote:
| >you should probably leave your job or not take it in the first
| place
|
| sounds like a decadent rationalization of some kind.
| joe_the_user wrote:
| _If you really are not comfortable with the consequences your
| personal labor you should probably leave your job or not take
| it in the first place._
|
| Oh really? I don't think you're going to get anything like sort
| of "ethical" behavior until there's something like UBI
| implemented. Until then, people are going to hold onto high
| paid jobs they don't like, especially if they can slack off at
| them.
| sureglymop wrote:
| 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_.
| Afforess wrote:
| > _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.
| ChrisMarshallNY wrote:
| 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.
| m0zg wrote:
| As someone who also tracks time in some amount of detail (to bill
| clients for it), communication, and _written_ communication in
| particular takes a surprising amount of time. All those Slack
| threads you might not even think twice of engaging in can easily
| destroy half your working day, even if you ignore the cost of
| context switching. Emails take longer than you think. Design docs
| take _much_ longer than you think. Code reviews take longer than
| you think also.
|
| For me at least coding seems to take less time objectively than
| subjectively, but it's also quite obvious that most of my time is
| not spent on coding, sadly. A good chunk of it is completely
| unproductive bullshit that simply has to happen because that's
| how the company chooses to operate. I tell them it's not the only
| way to do things, but they insist on wasting ~1.5 person days a
| week on "standups" and "scrum" (the team is 12 people, excluding
| me). They could _easily_ move 50% faster if they shed that
| bullshit and just gave people sizable tasks and some degree of
| autonomy and personal responsibility. Instead it's down to who
| can _appear_ the busiest during standup.
| spaetzleesser wrote:
| "Design docs take _much_ longer than you think. Code reviews
| take longer than you think also."
|
| I work in medical devices and this is so true.
|
| A thorough design doc or a thorough code review takes a very
| long time. It actually may take as much or more time as the
| actual coding. Somehow we never account for this time in
| planning so either things are rushed or the project will be
| delayed significantly. Add to that the fact we don't have good
| tools either for writing docs neither or for code reviews.
| m0zg wrote:
| 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.
| spaetzleesser wrote:
| I have done this but management can't accept that the
| mandatory overhead is taking that much time. They just
| don't want to hear it.
| m0zg wrote:
| 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.
| vymague wrote:
| 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.
| cuddlecake wrote:
| Recording oneself is also a common strategy for improving
| musicianship.
|
| When I was drumming, it sometimes helped me see exactly where
| my movements where improper, hesitant, or
| superfluous/exaggerated.
|
| When I look over junior developers' shoulders while they code,
| i kind of do something similar, where I point out small
| improvements in their "movement from one state of code to
| another", like IDE functions for refactoring, keyboard
| shortcuts to delete a line or to go back to the previous
| editing position.
|
| (I always wonder, when is the right time to introduce someone
| to vim?)
| sureglymop wrote:
| 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.
| cuddlecake wrote:
| 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.
| chousuke wrote:
| 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.
| DeathArrow wrote:
| I think that being fast at coding is akin of being fast working
| on an assembly line. This might matter a bit, however I don't
| strive to do that. If it comes naturally with experience good, if
| not, I don't make a goal from it.
|
| Churning out code is something that bores me. I'm interested more
| in problem solving, computer science part of programming,
| optimizations, research, discovery, architecture.
|
| I am not interested so much in how I do this common thing fast,
| but rather in how I solve this hard or interesting problem. If a
| problem is already solved, can I find a better solution? How fast
| the code will run? How robust it will be?
| crate_barre wrote:
| I'd also add that it's something many of us no longer need to
| prove to ourselves. When you are new, you have to at least
| prove to yourself once that you can be this 'machine'. Once
| you've proven it, how is that a goal anymore? I'm not
| interested in that anymore either.
|
| There are more optimal ways to being this machine than just
| slamming one's head against a keyboard, the proverbial work
| smarter, not harder.
| lngnmn2 wrote:
| 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).
| crispyambulance wrote:
| > 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.
| ptr wrote:
| 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?
| aozgaa wrote:
| What methods should be used to measure/track personal
| productivity and find areas for improvement?
|
| The only example I see in the post is a typing test.
|
| One comment mentioned a time-tracking app called Harvest.
| mrcode007 wrote:
| 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 :)
| woah wrote:
| 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?
| [deleted]
| hyperpape wrote:
| 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.
| renewiltord wrote:
| My first thought was that people were linking related stuff.
| But the two posts were written within a day of each other.
| Perhaps one was inspired by the other or perhaps the authors
| know each other.
|
| Dan Luu is a pretty prolific blogger / tweeter about
| engineering and this one is the later blogpost. I find it
| unlikely it was a "repurpose".
| dochtman wrote:
| Both bloggers know each other (this is pretty obvious if you
| read some of their online stuff), so Dan Luu probably
| reviewed the other post early and thought it interesting
| enough to add his own take.
| renewiltord wrote:
| Yeah that makes sense. Sounded like the most likely
| explanation honestly.
| meowface wrote:
| (The post, for anyone curious:
| https://news.ycombinator.com/item?id=28879240)
|
| Yeah, it's very similar in a lot of ways.
| TeeMassive wrote:
| Press F9 to toggle reader view.
| cratermoon wrote:
| 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.
| saeranv wrote:
| 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.
| cratermoon wrote:
| 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.
| Jensson wrote:
| 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.
| cratermoon wrote:
| 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?
| graperapist1480 wrote:
| > 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!
| Jensson wrote:
| > 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.
| graperapist1480 wrote:
| 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?
| necovek wrote:
| 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.
| necovek wrote:
| 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.
| saeranv wrote:
| > 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.
| jai_ wrote:
| The entire point of TFA is that the ability to go fast is a
| force multiplier for being productive in the first place.
| andrekandre wrote:
| > the ability to go fast is a force multiplier for being
| productive
|
| and what is the force multiplier for being fast?
| cratermoon wrote:
| But to what end?
| Jtsummers wrote:
| To get your time back while still meeting professional
| obligations, at least that's my "end" in being productive.
| cratermoon wrote:
| > while still meeting professional obligations
|
| The unstated and unexamined assumption here is that
| professional obligations trump leisure and enjoyment. Do
| they? If so, why?
| f00zz wrote:
| Do you have a trust fund?
| cratermoon wrote:
| 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.
| Jtsummers wrote:
| 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.
| orangecat wrote:
| Presumably you're working on something that is intended to
| benefit somebody.
| vasco wrote:
| Working on the right thing means driving in the right direction.
| Velocity is the speed at which you get there. Anyone that says
| velocity doesn't matter is wrong and there should be no debate.
| somishere wrote:
| 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
| jmchuster wrote:
| 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.
| bullen wrote:
| 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)
| rlewkov wrote:
| I think they do matter from the p.o.v. of the people footing the
| bill for the results. I have yet to work on a product/project
| where mgt doesn't care about when it gets done and how much it
| will cost. Call it productivity, call it velocity, but the people
| paying care and someone always pays.
| crate_barre wrote:
| 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.
| jorangreef wrote:
| 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.
___________________________________________________________________
(page generated 2021-10-16 23:02 UTC)