Slow Down, Finish Faster | Hacker News Reader

Slow Down, Finish Faster

briandicroce.com

205 pointsbdicroce86 comments

Define "finish". For that matter, define "faster".

When I was working as a junior doctor, I had colleagues who "saw" 10 patients in the space I saw 3.

Whenever I was on call at night, I could spot the patients who were "seen" by those colleagues, because it was always the patients who crashed or needed their meds re-writing to remove the allergy risks or needed to have their bloods ordered and taken, or even had to be re-clarked from scratch because the history and exam were utter bullshit, not to mention dangerously so. (I once re-clarked an old lady who was admitted for confusion affecting her ability to communicate and was about to receive all sorts of scans and radiation. When I talked to her, it turned out she had just lost her hearing aid and couldn't hear anything.)

Still, it was always the "tenners" who were praised.

(PS. I no longer work as a doctor. Fuck that shit.)

(PS2. Obviously this isn't unique to medicine. I have the same problems inheriting crappy untested code now, haha.)

Ha. Reminds me of my grandmother. She's quite old now but the doctors told us she had dementia. One day Mum was telling me about it and I said, "make sure they understand she's deaf, and will just smile and nod if she doesn't hear properly."

Next appt, mum goes with her and lo and behold, she doesn't have dementia, she needs a new hearing aid.

(deafness runs in my family, if you're interested: https://medium.com/@veb/my-journey-to-a-cochlear-implant-8ce... - had to remove part 2 because lawyers...)

What happened next, and why did lawyers make you remove part 2?

Pesky lawyers thinking they can really make stuff disappear from interwebz.

https://web.archive.org/web/20170112221346/https://medium.co...

> Still, it was always the "tenners" who were praised

You figure why "we are rolling down" (loss of quality as a value, "decadence" - loss of purpose (what do those colleagues think they were there for?), loss of good sense, loss of perception).

I have already narrated at HN the story of the evaluation in which the subject was criticized for being not as fast in responding as the colleague - who gave wrong answers.

I think I have also read in these pages our moderator DanG noting the qualitative difference in general separating prompt posts and meditated posts. It's not that the concept of "reflection" is gone, it is that it has generally declined. Surely, over ten years of "bad school" social networks helped that. Plus, economic and sociopolitical factors promoting the use of cheaper personnel in looser monitoring.

Edit: plus, overly-literal-interpreting-people dealing with overly-sloppy compilers of (Key) Performance Indicators...

I don't think there is something inherently bad about social media. I mean Tv / Radio sped up the time from an event to when people hear about it - and the first time people here is when people shape their perception of the event.

Hence if your side of the story is out at the same time as the news of the event, you get a good chance of shaping people's perception of the event.

If you wait a week, day or hour, it may be too late.

I am not sure it is good bad or other. Maybe it does not matter to you that millions hear one side if the "right" people hear your more considered side. (perhaps we call that lobbying)

Speed has meant it's harder to get a considered reaction. But then again, by middle age most things in the world are either things we have seen before so have an instant reaction, or frankly are not worth reacting too.

( Name checks ;) )

> I don't think there is something inherently bad about social media

Good that that's your opinion, just I hope you have not understood that is the position of the parent post, which wrote «over ten years of "bad school" social networks helped [the decline ... of the concept of "reflection"]». It meant that people have been encouraged to "fast respond", which boosts the diffusion of low quality. Lack of depth, cheap processing...

> the first time people here is when people shape their perception of the event

And duly reflection, the point, is there so that the new informational members in the Weltaufbau are well criticized before getting entrenched.

Why should have «speed [in the time from an event to when people hear about it] ... meant it's harder to get a considered reaction»? One's reaction to information is not really a function of the distance in time of the event in the information. The problem noted is with those ethological drives against «considered reaction».

I miss some of your points - but the last paragraph is fair.

I assume by emphasising "bad school" you say that the parent was also saying social media not inherently bad, but the way it was implemented was?

I think that we could design (regulate?) better social media (I have high hopes that something similar to the "this looks like anti-vaxxer posting, here are some links to scientific consensus on the issue) would help move us from facebook to wikipedia. But I may be blinded by my own privilege

> I miss some of your points

I will rephrase a core concept more plainly: people are supposed to be trained to be "reflective": whatever input (intellectual, emotional, informational, ideal - so external or internal - etc.) they get, it should be put on a buffer with a label "tentative, provisional, waiting for further validation, digestion, development". Whatever incites to shallowness, cheap, immature thought, reaction etc., is against civilization.

> social media not inherently bad, but the way it was implemented was

Yes indeed. Some environments clearly "point towards evil".

I was mainly thinking about incitation to rush, quick consumption, construed emotional response etc. But already the policy of one of the biggest boards out there, encouraging upvoting and downvoting according to "feeling", (mis-)educates people to give value to a knee-jerk reaction (which should at most be there as a preliminary orientation) and consolidate it through the psychological trap of a statement of position, and create identities in the deterior sense, self-images based on stagnating undiscussed assumptions.

> design (regulate?)

You need to promote, through function and policy, better examples and work recursively from them (let them lead and criticize). In fact, the very example you provide is all about credibility of the proponents.

> Still, it was always the "tenners" who were praised.

I believe the US does not align financial incentives with the quality of care provided.

Healthcare in the US is a runaway scam: https://ourworldindata.org/grapher/life-expectancy-vs-health...

There has been a massive change in US healthcare from a “fee for service” payment model to a “value based care” payment model over the last 10 years.

https://www.cerner.com/perspectives/between-fee-for-service-...

https://www.decorm.com/understanding-fee-for-service-and-val...

There are many posts online about doctors and pharmacists about the pros and cons of tying their reimbursement to patient outcomes.

That seems to fly in the face of the private health insurance system that many of us are forced to use. I believe there are many more value based healthcare situations now than before but suspect that it’s still a tiny fraction of healthcare delivery in the US.

25%+ of US residents receive taxpayer funded healthcare, via Medicare, Medicaid, Tricare (military), or other government programs. I think electronic medical records will only accelerate it to non taxpayer funded populations as it will greatly ease the ability to track data even when switching from one managed care organization to another.

Unrelated question. My girlfriend is an anesthesiologist and she is quite distraught with the fact that she is being payed less than me for working significantly more hours on a job with vastly more responsibility and risk (I work on embedded devices which have 0% chance of causing injury or death). She doesn't want to consider career switch because she already invested 12 years of her life into medicine. I am supportive of course, but to me this is a clear example of a "sunk cost fallacy". How did you get over that?

Based on the 12 years of education, I am guessing you are in the US. Median anesthesiologist income is ~$400k/year.

The odds of her earning similar, even per hour, if she switches to programming may cause sticking to being a doctor make more sense.

Nope, Eastern Europe. We both got pretty good education (even got to study abroad for a few semesters) and it was free for both of us, but her annual pay is around 30k$ while mine is around 35k$ (the median wage is about 15k$). Its really easy to earn more than that if you remotely work for a German or American company, but as a doctor you cant do that unless you move (not an option).

Oh, my bad. Yes, that changes things quite a bit. I am surprised it takes 12 years in Eastern Europe. I thought it was ~8 years in Europe.

6 years college minimum. Mandatory one year of general practice and then you can apply for specialist education. Specialization can then take years to begin, but it can also start right away depending how lucky you are and you do it for five years minimum. So that makes it 12 years minimum. After that, most hospitals require you to stay working there for another 5 years otherwise you have to pay for specialization school (about 30k$). After that, you are free to live your life :)

The sad truth is that your girlfriend in the wrong country. It's the same in mine, where many doctors move to nearby countries where they can earn many multiples more.

I am assuming you are an engi. If so, it's about the leverage. Her time, responsibility, and risk is 1:1. An engi's time can lead to exponential returns, and mistakes can lead to exponential disaster.

Leverage just set the ceiling, then you enter on offer and demand kind of world. Software developers just have it good in 2021.

Also, if OP lives in a low income country, he has better options to sell himself compared to a doctor, normally constrained to the local market.

Not sure what you mean by "exponential", but mistakes by an anaestheseologist can certainly lead to disaster. Like, people can die. I'd think at least for the people doing the dying that's quite "exponential" enough. How is the possibility of killing people if you make a mistake on the job more "risk is 1:1" than for a software developer (or "engi", as the trendy kids apparently call it nowadays)?

I told myself exactly what you just said. That this thinking was effectively the "sunken cost fallacy".

In the end it was about prioritising my personal satisfaction and 'happiness' over what a more conservative mind would think 'I should do' (one aspect of which was the financial sense). I am not super rich nor super successful at my choice of profession now (partly because I'm 10 years older than everyone else in my position right now, which can be an issue in itself), but I largely enjoy what I do despite the stressors and pressure that my particular position puts me in, and I'm trying to use my richer experience to 'catch up' career-wise as quickly as I can, so to speak.

I's not a black and white decision of course, and I'd be lying if I said I have zero doubts. There are still moments where I think "what if I hadn't left". Would I have been happier staying miserable but with lots of money to choose my preferred form of misery? :p Is it better to be 'poor' (by comparison) due to cost of the 10-year career lag in the new field, but in a more fulfilling profession? In general, 9 times out of 10 when I think about it I'm happy it was the right decision and not one that I regret. But there's still that 1 in 10 which nags you, especially when you get together with your old colleagues who are driving ferraris and talking about how delicious that £1,000 champagne bottle was last week while skiing in the Alps. (I actually despise that lifestyle, but for some reason it still stings when it's rubbed right in your face...)

As for how I made the decision to leave, for me the big moment was when I realised I was bound to rebel sooner or later, because my psychology, sense of satisfaction, social life, and quality of life were all crap. This gives the sunken cost fallacy new context: your options are not just "not leave" vs "leave now". This in itself is the fallacy of the false dichotomy! Other options also included "endure another 10 years before giving up", "endure another 20 years", "endure another 30", and so on.

So the question got reframed into "leave now and waste 10 years of medicine? Or leave in 10 years' time and waste 20 years of medicine?". Similarly, "If I leave now, do I still have a sporting chance of achieving something meaningful in the new field before I have to retire? How does this change if I delay this start by another 10 years instead?"

It was easy to make the decision to leave right away after that. :)

> I no longer work as a doctor.

I'm curious if you'd be willing to discuss why?

Honestly, every time I answer this question, it's a bit like when the Joker answer's how he got his smile (i.e. the answer is different every time, hahah).

In the end, I think what it boils down to is that I wasn't happy doing it, and I found something else that I felt more passionate about and found a way to do that instead. (while retaining some of the medical context which would set me apart from my peers in the new profession).

You became a coder after leaving medicine? I'd love to read a blog post about that journey!

Not a 'coder' coder per se. I'm a biomedical engineering researcher, which so happens to involve writing a lot of code. :)

“In the winter of 1650, I was going into the city of Chiaochuan from the Little Harbor, accompanied by a boy carrying a big load of books, tied with a cord and strengthened with a few pieces of board. It was toward sunset and the country was covered with haze. We were about a mile from the city. “Will we be in time to get into the city before the gates are closed?” I asked the ferryman. “You will if you go slowly. But if you run, you will miss it,” replied the ferryman, casting a look at the boy. But we walked as fast as possible. About halfway, the boy fell down. The cord broke and the books fell on the ground. The boy sat crying. By the time we had retied the package and reached the city gate, it was already closed. I thought of that ferryman. He had wisdom.” - Chou Yung (1619-1679)

Anecdotally, I had something similar happen to me. Someone was critiquing my rowing form at the gym. I was doing ~28 strokes per minute and my pace was about 2:05m per 500m.

"Explode when you push, but slow your overall pace to 20 strokes per minute. Take time to breathe and rest on the way back in."

After finding the new cadence, my pace was now 1:55m per 500m. A 30% reduction in stroke rate improved my pace by 8%.

out of curiosity, what do your sets normally look like? I generally just do a 500m sprint before moving onto other workouts, but I’m pretty spent and need to recoup for a while afterwards. Do you have recommendations for building up endurance?

I am new to rowing. However rowing is primarily a legs activity. You should only minimally be using your arms.

Slow down. A good pace is 2min/500m. Any faster and you will feel spent.

You can do intervals to build endurance: 30s fast work/90-120s slow and repeat 5 or more times. If that’s too much try 15s/60-90s. Build up from there.

Thanks for the advice. I normally tackle it as 5x10 pulls where each set is ~100m. My legs are always wobbly afterwards. I think switching between slow/fast is a good idea and I’ll try it out. I feel like I always dread doing intervals and I just try to get it over with as fast as possible haha. Bad habit of mine

2000m is the standard for benchmarking yourself. Legs/back/arms are three distinct movements - when you are done pushing with your legs and they are fully extended you should still be upright, then lean back, then arms. The arms should just be dead weight used as a hook for the oar up until the last part of the drive. Engaging them throughout will tire you faster. Reverse the order on the way back to the catch.

If you're feeling particularly motivated - bring a bucket ;)

I'm an ex-rower in my 40s and my usual cardio workout these days is 10km at about a 2:05 pace. Lately I've been watching Breaking Bad episodes during each workout, it's about the right length and a nice distraction!

Sometimes I do a 5k at about 1:55 instead. Between that and weight training, trying to build back my endurance before doing 2k sprints again. Maybe I'll get back on the water next year.

> I'm an ex-rower in my 40s and my usual cardio workout these days is 10km at about a 2:05 pace.

What? Assuming that you are talking about running, the current world record for 10K is 26:24 for men [0] and 29:38 for women [0]. It makes you quite a bit faster. Am I missing something?

[0] https://en.wikipedia.org/wiki/10K_run

He's speaking of rowing, not running.

And rowing splits are per 500m, not per km.

Thank you for sharing. Is the quote from "The importance of understanding" by Lin Yutang?

I got it from “The Man of Many Qualities” by R.G.H. Siu.

If you are a contractor, you need to read, understand, and practice this. I am about to fire a contractor who is extremely productive because he is completely unable/unwilling to take the feedback that he needs to move slower and check his work now that the product is in production with many real users, and this is not the first (nor likely the last) I've fired for this reason. He's incredibly smart, fast, and gets a ton done, but the fact that he cannot figure out how to turn his speed dial further towards correctness means that he is literally useless to me at this point.

That goes the other way as well: I've had to cut FAANG hires from startup projects because they couldn't agree on any corners to cut in the name of getting an MVP out quickly. As a senior person you need to be able to make that tradeoff effectively, and figure out what level of quality/testing is appropriate to the business situation. It's a tricky skill to learn, and it's a big reason why a lot of engineers that thrive in startups can't survive the transition to "real business" and vice versa.

Agreed. I don’t know how this would work in practice, but it would be great if dev education/bootcamping explicitly incorporated these kind of tight-rope walks.

Most difficult things in life turn out to be balancing acts between two opposing forces, yet junior devs always seem surprised about that fact.

Very interesting! I guess the good old iron triangle is still relevant.

https://en.wikipedia.org/wiki/Project_management_triangle

Choose one…

Yes! This is such an important quality in a senior engineer: Can you tune your work based on the appropriate values for the project?

Building a weekend prototype? Move fast. Just get it working. Building an MVP? Move fast but keep an eye on which areas will need to be redesigned in 6 months. Pay down tech debt as the code matures and you know which features will stick around. Adding features to software with an established user base? Move slowly and test.

If you can’t adjust your workflow based on the needs of the product, you will only be able to add value in a single niche.

I met some people who do not know how to write correct code (maybe because they do not have a correct model of how computation works all the way down). So the 'trick' of one guy was just to work as fast as possible so at least they looked productive. Slowing down wouldnt have helped.

Sounds like a guy worth training.

Are you hiring?

Training has limited value that depends critically on the personality traits of the person being trained.

Someone who's fresh to the field and is eager to take feedback and act on it, great! They'll learn quickly and you can mold them, they'll slurp up all the feedback they can get and end up fantastic after very little time.

But someone who already has 20 years of experience and is bitter that YOU, a young'n with just 10 years under your belt has the AUDACITY to condescend to THEM about how they could improve THEIR PERFECT CODE? You might as well just fire this person unless you're happy with their output, they are going to be locked in their ways and while it's possible to "break" a person like this and get them to bend a bit, it's going to be your full-time job which you'd damn well better have political cover for within the org because it can get nasty.

>> I met some people who do not know how to write correct code

I have never met a single developer who knew how to write correct code.

There is always a bug somewhere.

"Why do it right when you can do it twice." is one of my favorite lines to developers who insist on going fast.

Doing it right takes too much time.

It's better to do it twice and have your clients give up and throw it away because they can't use either result.

I think there's something to be said for doing it twice, or several more times. I've read many well-accomplshed devs say that they don't get it figured out until several prototypes in, and a "good" version doesn't come until the seventh rewrite.

Iterating to a correct solution to a problem works well as a strategy for projects, but very poorly for smaller units of work like a feature or a bug fix. Often, doing the quick hacky solution for a feature won't show the problems it has for a while, by which time you've built things on top of it. Having to go back and fix that impacts far more than if you'd spent a little more time in the first place.

It's particularly important when you're designing data structure changes more than than code. Getting an API or a database table design right first time (or even just 'more right') is worth the time invested.

This is the difference between productivity and efficacy.

The big one:

    you don’t want to assume anything. Don’t assume. Stop assuming. Stop guessing

He goes on to explain this in much more detail and I can echo a lot of this from my own experience. I too have been "the new guy that asks too many questions, we wanna be done with backlog maintenance already!".

I've also had this experience in some consulting gigs before where they asked me to help out with something "because don't you know SSL?". "Sure" I said (coz yeah, I had set up an self-signed cert for my home server once ...). All it took was to get the developer that had been stuck for a day to get something running (don't remember any specifics) to actually take a step back and check all the assumptions he made. I basically just asked him very simple and basic questions about the problem and whenever he told me that he'd checked something, I made him show me that whatever he claimed was true. Sometimes it was. One time it wasn't and we found the problem. Once we had rooted out the assumption, it was easy to fix the actual problem. More than a day of a highly paid senior developer wasted and figured out by the "dumb rookie consultant". Sounds a bit like the recent story about "asking dumb questions" ;)

I think this is more about asking literally anybody else. If I spend a day on a problem without progress I know it’s time for someone else to take a look.

Actually, at this point I’m always pretty well aware that it must be one of my assumptions, it’s just a matter of figuring out what implicit assumptions I’ve made.

Other people are really good for that.

Dunn's Law of Information

"What you don't know, you don't know - and you can't make it up".

Attributed to former Raytheon vice president Bruce Dunn.

http://www.linux-ha.org/wiki/Dunn%27s_Law_of_Information

"Slow is smooth, smooth is fast."

Alas, the fast hacker gets recognized for their hustle, despite them spending twice the effort to get to the same place, and others having to go back and fix/cleanup their mistakes.

Was going to post this exact saying. (For the uninitiated, this advice is repeated on racetracks everywhere.)

It depends as always on the length of the race, though. The fast hacker gets to the first corner first. The 'slow' hacker finishes the first lap first. The engineer might miss the first season and then show up in a fighter jet.

This is why Scrum can be so pernicious for productivity: It turns every race into a race to the first corner.

Which is great! For a drag strip. Or a 4WD trek through unexplored jungle to a vaguely defined destination, like 'first to a nice swimming hole wins!' It's not so great if you're racing on a known track with lots of corners, or you have to meet up at planned waypoints.

Agile (are we calling it Scrum now or is Scrum something different these days?) is a good methodology for a very specific scenario: A small team working on a tight schedule towards an ill-defined goal for a client who doesn't know what they want. Unfortunately some people (especially those getting paid to preach it) took this new hammer and hammered every nail, screw, bolt and tube of epoxy they could find while trying to convince everyone they met that Hammering Is The Way.

Scrum is a horrible way to interact with somebody that doesn't know what they want. The process is entirely focused on breaking things on predictable sizes and focusing the interaction with the users into a single person and a few meetings. Also, in a tight schedule you do really not want to use a fixed timebox.

Honestly, I'm not sure Scrum is good for anything. (And well, we did not technically rename "Agile" into "Scrum", we just have a lot of lying propaganda saying that Scrum implements Agile and have the entire population of managers dismissing any other process. So Agile doesn't exist anymore, we successfully killed the idea.)

As someone working on quite some complex stuff, be it programming or electronics (including the varity that could kill people if done wrongly) this is my mantra: If you are in a hurry, go slow

You have to know at which pace you won't make mistakes and try hard never to exceed that pace and all will be good. Especially if you work with things where you will go to prison (or die) in the worst case, while the boss who pressured you into going faster will just loose more time.

There is always a maximum tempo at which things can be done reasonably. Know that tempo, never exceed it and never promise someone to be faster than that.

That being said I am still fast compared to other people.

We're all faster than everyone else, or we wouldn't find the time to post on HN!

We have to be. A little distraction let's you look at the code with fresh eyes — or so I say.

Exactly! While others stare at their code with their old eyes, we came back from HN with a pair of fresh ones.

His main point is that you should only start work once 100% of the requirements are clear. And you should get them clear by asking people, several of them.

But in my experience, it's often my job as a developer to decide on the last so many percent of the requirements, and asking other people doesn't help much because they all have their own work to do.

And many of the things left not completely specified are often not that crucial, and can be changed later, so this is how it should be.

That’s the judgement call to make and sometimes I don’t ask but assume when (i) it’s easy to change later, in other words a 2 way door (ii) asking will cause meetings, scheduling challenges (need to get everyone in the room!) and delay work and (iii) the people I’m asking might bike shed it taking up lots of their time and mine.

It’s the developers discretionary power! Perhaps the colour of the capacitor inside the iPhone … you don’t need to run past Jobs (back in the day…)

Yes, people who say you should never assume anything just don't realise that they assume things all the time. They have to or they would never get anything done.

Assumptions go wrong sometimes, but they go right and save so much time so often that you can't just throw them all out.

The real advice is "learn when to question assumptions" but that just takes experience and you can't write blog posts about it.

Yeah I kinda balked at the "figure out 100% of the requirement up front" statement. That's usually how I define waterfall development.

I like to go fast and make a test build to show someone else and get feedback. Cause I know one person can never see the whole picture. Code is a conversation. This is the essence of Agile (not the Agile that paid management consultants teach).

But we're working stories with points that are mapped to days and all the epic deliverables are planned according to the story estimates and this epic HAS to be done before the next epic and those epics both must be done by X date.

Now picture you are reworking almost an entire process or part of the system that has already been delivered (management jumped up and down congratulating everyone, promotions handed out), and is highly complex where new issues are discovered that were never thought of in planning. There is no "fast" in this situation and it's where most of us live every single day. And they want it all by X date or everything goes tits up (not really but managements' metrics: dates and "done," are causing them to pressure people--and by people I mean junior devs who are running on the career treadmill at a corp).

Meanwhile there are devs who go fast because they like the immediate praise. They literally print bugs with their keyboard--and they bite hard.

Yeah that's the Agile I added a caveat about at the end.

He isn't saying that 100% of requirements must be understood up front, but that each stated requirement must be 100% understood by the developers. Not really understanding a requirement means you don't understand what the customer is asking for, and are likely to go build the wrong thing. It's a communication failure between the developer and the customer, and while I'll happily blame the customer for that, I also see it as my job to figure out what was really meant.

Understanding each requirement fully does not, unfortunately, imply you know everything there is to know about the desires of the customer, but at least you are on much firmer ground than if you only barely know what you are supposed to be making in the first place.

I think that's the "building a brige" model of software.

But there is also the "writing a book" model, where a general plot outline is first, but the characters write themselves and often surprise the author.

> But in my experience, it's often my job as a developer to decide on the last so many percent of the requirements, and asking other people doesn't help much because they all have their own work to do.

(Note: The article addresses the issue with incremental development.)

I agree, not necessarily because people have other stuff to do, but rather because that is what programming _is_: you operationalise a vague process into something detailed and clear so a computer understands it.

It's really a spectrum that is never clear cut. The article suggests that one should take time to get close to a clearer picture by thinking, investigating and communicating before writing actual code. I tend to agree.

Or measure twice cut once.

Or a stitch in time saves nine.

This is definitely true but some companies are set up to reward rush ‘n’ bug fixes and love the heroism of an all hands production issue fixed. So know what you are swimming in too!

Not always true. Often building what you guessed is the quickest way to find out whether your assumptions are correct - maybe what you built is "wrong", but it sharpens the conversation about what the client actually wants. Iterating in software is extremely cheap, far cheaper than in traditional engineering, and going around the loop several times often gets you a better result than any amount of up-front analysis and design work.

Festina lente

Make haste slowly

https://en.wikipedia.org/wiki/Festina_lente

I find getting started on multiple sub projects/tasks at the same time really helps my progress.

Starting to think about the requirements of a task and how to implement it a few days (or more) before I'll start work on it, whilst working on another lets the problem mature in my mind, perhaps think or research the problem in my downtime and means I won't rush ahead into a non optimal solution.

While I believe there's value in the mentality that "you don't know what you're building until you're building it", I also agree with a lot of this, as long as it means more asynchronous communication anyhow. The write-up itself was a bit focused on if it all happened in meetings, but a lot of this could also be accomplished over email or collaborative editing, RFCs, etc.

But back to the idea of many applications being emergent and/or not at all (or not entirely) what their creators intended. Maybe there's room for both approaches depending on the situation.

Assuming finishing fast is what you want and not looking busy in front of your boss.

I'm sure how I'd get away with this. Either my tickets are getting done or they're not.

Agree.

Often small team doesn't have dedicated PM to divide and conquer big issues into smaller ones to be fit in a sprint timeline. It's the main reason to fail at delivery on time for most of my projects.

It becomes interesting if you project this onto the programming languages space: "python lets you get started faster. Ocaml lets you finish earlier" (NN)

https://youtu.be/bSjOq28wuOk?t=71

latin proverb: festina lente

german saying: eile mit Weile

it seems to be a pattern.

Reply on news.ycombinator.com