Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How To Do Less

alexturek.com

Post reply on HN
Print view View original

31–40 of 74 posts

Re: How To Do Less

#31

Post by creakingstairs »

michaelcampbell wrote: post #13
laurent92 wrote: post #10

Earlier quoted context omitted.

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.

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 jou…

> There's no "big win".

Even though you are shipping piece by piece, don't you still have a "big win" that those small pieces make up to be to celebrate? For example, my old team had to deliver MFA. This was broken up and was "released" continuously. We celebrated when the whole feature was "done".

Re: How To Do Less

#32

Post by godfreyantonell »

jaqalopes wrote: post #16

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 stu…

brain vomit I like it

Re: How To Do Less

#33

Post by WinterMount223 »

godfreyantonell wrote: post #32
jaqalopes wrote: post #16

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 stu…

brain vomit I like it

AKA brain dump.

Re: How To Do Less

#34

Post by a1445c8b »

sdoering wrote: post #4

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

> From my experience people "on the ground" often miss out on the strategic long term goals.

This has been my experience too, having been an engineer for the past 3 decades and to this day.

And even if the CTO does a great job of communicating strategy, we on the ground tend to get lost in the weeds just because of the nature of our work.

I think outright saying “no” because we don’t think it’s hight priority is a dangerous move that makes the team a target for future performance reviews.

We should, instead, find a common ground and sell our priorities rather than impose them.

Re: How To Do Less

#35

Post by eternityforest »

sarchertech wrote: post #24
eternityforest wrote: post #19

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…

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

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

Re: How To Do Less

#36

Post by lioeters »

jaqalopes wrote: post #16

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 stu…

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.

Re: How To Do Less

#37

Post by XorNot »

sokoloff wrote: post #26
jimbob45 wrote: post #12

Earlier quoted context omitted.

Why would you ever give a developer a task without ensuring they understand your strategic long-term goals? That sounds like a sure-fire way to end up with a product that doesn’t match your vision.

There’s plenty of work (possibly a majority of it) in the industry that can be of the form “take a ticket, do the ticket, close the ticket”. Someone in the cascade has to understand the strategy and product vision to ensure you get a good overall outcome, but it doesn’t have to be the 22 year old SWE-1.

My benchmark for this being wrong is that military briefings don't do this if they don't have to.

The gold standard for a military briefing is that it includes a high level overview of the global, regional and local situation before getting into specific orders and this was adopted because small unit doctrine depends on unit commanders having enough context to make informed independent actions in lieu of direct chains of command being available.

Everytime I've watched a ticket languish in any organisation, it's always because people don't feel a need to give context. They think they understand what they're asking for, it doesn't match reality and then the back and forth culminating in a bunch of calls and finally someone explaining the goal happens.

Re: How To Do Less

#38

Post by sarchertech »

eternityforest wrote: post #35
sarchertech wrote: post #24

Earlier quoted context omitted.

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

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

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.

Re: How To Do Less

#39

Post by qwertyasd »

jaqalopes wrote: post #16

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 stu…

No post body was provided.

Re: How To Do Less

#40

Post by westcort »

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

Post reply on HN