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

51–60 of 74 posts

Re: How To Do Less

#51

Post by yayajacky »

mherdeg wrote: post #41

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

You can figure out if people use or care about your service or not via observability.

Re: How To Do Less

#52

Post by blacklivsmatr »

yayajacky wrote: post #51
mherdeg wrote: post #41

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

You can figure out if people use or care about your service or not via observability.

Disagree. If you followed observability no text editor would do more than Notepad

Re: How To Do Less

#53

Post by sdoering »

XorNot wrote: post #37
sokoloff wrote: post #26

Earlier quoted context omitted.

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

I wasn't in the military and my knowledge stems only from others' personal accounts and what I read about it.

I agree for the need of context. Because only then can the operative understand why it is important what they are doing and in case of decisions to be made on the ground either decide or clarify with the org structure.

I know that unit commanders are being (ideally) briefed like you described. But how does this context trickle down to their people? Does the military have a means to ensure the passing down of relevant and qualitativ information?

Because that is what I personally see as a problem more often than not. The information is lost at the lower rungs of the ladder.

Re: How To Do Less

#54

Post by codemac »

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?

Re: How To Do Less

#56

Post by bryanrasmussen »

blacklivsmatr wrote: post #52
yayajacky wrote: post #51

Earlier quoted context omitted.

You can figure out if people use or care about your service or not via observability.

Disagree. If you followed observability no text editor would do more than Notepad

most text editors aren't services though?

Re: How To Do Less

#57

Post by debesyla »

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/

Re: How To Do Less

#58

Post by Cthulhu_ »

mherdeg wrote: post #41

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

> 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

It's an interesting one, same as e.g. pair programming; people (and I'm speaking for myself but I'm sure others will agree) prefer to work alone, because software engineering is difficult, brainy work, whereas swarming and pair programming are social activities. If you're like me - introverted, probably on the spectrum, etc - it's something that is well out of your comfort zone.

Re: How To Do Less

#59

Post by eternityforest »

sarchertech wrote: post #38
eternityforest wrote: post #35

Earlier quoted context omitted.

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…

Left pad was more of an issue with mutable dependencies it seems like, and with using tons small dependencies instead of larger trusted ones.

Yarn's zero install and the like could probably have stopped that from ever being an issue. Many lodash/underscore/whatever utilities have that feature, and with dead code removal I don't know why people still use micro libraries.

There's of course malware concerns, but that's why you don't use things that aren't popular with a million eyes on them unless you want to check it yourself.

Re: How To Do Less

#60

Post by maccard »

gmfawcett wrote: post #43
wereHamster wrote: post #15

Earlier quoted context omitted.

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

I don't think a client-facing changelog tells us much at all about how the dev-team celebrates. Calling it a cultural issue seems off. Perhaps in some cases it is. But if the process truly is a grind, then the only target left to celebrate might be a proxy metric that the devs don't relate to. (Congrats on staying within 0.5 sigma of our mean time to deliver this week, let's have a pizza.)

Celebrating doesn't have to be a reward, and assuming that celebrating a release involves a material reward is certainly cultural. To me, the important part of celebrating a release/milestone is pausing and reflecting on what has changed. That only needs to be a small nod.
Post reply on HN