18 ms·

How To Do Less

413 points by ggoodale 5y ago

bghfm 5y ago
Great article and thanks for sharing; great applications in one’s personal life too. The author is very focused on hows of managing expectations of the technology team, and would love to hear his/her thoughts on how to manage expectations with the business.
- 9wzYQbTYsAIc 5y ago
  This is the authors take on that: “Here are some concrete ways to tell management or stakeholders no. This isn’t MAIN_PRIORITY, so we aren’t going to do it until at least ESTIMATED_DONE_DATE. Right now our priority is MAIN_PRIORITY because of ONE_SENTENCE_JUSTIFICATION, and this is 100% our shipping focus. I agree this sounds like a really useful feature - once we finish MAIN_PRIORITY, should we consider dropping SECOND_PRIORITY and do it?”
cushychicken 5y ago
This could be a guide of "How to quickly get on the wrong side of a CTO". Seen it happen.
- btrettel 5y ago
  What should someone do differently to have a more realistic workload?
  - michaelcampbell 5y ago
    If history is any guide, commit to X, deliver X/5, then start Y. There's always time to fix stuff, never time to do it right. A project manager inadvertently laid this out for me when I was new in my career; he didn't mean to put it like this, but this is what came out. (Note that I'm a software developer, and at the time the software I wrote was not "shelfware", but rather installed into big enterprises' data centers. Pre cloud) NO ONE wants software done right the first time. Because, when you slam the happy paths out there for the customer as fast as you can: * Sales wins because they can claim "Feature X" being sold and get their commission * The customer wins because they get to complain about x or y being bad, incomplete, or whatever they want to whinge about and feel like they're part of the solution * Customer Support/Sales Engineering/etc wins because they get to appear to be "responsive" to the customer by quickly reorganizing ongoing work to take care of the "urgent need" * The Project Manager wins (2x!) because they can now a) do the same "response" dance for the C-levels, and b) berate the software development staff and show their authority and working under pressure skills * Software Development wins because they can now work on the secondary features, fixes, "skunk works" tech debt, etc. since this is now more important.
    - laurent92 5y ago
      z) Customers are gonna complain anyway and ask for more, so better make 80% of the feature and see what they focus on. z’) If we deliver 20% of the wrong feature, the customers are going to say it and we can reorient before we make the other 50%. #Agile I’m not very satisfied either but the history of programming is riddled with us building overengineered solution to the wrong problem.
      - michaelcampbell 5y ago
        My background (and experience) might be different than many here, but I've worked in dev orgs that specifically did the every-6-months big-bang release to a customer, with the BigDesignUpFront, waterfall, and all that. There were some wins here: * Customers signed off on requirements; they may not have liked them, but they knew what was coming. And when. * The dev org got to have the (IMO important) psychological journey of discovery, creation, testing, "oh shit", last minute fixing, last second covering up, and the final human release of... releasing. Big celebration. Yay, we did it. My last couple positions have been SAAS stuff where we "release" tiny little things multiple times a week; sometimes multiple times a day. Honestly, it's a grind. There's no "big win". It's akin to "death by 1000 cuts". You don't have the big wins or the big losses, but you get ground down by the never ending stream of small stuff. Writing an app is like putting yet another pat of snow on the snowball. I get where agile is coming from, but a lot of times it fails to recognize that sometimes, people actually DO want to be surprised with big things, even if they're not 100% positive. And sometimes, customers DO want to have the vendor "Just deal with it and leave me alone - I can't be bothered multiple times a month (or week!) to look at your teeny little new thing. SHOW ME THE FEATURE WHEN IT'S DONE." They WANT that ability to gripe all at once in the end, and not be part of the "steering committee - what am I paying you for if I have to dictate everything?" I'm being hyperbolic here of course, but I've seen versions of this play out numerous times.
        wereHamster 5y ago
        Not celebrating is a cultural issue. Even if you ship a thousand new things a week, you can still take time to celebrate those. It's your (or your team's) choice not to. One good example is Linear. The product improves day by day, but they also publish a regular (weekly) summary of the changes. And for me as a user it's a delight to read through them. https://linear.app/changelog https://linear.app/changelog
  - cushychicken 5y ago
    I'm not sure. The business unit is always demanding more. I don't have a solution for that. I just know enough from my brief stint in management that always saying "No" is a great way to get people to say you're "difficult to work with" or "aren't a team player". That was a hard lesson to learn: "team player" means different things at different org levels.
    - underwater 5y ago
      Being a team player at every company is different too. That makes it hard to give general advice. But I think that "learn to prioritise, communicate priorities and default to no" is most useful advice than "don't say no to your CTO."
    - redisman 5y ago
      Every IC and manager needs to just learn to say: “yes we can do that, the sprint/quarter/whatever is already planned full, what would you like to remove to fit the new priority in?”
    - TameAntelope 5y ago
      You aren't saying "No", you're saying, "What drops?" People who say, "No." are being hard to work with. People who engage honestly with the CTO who is trying to change priorities is someone who you actually want on your team, the only kicker here is that the conversation ends with, "Okay so what gets shelved for this new thing we've been talking about, or should we finish out what we're currently doing before jumping on this?" There is a lot of advice out there that says, "Say no!" but you can't take it at face value; no reasonable person is suggesting you respond to a request from leadership with a single word answer. You need to have a higher EQ than that, but what you can do is find ways of explaining the cost of what they're asking in a way that is effectively no, without actually just saying one word and then refusing to elaborate.
      - skydhash 5y ago
        > what you can do is find ways of explaining the cost of what they're asking in a way that is effectively no What's good about that is that your superior may want to actually eat the costs because he may have information that he has not shared yet with you.
