11 ms·

Slow Down, Finish Faster

205 points by bdicroce 5y ago

helsinkiandrew 5y ago
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.
aaronleather 5y ago
don’t start the work unless, and until all the variables are known
tharkun__ 5y ago
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" ;)
- Aeolun 5y ago
  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.
- throwaway210222 5y ago
  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 http://www.linux-ha.org/wiki/Dunn%27s_Law_of_Information
mjklin 5y ago
“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)
- nvahalik 5y ago
  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%.
  - ajoseps 5y ago
    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?
    - jpm_sd 5y ago
      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.
cornel_io 5y ago
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.
- tenaciousDaniel 5y ago
  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.
- cpach 5y ago
  Very interesting! I guess the good old iron triangle is still relevant. https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle
  - ultrablack 5y ago
    Choose one…
- josephg 5y ago
  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.
jasonpeacock 5y ago
"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.
- taneq 5y ago
  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.
  - WJW 5y ago
    This is why Scrum can be so pernicious for productivity: It turns every race into a race to the first corner.
    - taneq 5y ago
      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.
      - marcosdumay 5y ago
        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.)
kubb 5y ago
Assuming finishing fast is what you want and not looking busy in front of your boss.
- mehphp 5y ago
  I'm sure how I'd get away with this. Either my tickets are getting done or they're not.
galaxyLogic 5y ago
https://youtu.be/bSjOq28wuOk?t=71 https://youtu.be/bSjOq28wuOk?t=71
revskill 5y ago
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.
Triesault 5y ago
Festina lente Make haste slowly https://en.wikipedia.org/wiki/Festina_lente https://en.wikipedia.org/wiki/Festina_lente
lmm 5y ago
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.
eternalnode 5y ago
Seems like a fun guy to work with. /s
atoav 5y ago
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.
- _y5hn 5y ago
  We're all faster than everyone else, or we wouldn't find the time to post on HN!
  - atoav 5y ago
    We have to be. A little distraction let's you look at the code with fresh eyes — or so I say.
    - _y5hn 5y ago
      Exactly! While others stare at their code with their old eyes, we came back from HN with a pair of fresh ones.
toolslive 5y ago
It becomes interesting if you project this onto the programming languages space: "python lets you get started faster. Ocaml lets you finish earlier" (NN)
Scarblac 5y ago
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.
- quickthrower2 5y ago
  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…)
- IshKebab 5y ago
  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.
- Sammi 5y ago
  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).
  - datavirtue 5y ago
    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.
quickthrower2 5y ago
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!
tpoacher 5y ago
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.)
- veb 5y ago
  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-8cefe5e74344 https://medium.com/@veb/my-journey-to-a-cochlear-implant-8ce... - had to remove part 2 because lawyers...)
  - codetrotter 5y ago
    What happened next, and why did lawyers make you remove part 2?
    - Hitton 5y ago
      Pesky lawyers thinking they can really make stuff disappear from interwebz. https://web.archive.org/web/20170112221346/https://medium.com/@veb/my-journey-to-a-cochlear-implant-wtf-happened-38331f661781 https://web.archive.org/web/20170112221346/https://medium.co...
mro_name 5y ago
latin proverb: festina lente german saying: eile mit Weile it seems to be a pattern.
SeanFerree 5y ago
Great article!
luord 5y ago
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.

205 points by bdicroce 5y ago

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.

aaronleather 5y ago

don’t start the work unless, and until all the variables are known

tharkun__ 5y ago

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" ;)

Aeolun 5y ago
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.
throwaway210222 5y ago
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 http://www.linux-ha.org/wiki/Dunn%27s_Law_of_Information

mjklin 5y ago

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

nvahalik 5y ago
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%.
- ajoseps 5y ago
  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?
  - jpm_sd 5y ago
    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.

cornel_io 5y ago

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.

tenaciousDaniel 5y ago
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.
cpach 5y ago
Very interesting! I guess the good old iron triangle is still relevant. https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle
- ultrablack 5y ago
  Choose one…
josephg 5y ago
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.

jasonpeacock 5y ago

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

taneq 5y ago
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.
- WJW 5y ago
  This is why Scrum can be so pernicious for productivity: It turns every race into a race to the first corner.
  - taneq 5y ago
    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.
    - marcosdumay 5y ago
      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.)

kubb 5y ago

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

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

galaxyLogic 5y ago

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

revskill 5y ago

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.

Triesault 5y ago

Festina lente Make haste slowly https://en.wikipedia.org/wiki/Festina_lente https://en.wikipedia.org/wiki/Festina_lente

lmm 5y ago

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.

eternalnode 5y ago

Seems like a fun guy to work with. /s

atoav 5y ago

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.

_y5hn 5y ago
We're all faster than everyone else, or we wouldn't find the time to post on HN!
- atoav 5y ago
  We have to be. A little distraction let's you look at the code with fresh eyes — or so I say.
  - _y5hn 5y ago
    Exactly! While others stare at their code with their old eyes, we came back from HN with a pair of fresh ones.

toolslive 5y ago

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

Scarblac 5y ago

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.

quickthrower2 5y ago
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…)
IshKebab 5y ago
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.
Sammi 5y ago
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).
- datavirtue 5y ago
  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.

quickthrower2 5y ago

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!

tpoacher 5y ago

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

veb 5y ago
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-8cefe5e74344 https://medium.com/@veb/my-journey-to-a-cochlear-implant-8ce... - had to remove part 2 because lawyers...)
- codetrotter 5y ago
  What happened next, and why did lawyers make you remove part 2?
  - Hitton 5y ago
    Pesky lawyers thinking they can really make stuff disappear from interwebz. https://web.archive.org/web/20170112221346/https://medium.com/@veb/my-journey-to-a-cochlear-implant-wtf-happened-38331f661781 https://web.archive.org/web/20170112221346/https://medium.co...

mro_name 5y ago

latin proverb: festina lente german saying: eile mit Weile it seems to be a pattern.

SeanFerree 5y ago

Great article!

luord 5y ago

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.