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

Finishing what you start makes teams more productive and predictable

lucasfcosta.com

Post reply on HN
Print view View original

131–140 of 165 posts

Re: Finishing what you start makes teams more productive and predictable

#131

Post by supernovae »

"Finishing what you start" has no meaning. None.

In the weakest definition of "finish what you start", it means "I cleaned my desk, I finished what I started" but the reality is - the only way for this to be "done" is to have no more work and no more desk. The work of maintaining that desk cleanliness is never ending work and herein lies the problems we create for ourselves.

Take the burger example and put it in a system - you're on to the next burger and some shmuck wants it without ketchup and with extra pickles. Then you have to cleanup the burger stand but cleaning up one day won't be the same cleanup as another and sometimes you may have to shutdown to deep clean - it's never done until you forever stop making burgers and close shop.

For me, it's all about mindset. I look at work as rewarding when I never stop learning. The notion of done is what makes people crazy because it's never about the work being done, it's about not want to do the work to begin with and not seeing any value in doing it.

My kids rooms are messy, i say they're lazy, but really they see no value in the work - to them, it's a waste of time. It keeps them from doing other things they would rather do. I laugh when they say they're done cleaning their room because without a doubt, not even a day later, it will be a stink mess again.

Also, context switching... these discussions never make sense because they're always discussed in terms of state as an exception to the system. Your flow state is uniquely you, the system you operate in is complex and dynamic.

I think all to often people put way too many words to paper trying to control complex interactive systems when they should really make them safe and resilient to monitor, observe, anticipate what's next and have the autonomy to make decisions.

That autonomy and decision making and anticipation still requires effort and work - and i'll be honest, some of the best flow state is safely operating in complex dynamic systems while being able to mental model your position in it and have empathy for others - realizing that your model is yours and others will have there's.

Done is imaginary.

Re: Finishing what you start makes teams more productive and predictable

#132

Post by BurningFrog »

yakubin wrote: post #124
BurningFrog wrote: post #107

Earlier quoted context omitted.

The standups I've been in are about reporting to the rest of the team what you're doing. This way, everyone has a clue what's going on, and can also chime in with advice and questions.

I'm not against stand-ups per se, just against daily stand-ups. Currently I'm in a team which does three a week. That's at least tolerable, but if it was up to me, I'd opt for once a week. Daily made me feel that I had no agency over my work, that everything to the tiniest detail needed to be negotiated with someone, most often the manager. Less agency means lower engagement in work. At least for me. I do know that t…

We must mean very different things by "standups".

My standup messages are mostly "I'm working on adding feature X, it's going well", or "I'm fixing bug Y, and I wonder how to handle Z".

Usually that's it. Sometimes there are questions or discussion about details. It serves to keep the team aware of what's going on.

If your team is argumentative it can drag out and be a drain. That's when it is up to the manager to break it off and move any needed discussions somewhere else. If your manager is the argumentative one... you have a bit of a problem.

Re: Finishing what you start makes teams more productive and predictable

#133

Post by rightbyte »

morelisp wrote: post #125
rekrsiv wrote: post #116

Earlier quoted context omitted.

The problem with acceptable bounds is when they're applied uniformly to all your code monkeys without adjusting for experience and mental state at any point in time and we can't sample those values in real-time. Performance metrics are often too noisy to be useful so proper bounds are too difficult to set without the "experience" of seeing the team work over a very long period of time. Predicting the future of a high…

What pop nonsense. An unpredictable software engineering team is itself a barrier limiting the creativity of the product team (and vice versa). If you don't want to be treated a crank to turn, you also need to bring some self-reflection, compromise, and willingness to communicate to the table.

The only way to make good reliable estimates is to pad and roll your thumbs until the nominal time is up.

If there are teams that meet targets they are padding for king and country.

Re: Finishing what you start makes teams more productive and predictable

#134

Post by Kaze404 »

boffinism wrote: post #43

I once worked in a VERY chaotic startup with near-constant pivots and priority shifts. In each case, at the time, the change in direction could be justified... but morale was chronically low, particularly among software engineers. I spoke to one who, after a year, mournfully revealed that none of the code he had written had ever shipped. He, and most of his colleagues, burnt out and dropped out pretty fast.

I just left an environment like that after almost 2 years. It got to me so bad that I can't even remember what it's like to work somewhere more organized, which is why I'm excited to start my new job soon.

Re: Finishing what you start makes teams more productive and predictable

#135

Post by rekrsiv »

morelisp wrote: post #125
rekrsiv wrote: post #116

Earlier quoted context omitted.

The problem with acceptable bounds is when they're applied uniformly to all your code monkeys without adjusting for experience and mental state at any point in time and we can't sample those values in real-time. Performance metrics are often too noisy to be useful so proper bounds are too difficult to set without the "experience" of seeing the team work over a very long period of time. Predicting the future of a high…

What pop nonsense. An unpredictable software engineering team is itself a barrier limiting the creativity of the product team (and vice versa). If you don't want to be treated a crank to turn, you also need to bring some self-reflection, compromise, and willingness to communicate to the table.

A product team without an engineering process can reliably do nothing (but not vice versa). If you don't want to be treated like an optimization that only makes sense in a large money-printing machine, you need to stop optimizing for money-printing.