- nevir 5y ago
  For what it's worth, the author's CTO is the one that shared this article ;)
  - spccdt 5y ago
    Former* CTO. That is no longer accurate
sdoering 5y ago
> unless you work at a 10 person company, the CTO has less context than you about reality “on the ground.” From my experience people "on the ground" often miss out on the strategic long term goals. Neither my take on it, nor the author's approach will be the silver bullet. Both are too extreme. And might appeal to different audiences on paper but not survive reality imho.
- Negitivefrags 5y ago
  This is the result of the "Us vs Them" mentality that so many developers have these days and boils down to a lack of trust. If your CTO lacks context about your reality on the ground, then tell them the context. How else can they readjust what the priorities are? If you tell them and they refuse to adjust your priority then it's probably you that lacks context about what the goals actually are. If you still disagree with that, then it's because you don't trust your CTO. If you don't trust your CTO then you should leave and find a better one. If you have worked in a few places and have never trusted the CTO anywhere you have worked, perhaps you need to sit down and take a hard look at your yourself rather than others.
  - fartcannon 5y ago
    I think its the power dynamic. Not everyone can just leave jobs. If people don't trust their CTOs, bosses, CEOs, that is mostly the bosses fault and on them to fix. Requiring the person who can be at-will fired to also manage upwards is pretty much a fail state.
    - malfist 5y ago
      Not managing upwards is how you wind up in a fail state. Business, teamwork and employment isn't a zero sum game. Everyone is working together to achieve something. Helping your boss understand why something shouldn't be done/prioritized/cancelled is paramount to being efficient. If you think you can never tell your boss no because you'll be fired, you're not going to have a good employment story.
