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

11–20 of 74 posts

Re: How To Do Less

#11

Post by fartcannon »

Negitivefrags wrote: post #7
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.

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…

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.

Re: How To Do Less

#12

Post by jimbob45 »

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.

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.

Re: How To Do Less

#13

Post by michaelcampbell »

laurent92 wrote: post #10
michaelcampbell wrote: post #8

Earlier quoted context omitted.

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

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

Re: How To Do Less

#14

Post by warlog »

jimbob45 wrote: post #12
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.

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.

Tell my manager (the CTO) that.

Re: How To Do Less

#15

Post by wereHamster »

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…

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

Re: How To Do Less

#16

Post by jaqalopes »

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.

Re: How To Do Less

#17

Post by arthurofbabylon »

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

Re: How To Do Less

#18

Post by malfist »

fartcannon wrote: post #11
Negitivefrags wrote: post #7

Earlier quoted context omitted.

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…

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.

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.

Re: How To Do Less

#19

Post by eternityforest »

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.

Re: How To Do Less

#20

Post by manmal »

michaelcampbell wrote: post #8
btrettel wrote: post #6

Earlier quoted context omitted.

What should someone do differently to have a more realistic workload?

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

I don’t mean to attack by going through these points, but would like to share a different perspective.

> Sales wins because they can claim "Feature X" being sold and get their commission

That’s true even if the product is high quality from the get-go, isn’t it?

> 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

I‘ve seen contractors, big and small, fired for providing complain-worthy software, multiple times. Some (most?) customers have enough on their plate and just want working software. Take Apple as an example. Their software quality seems to have worsened considerably in the last decade, but I don’t feel this has made myself more inclined towards buying their products. Infact, I‘m frustrated and have considered switching to other tech more than once.

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

I agree, support staff actually needs bugs to occur or else they will be scaled down. What’s the business case for having a huge support team though, if shipping high quality software is an option?

> 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

Why not, instead of working on authority and under-pressure skills, let PMs grow as leaders insider their team who can inspire hard work when the rubber really needs to hit the road?

> Software Development wins because they can now work on the secondary features, fixes, "skunk works" tech debt, etc. since this is now more important.

As an engineer I‘ve found it more satisfying to deliver great code instead of having old hacks thrown back at me, maybe with added time pressure because there’s data loss involved.

Post reply on HN