Communication isn't just about gracefully accepting expected input and feeling good about getting it. It's also about reliably figuring out the logic behind unexpected input to gracefully bridge the gap.

So hacking means creatively staring at unpredictable systems until they make sense. You can timebox how long you can afford to stare at it and then incrementally review whether your staring method should be improved or whether it makes more sense to do something else after the timebox but you shouldn't poll the state of the world every day.

TL;DR: Stop opening the oven door every 5 minutes, you're losing heat every time. Muffins don't like that.

Re: Finishing what you start makes teams more productive and predictable

#136

Post by d0mine »

morelisp wrote: post #76
d0mine wrote: post #56

Earlier quoted context omitted.

It is a rookie mistake to think that programming is splitting a big task into smaller tasks that are splitted into even smaller tasks, and that once the process is done, you can use mindless drones to complete these microtasks. It assumes the perfect knowledge, the fixed work volume. In practice, you don't know how much work might be required (a small task may blow up). It is inevitable that sometimes you have to dro…

It is also a rookie mistake to think that just because some tasks might blow up, you can't accurately estimate a large class of them to within a reasonable confidence window (say, within one day 99% of the time), and likewise identify those tasks with a large chance of blowing up. Breaking down tasks into smaller tasks seems to help build this skill faster in some people. If you don't want to be a mindless drone, you…

It does not matter that you can estimate 99% of [simple] tasks. The total time is dominated by complex (big uncertainty) tasks that you can't predict/estimate reliably (e.g., think lognormal random distribution).

Programmers are good at automating predictable boring tasks. If you are competent, there always be unpredictable elements in your work.

Software estimation is similar to the coastline paradox if you don't know how small your measuring stick should be in advance. The smaller the stick the longer the coastline might be (fractal nature). An analog of taking a big software task, splitting into several smaller tasks and using it as an estimate would be like drawing a square on a map and rely on it as a good estimation for the coastline length that you can use for any scale (it is wrong if the coastline is a fractal (if the software task is complex)) https://youtube.com/watch?v=I_rw-AJqpCM

Re: Finishing what you start makes teams more productive and predictable

#137

Post by seagullrific »

jraph wrote: post #23
jmathai wrote: post #17

In my experience on small teams that I've been on - a key motivator for people is shipping products and features. The sooner and more frequently you can do this the more positive reinforcement there is for the entire team - not to mention reduced risk of something never making it to the target users. Teams that have figured out the optimal way to get product and features into the hands of users as quickly as possible…

Releasing is great. Unused work is quite sad. A big condition for motivation though is if people are not pressured to rush features. Being in a rush does not work long term and not being happy with the quality of the work done is very demotivating and impairs the sense of meaning. Micromanagement too. Personally, the two week sprints and daily stand-ups did this to me in my previous job, but I can see they could be a…

Had the exact-same experience in a previous role: pressured to rush to release to meet a(n arbitrary) sprint deadline and then - the deadline not met - the work left unreleased. Super frustrating and almost caused me to quit at the time.

Re: Finishing what you start makes teams more productive and predictable

#138

Post by TameAntelope »

rekrsiv wrote: post #108
morelisp wrote: post #76

Earlier quoted context omitted.

It is also a rookie mistake to think that just because some tasks might blow up, you can't accurately estimate a large class of them to within a reasonable confidence window (say, within one day 99% of the time), and likewise identify those tasks with a large chance of blowing up. Breaking down tasks into smaller tasks seems to help build this skill faster in some people. If you don't want to be a mindless drone, you…

It may also be a mistake to assume that it's always possible to break down a system into logical parts and simplify that system until it fits your complexity budget prior to development without knowing the upper bound of your problem's complexity. Some things still have to be discovered before they can be measured.

Your job as an engineer, broadly, is to bring order to the disordered. You only rarely have enough time to fully understand the problem before trying to solve it.

The real, fundamental mistake being danced around here is the failure to recognize the inherent tension between product and engineering.

Stop fighting, start harmonizing. Understand how you fit into the bigger picture, and “deadlines” vs. “complexity” will start to make more sense.

It’s obvious that you aren’t going to make money off of nothing, so you have to build something, and it’s obvious you can’t build something out of thin air, so figure out how to build small, specific things that people will pay for.

Re: Finishing what you start makes teams more productive and predictable

#140

Post by rekrsiv »

TameAntelope wrote: post #138
rekrsiv wrote: post #108

Earlier quoted context omitted.

It may also be a mistake to assume that it's always possible to break down a system into logical parts and simplify that system until it fits your complexity budget prior to development without knowing the upper bound of your problem's complexity. Some things still have to be discovered before they can be measured.

Your job as an engineer, broadly, is to bring order to the disordered. You only rarely have enough time to fully understand the problem before trying to solve it. The real, fundamental mistake being danced around here is the failure to recognize the inherent tension between product and engineering. Stop fighting, start harmonizing. Understand how you fit into the bigger picture, and “deadlines” vs. “complexity” will…

While I agree that my job is broadly to bring order to the disordered, I would prefer if the disordered accepted that my proposed way of doing things will eventually achieve order without doubting me every morning, as it is after all my job to find the optimal algorithm to order things since I have myself optimized myself to find just that.

I don't want to fight, I'm simply unable to process your disorder in real-time.

Post reply on HN