jaqalopes 5y ago
As a self-employed person, this is essential. I'm constantly using Things3 to take down notes on ideas for things I want to do, or could do. But there's only so much I can do in my waking hours. So when it comes time to "prioritize" and make my plan for the week, I throw everything that's not on fire in a secondary list called "brain vomit" that I simply never look at, while filtering out the important and urgent stuff to the main actual list of things I'm actually going to do. This probably sounds insane but it's working for me. I think part of the reason is that I often don't have the mental bandwidth (or discipline) to recognize at the moment of task creation whether something is a good idea or not. I'm simply moving too fast, multitasking too much, to make those calls. So I batch every new idea into the inbox and review it later. And even if I discover good ideas in there later, if they aren't essential to my work or life they go in the brain vomit folder. So I get all the satisfaction of stream of consciousness "ubiquitous capture" (a la GTD) without the emotional burden of having to actually do all that non-critical stuff.
- godfreyantonell 5y ago
  brain vomit I like it
  - WinterMount223 5y ago
    AKA brain dump.
- lioeters 5y ago
  That's interesting to hear about the inbox for quickly capturing thoughts, including brain vomit. Over the past few years I've used a similar convention, first called Journal, then Stream, then finally Archive. Everything goes in there, added to the bottom of the file: snippets, ideas, links, both personal and work-related stuff. I have a shell alias to append one-liners from the terminal, which I use throughout the day (and night). I review it regularly to move the important parts, especially plans and actions: - Archive - Do - Doing - Done I like that the folders sort alphabetically, and also in the order of how things flow.
  - 5y ago
arthurofbabylon 5y ago
In my experience/opinion (disclaimer: small teams only) this single-item paradigm misses a lot of opportunities. I prefer the 60-30-10 approach (see https://minimal.app/603010 https://minimal.app/603010) as it is more experimental/open while still capturing great focus. To back that up, I’d like to acknowledge that almost all significant contributions I’ve witnessed weren’t the top priority item (instead, they’re some weird experiment). I am generally suspicious of the human ability to form a hierarchy of needs/opportunities, so I try to favor qualities like experimentalism, curiosity. Of course, this is all circumstantial. I’m sure some teams have hard deliverables where there is little value in exploring or doing things with no known measurable impact.
- Spooky23 5y ago
  It depends on how well the organization understands priorities, whether it does so consistently and how it is organized. Sometimes the business priorities and your chain of command priorities don’t mesh. That’s a good reason to be able to focus on multiple things.
eternityforest 5y ago
My priority is always decustomization. Anything that makes me think of the words "Bespoke" or "Artisinal" or worst of all "A perfect fit to the project needs" is where I look first for problems. I also look at anything that provides multiple ways to do the same thing. The JS community understands it better than anyone. At the application level, any program, be it amateur or professional, is almost always readable and maintainable. Because there's no interesting algorithms, no abstractions you haven't already seen in a design patterns list, and just generally nothing special about the code at all. They use libraries for everything. When you stop trying to write interesting and beautiful code, and stop trying to innovate at any level below the application, stuff gets a lot easier. Of course some projects really do have interesting technical challenges... but so many projects don't.
- sarchertech 5y ago
  > The JS community understands it better than anyone. At the application level, any program, be it amateur or professional, is almost always readable and maintainable. Oh man. We have worked on some very different JS applications.
  - eternityforest 5y ago
    Maybe a better way to phrase it would be "Half the JS community understands that better than anyone, and the other half diarrheas out endless tiny useless frameworks and tries to get you to use them, but lets pretend that's not an issue".
    - sarchertech 5y ago
      Yes there’s that as well. But I have seen plenty of the type of code bases you’re praising that were a nightmare to maintain and debug. Everything is a trade off. Most developers probably shouldn’t write their own database engine. But at the same time adding another dependency to handle padding a number with zeroes is overkill. In practice after 2 decades doing this, I’m much more likely to run into an over reliance on libraries these days than the other way around.
jll29 5y ago
Thanks for sharing. I like how you provide text snippets for potential responses, as communications & stakeholder mgt. is something junior people often struggle with (not taught much at uni). Delivering one feature at a time may neither synch up with org roadmaps or go down well with mgt. expectations, but that depends where you work; I can see your approach might work in a smaller organization with overloaded team, where it may be a tool to create laser focus.
westcort 5y ago
Here are my key takeaways: 1. Say no a lot, up front 2. As early as you hear anybody else’s plans that involve your team doing something new, interject with a clear No 3. Everything your team already owns (that actually matters to your customers) needs to approach 0 maintenance costs 4. Ask your team what the biggest maintenance costs are 5. Write a Maintenance Roadmap to reduce your team’s costs 6. List all the new things you’re currently doing or planning to do, and put them in the New Features roadmap doc 7. Dig into your data, figure out where the drag on your team comes from, and drive it down 8. Drop everything except the top item on the list
mherdeg 5y ago
I'm currently reading through Johanna Rothman's "Manage Your Project Portfolio" and related literature and a bunch of this resonates: * Finishing work is more important than starting it * Teams working together on a single priority ("swarming") seem to be more successful than teams where each person is doing 1-2 things on their own A few subtle points in this article that made me think: * Keeping existing features working as well as customers expect is a great zeroth priority but it can be hard to know what customers actually expect. Absolutely the worst is when you carefully maintain a very reliable, feature-rich thing that no one particularly wants or uses. In an org without a dedicated PM, I'm never quite sure how to account for time spent on the product-management work of "listen to my customers about what they want from my service". * The article talks about engineers and stakeholders caring about "project X" and "feature Y". A bunch of literature suggests that anyone who is thinking this way is probably a bit lost -- they have lost sight of the business outcome that the team's work is supposed to be getting (more sales, quantifiably happier customers, fewer pager alerts interrupting engineers, whatever). If you can tie particular features/projects to outcomes maybe you can make it easier to explain why you've prioritized other work first (it makes bigger outcomes sooner).
- nevir 5y ago
  It's also worth noting that another way to reduce the cost to maintain your existing functionality (priority 0) is to actively _remove_ rarely-used or less valuable functionality
- yayajacky 5y ago
  You can figure out if people use or care about your service or not via observability.
  - blacklivsmatr 5y ago
    Disagree. If you followed observability no text editor would do more than Notepad
    - bryanrasmussen 5y ago
CraigJPerry 5y ago
This is one of the best articles i can recall reading in a while. What a great piece. The third how to say no copy/paste example is poor compared to the first two.
codemac 5y ago
But what about Engineer FAANG: Who will get promoted based on individual impact? I've found convincing everyone else an engineering team needs to focus doesn't take too long. Managers are not shocked or confused to hear that a team drowning needs to do less. The individual engineers though, those can be the hardest. How does management split credit for group effort? Will the leader of the project get promoted, even though their contribution may in total be less than others on the project? What happens to my ongoing work, will I get skewered in "calibrations" when other teams talk about how I dropped everything to work on something to important to them?
deleted 5y ago
[deleted]
debesyla 5y ago
The prioritization tip reminded me of "Final Version" productivity system that I personally like. It's just one big-ass list of everything and you pick and do stuff at random (more or less). Yes, it sounds silly, but I found out that it works better than constantly re-ordering goals. :-) http://markforster.squarespace.com/final-version-faqs/ http://markforster.squarespace.com/final-version-faqs/
- codemac 5y ago
  Mark Forster is a hidden gem!
5350-uiop-1130 5y ago
"So now, you’ve committed to a big, one-time effort of saying No to everybody. " assuming you have the luxury to do that.
roeles 5y ago
One interesting thing I learned from the book "essentialism" is that the word priority used not to have a plural. It described the single most important thing to do.
auxfil 5y ago
It sounds like this is just an exercise in, not learning, but being forced to say "No" (a lot) out of a need for mental survival...in a work culture where priorities are constantly shifted (and this is the key). Instead, foster change where you can say "Yes, and" or "Yes, but", where there is a common understanding that sure we can work on it, eventually, as it's going into the backlog, that will need to be prioritised, or it goes at the bottom of the queue as any new thing should - as what is already in the queue, should already be prioritised. Obviously what is already in the stack can be shifted around as the business needs may necessitate the change in priority...but popping shit at the top of the stack constantly...that's not where you need to learn to say "No"...that's where you need to learn to say "Bye".

413 points by ggoodale 5y ago

Great article and thanks for sharing; great applications in one’s personal life too. The author is very focused on hows of managing expectations of the technology team, and would love to hear his/her thoughts on how to manage expectations with the business.

9wzYQbTYsAIc 5y ago
This is the authors take on that: “Here are some concrete ways to tell management or stakeholders no. This isn’t MAIN_PRIORITY, so we aren’t going to do it until at least ESTIMATED_DONE_DATE. Right now our priority is MAIN_PRIORITY because of ONE_SENTENCE_JUSTIFICATION, and this is 100% our shipping focus. I agree this sounds like a really useful feature - once we finish MAIN_PRIORITY, should we consider dropping SECOND_PRIORITY and do it?”

cushychicken 5y ago

This could be a guide of "How to quickly get on the wrong side of a CTO". Seen it happen.

btrettel 5y ago
What should someone do differently to have a more realistic workload?
- michaelcampbell 5y ago
  If history is any guide, commit to X, deliver X/5, then start Y. There's always time to fix stuff, never time to do it right. A project manager inadvertently laid this out for me when I was new in my career; he didn't mean to put it like this, but this is what came out. (Note that I'm a software developer, and at the time the software I wrote was not "shelfware", but rather installed into big enterprises' data centers. Pre cloud) NO ONE wants software done right the first time. Because, when you slam the happy paths out there for the customer as fast as you can: * Sales wins because they can claim "Feature X" being sold and get their commission * The customer wins because they get to complain about x or y being bad, incomplete, or whatever they want to whinge about and feel like they're part of the solution * Customer Support/Sales Engineering/etc wins because they get to appear to be "responsive" to the customer by quickly reorganizing ongoing work to take care of the "urgent need" * The Project Manager wins (2x!) because they can now a) do the same "response" dance for the C-levels, and b) berate the software development staff and show their authority and working under pressure skills * Software Development wins because they can now work on the secondary features, fixes, "skunk works" tech debt, etc. since this is now more important.
  - laurent92 5y ago
    z) Customers are gonna complain anyway and ask for more, so better make 80% of the feature and see what they focus on. z’) If we deliver 20% of the wrong feature, the customers are going to say it and we can reorient before we make the other 50%. #Agile I’m not very satisfied either but the history of programming is riddled with us building overengineered solution to the wrong problem.
    - michaelcampbell 5y ago
      My background (and experience) might be different than many here, but I've worked in dev orgs that specifically did the every-6-months big-bang release to a customer, with the BigDesignUpFront, waterfall, and all that. There were some wins here: * Customers signed off on requirements; they may not have liked them, but they knew what was coming. And when. * The dev org got to have the (IMO important) psychological journey of discovery, creation, testing, "oh shit", last minute fixing, last second covering up, and the final human release of... releasing. Big celebration. Yay, we did it. My last couple positions have been SAAS stuff where we "release" tiny little things multiple times a week; sometimes multiple times a day. Honestly, it's a grind. There's no "big win". It's akin to "death by 1000 cuts". You don't have the big wins or the big losses, but you get ground down by the never ending stream of small stuff. Writing an app is like putting yet another pat of snow on the snowball. I get where agile is coming from, but a lot of times it fails to recognize that sometimes, people actually DO want to be surprised with big things, even if they're not 100% positive. And sometimes, customers DO want to have the vendor "Just deal with it and leave me alone - I can't be bothered multiple times a month (or week!) to look at your teeny little new thing. SHOW ME THE FEATURE WHEN IT'S DONE." They WANT that ability to gripe all at once in the end, and not be part of the "steering committee - what am I paying you for if I have to dictate everything?" I'm being hyperbolic here of course, but I've seen versions of this play out numerous times.
      - wereHamster 5y ago
        Not celebrating is a cultural issue. Even if you ship a thousand new things a week, you can still take time to celebrate those. It's your (or your team's) choice not to. One good example is Linear. The product improves day by day, but they also publish a regular (weekly) summary of the changes. And for me as a user it's a delight to read through them. https://linear.app/changelog https://linear.app/changelog
- cushychicken 5y ago
  I'm not sure. The business unit is always demanding more. I don't have a solution for that. I just know enough from my brief stint in management that always saying "No" is a great way to get people to say you're "difficult to work with" or "aren't a team player". That was a hard lesson to learn: "team player" means different things at different org levels.
  - underwater 5y ago
    Being a team player at every company is different too. That makes it hard to give general advice. But I think that "learn to prioritise, communicate priorities and default to no" is most useful advice than "don't say no to your CTO."
  - redisman 5y ago
    Every IC and manager needs to just learn to say: “yes we can do that, the sprint/quarter/whatever is already planned full, what would you like to remove to fit the new priority in?”
  - TameAntelope 5y ago
    You aren't saying "No", you're saying, "What drops?" People who say, "No." are being hard to work with. People who engage honestly with the CTO who is trying to change priorities is someone who you actually want on your team, the only kicker here is that the conversation ends with, "Okay so what gets shelved for this new thing we've been talking about, or should we finish out what we're currently doing before jumping on this?" There is a lot of advice out there that says, "Say no!" but you can't take it at face value; no reasonable person is suggesting you respond to a request from leadership with a single word answer. You need to have a higher EQ than that, but what you can do is find ways of explaining the cost of what they're asking in a way that is effectively no, without actually just saying one word and then refusing to elaborate.
    - skydhash 5y ago
      > what you can do is find ways of explaining the cost of what they're asking in a way that is effectively no What's good about that is that your superior may want to actually eat the costs because he may have information that he has not shared yet with you.
nevir 5y ago
For what it's worth, the author's CTO is the one that shared this article ;)
- spccdt 5y ago
  Former* CTO. That is no longer accurate

sdoering 5y ago

> unless you work at a 10 person company, the CTO has less context than you about reality “on the ground.” From my experience people "on the ground" often miss out on the strategic long term goals. Neither my take on it, nor the author's approach will be the silver bullet. Both are too extreme. And might appeal to different audiences on paper but not survive reality imho.

Negitivefrags 5y ago
This is the result of the "Us vs Them" mentality that so many developers have these days and boils down to a lack of trust. If your CTO lacks context about your reality on the ground, then tell them the context. How else can they readjust what the priorities are? If you tell them and they refuse to adjust your priority then it's probably you that lacks context about what the goals actually are. If you still disagree with that, then it's because you don't trust your CTO. If you don't trust your CTO then you should leave and find a better one. If you have worked in a few places and have never trusted the CTO anywhere you have worked, perhaps you need to sit down and take a hard look at your yourself rather than others.
- fartcannon 5y ago
  I think its the power dynamic. Not everyone can just leave jobs. If people don't trust their CTOs, bosses, CEOs, that is mostly the bosses fault and on them to fix. Requiring the person who can be at-will fired to also manage upwards is pretty much a fail state.
  - malfist 5y ago
    Not managing upwards is how you wind up in a fail state. Business, teamwork and employment isn't a zero sum game. Everyone is working together to achieve something. Helping your boss understand why something shouldn't be done/prioritized/cancelled is paramount to being efficient. If you think you can never tell your boss no because you'll be fired, you're not going to have a good employment story.

jaqalopes 5y ago

As a self-employed person, this is essential. I'm constantly using Things3 to take down notes on ideas for things I want to do, or could do. But there's only so much I can do in my waking hours. So when it comes time to "prioritize" and make my plan for the week, I throw everything that's not on fire in a secondary list called "brain vomit" that I simply never look at, while filtering out the important and urgent stuff to the main actual list of things I'm actually going to do. This probably sounds insane but it's working for me. I think part of the reason is that I often don't have the mental bandwidth (or discipline) to recognize at the moment of task creation whether something is a good idea or not. I'm simply moving too fast, multitasking too much, to make those calls. So I batch every new idea into the inbox and review it later. And even if I discover good ideas in there later, if they aren't essential to my work or life they go in the brain vomit folder. So I get all the satisfaction of stream of consciousness "ubiquitous capture" (a la GTD) without the emotional burden of having to actually do all that non-critical stuff.

godfreyantonell 5y ago
brain vomit I like it
- WinterMount223 5y ago
  AKA brain dump.
lioeters 5y ago
That's interesting to hear about the inbox for quickly capturing thoughts, including brain vomit. Over the past few years I've used a similar convention, first called Journal, then Stream, then finally Archive. Everything goes in there, added to the bottom of the file: snippets, ideas, links, both personal and work-related stuff. I have a shell alias to append one-liners from the terminal, which I use throughout the day (and night). I review it regularly to move the important parts, especially plans and actions: - Archive - Do - Doing - Done I like that the folders sort alphabetically, and also in the order of how things flow.
- 5y ago

arthurofbabylon 5y ago

In my experience/opinion (disclaimer: small teams only) this single-item paradigm misses a lot of opportunities. I prefer the 60-30-10 approach (see https://minimal.app/603010 https://minimal.app/603010) as it is more experimental/open while still capturing great focus. To back that up, I’d like to acknowledge that almost all significant contributions I’ve witnessed weren’t the top priority item (instead, they’re some weird experiment). I am generally suspicious of the human ability to form a hierarchy of needs/opportunities, so I try to favor qualities like experimentalism, curiosity. Of course, this is all circumstantial. I’m sure some teams have hard deliverables where there is little value in exploring or doing things with no known measurable impact.

Spooky23 5y ago
It depends on how well the organization understands priorities, whether it does so consistently and how it is organized. Sometimes the business priorities and your chain of command priorities don’t mesh. That’s a good reason to be able to focus on multiple things.

eternityforest 5y ago

My priority is always decustomization. Anything that makes me think of the words "Bespoke" or "Artisinal" or worst of all "A perfect fit to the project needs" is where I look first for problems. I also look at anything that provides multiple ways to do the same thing. The JS community understands it better than anyone. At the application level, any program, be it amateur or professional, is almost always readable and maintainable. Because there's no interesting algorithms, no abstractions you haven't already seen in a design patterns list, and just generally nothing special about the code at all. They use libraries for everything. When you stop trying to write interesting and beautiful code, and stop trying to innovate at any level below the application, stuff gets a lot easier. Of course some projects really do have interesting technical challenges... but so many projects don't.

sarchertech 5y ago
> The JS community understands it better than anyone. At the application level, any program, be it amateur or professional, is almost always readable and maintainable. Oh man. We have worked on some very different JS applications.
- eternityforest 5y ago
  Maybe a better way to phrase it would be "Half the JS community understands that better than anyone, and the other half diarrheas out endless tiny useless frameworks and tries to get you to use them, but lets pretend that's not an issue".
  - sarchertech 5y ago
    Yes there’s that as well. But I have seen plenty of the type of code bases you’re praising that were a nightmare to maintain and debug. Everything is a trade off. Most developers probably shouldn’t write their own database engine. But at the same time adding another dependency to handle padding a number with zeroes is overkill. In practice after 2 decades doing this, I’m much more likely to run into an over reliance on libraries these days than the other way around.

jll29 5y ago

Thanks for sharing. I like how you provide text snippets for potential responses, as communications & stakeholder mgt. is something junior people often struggle with (not taught much at uni). Delivering one feature at a time may neither synch up with org roadmaps or go down well with mgt. expectations, but that depends where you work; I can see your approach might work in a smaller organization with overloaded team, where it may be a tool to create laser focus.

westcort 5y ago

Here are my key takeaways: 1. Say no a lot, up front 2. As early as you hear anybody else’s plans that involve your team doing something new, interject with a clear No 3. Everything your team already owns (that actually matters to your customers) needs to approach 0 maintenance costs 4. Ask your team what the biggest maintenance costs are 5. Write a Maintenance Roadmap to reduce your team’s costs 6. List all the new things you’re currently doing or planning to do, and put them in the New Features roadmap doc 7. Dig into your data, figure out where the drag on your team comes from, and drive it down 8. Drop everything except the top item on the list

mherdeg 5y ago

I'm currently reading through Johanna Rothman's "Manage Your Project Portfolio" and related literature and a bunch of this resonates: * Finishing work is more important than starting it * Teams working together on a single priority ("swarming") seem to be more successful than teams where each person is doing 1-2 things on their own A few subtle points in this article that made me think: * Keeping existing features working as well as customers expect is a great zeroth priority but it can be hard to know what customers actually expect. Absolutely the worst is when you carefully maintain a very reliable, feature-rich thing that no one particularly wants or uses. In an org without a dedicated PM, I'm never quite sure how to account for time spent on the product-management work of "listen to my customers about what they want from my service". * The article talks about engineers and stakeholders caring about "project X" and "feature Y". A bunch of literature suggests that anyone who is thinking this way is probably a bit lost -- they have lost sight of the business outcome that the team's work is supposed to be getting (more sales, quantifiably happier customers, fewer pager alerts interrupting engineers, whatever). If you can tie particular features/projects to outcomes maybe you can make it easier to explain why you've prioritized other work first (it makes bigger outcomes sooner).

nevir 5y ago
It's also worth noting that another way to reduce the cost to maintain your existing functionality (priority 0) is to actively _remove_ rarely-used or less valuable functionality
yayajacky 5y ago
You can figure out if people use or care about your service or not via observability.
- blacklivsmatr 5y ago
  Disagree. If you followed observability no text editor would do more than Notepad
  - bryanrasmussen 5y ago

CraigJPerry 5y ago

This is one of the best articles i can recall reading in a while. What a great piece. The third how to say no copy/paste example is poor compared to the first two.

codemac 5y ago

But what about Engineer FAANG: Who will get promoted based on individual impact? I've found convincing everyone else an engineering team needs to focus doesn't take too long. Managers are not shocked or confused to hear that a team drowning needs to do less. The individual engineers though, those can be the hardest. How does management split credit for group effort? Will the leader of the project get promoted, even though their contribution may in total be less than others on the project? What happens to my ongoing work, will I get skewered in "calibrations" when other teams talk about how I dropped everything to work on something to important to them?

deleted 5y ago

[deleted]

debesyla 5y ago

The prioritization tip reminded me of "Final Version" productivity system that I personally like. It's just one big-ass list of everything and you pick and do stuff at random (more or less). Yes, it sounds silly, but I found out that it works better than constantly re-ordering goals. :-) http://markforster.squarespace.com/final-version-faqs/ http://markforster.squarespace.com/final-version-faqs/

codemac 5y ago
Mark Forster is a hidden gem!

5350-uiop-1130 5y ago

"So now, you’ve committed to a big, one-time effort of saying No to everybody. " assuming you have the luxury to do that.

roeles 5y ago

One interesting thing I learned from the book "essentialism" is that the word priority used not to have a plural. It described the single most important thing to do.

auxfil 5y ago

It sounds like this is just an exercise in, not learning, but being forced to say "No" (a lot) out of a need for mental survival...in a work culture where priorities are constantly shifted (and this is the key). Instead, foster change where you can say "Yes, and" or "Yes, but", where there is a common understanding that sure we can work on it, eventually, as it's going into the backlog, that will need to be prioritised, or it goes at the bottom of the queue as any new thing should - as what is already in the queue, should already be prioritised. Obviously what is already in the stack can be shifted around as the business needs may necessitate the change in priority...but popping shit at the top of the stack constantly...that's not where you need to learn to say "No"...that's where you need to learn to say "Bye".