141–150 of 165 posts
This is a fun experiment along the same lines: https://m.youtube.com/watch?v=Dr67i5SdXiM The result surprised me even though I know intellectually I should have expected it.
Earlier quoted context omitted.
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-ti…
Very, very few people are paid to find the "optimal" anything. The trust you're looking for can be found once you recognize what it is you're actually being asked for (again, rarely 'optimal', just 'functional').
Earlier quoted context omitted.
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-ti…
It can go wrong if you have shitty teammates, a detached PO, a selfish team lead, etc. So will everything else.
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…
You end up with an ever increasing list of "completed" tasks until you eventually reach a shipping point and you can have a celebration party or whatever.
The hard part is then managing deadlines and expectations from then on with whoever wants the product, where good managers can make progress feel very present and visible, which in turns makes speed feel predictable and everyone can plan with realistic expectations.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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-ti…
Ah, you've already fallen into the trap; it's not about the "optimal", it's about the "functional". Very, very few people are paid to find the "optimal" anything. The trust you're looking for can be found once you recognize what it is you're actually being asked for (again, rarely 'optimal', just 'functional').
Are you aware of the traps you're currently in?
Earlier quoted context omitted.
Ah, you've already fallen into the trap; it's not about the "optimal", it's about the "functional". Very, very few people are paid to find the "optimal" anything. The trust you're looking for can be found once you recognize what it is you're actually being asked for (again, rarely 'optimal', just 'functional').
We just got started and while I still can't find any obvious deficiencies with your thinking, I find you're investing far too much energy in telling me how I should work and not allocating nearly enough energy into describing what your problem is. Are you aware of the traps you're currently in?
Up to you.
Earlier quoted context omitted.
Shipping an 80% solution is ok... it leaves a bad taste, but its "ok". The problem becomes more-so when the next 80% solution is shipped on top of the previous 80% solution. And that just gets demoralizing after a time when one looks at the stack of 80% solutions on top of 80% solutions that needs to get fixed up (but "we don't have time to do that").
One thing I tell our developers (and POs) is that we can only tolerate 80% solutions so long as they also produce 120% solutions (or give us additional time/scope for them) at approximately the same rate.
Sometimes you have to let developers overengineer something or work on something a little too much so they don't go insane and take you with them. Or quit and go somewhere else.
Few things affect consistent delivery as much as bad employee retention and burnout.
Earlier quoted context omitted.
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…
I think you need a way to have deadlines, without that you can easily fall into over engineering or completing other unrelated tasks.
The counterargument about deadlines is always some sad sack story about shipping for the holidays or having tax software done in time for the start of the tax season. Those stories are all true, but they have fuck all to do with deadlines.
Continuous Delivery means that if you need something by Friday, the conversation is about the relative risk/reward of shipping the build we're going to do on Tuesday, or the one we did last Tuesday, or one from three weeks ago. Not whether the important features will be done by CoB on Friday. Because the critical bits of the important features were finished over a month ago and now we're just making everything pretty.
What happens is that "the work expands to fill the time" is not just a law that applies to developers, it also applies to management in spades. "Sure, we need this feature, but why don't you hold off on doing that while we do this other thing that feels important but only because I told someone it would happen and I'm too much of a coward to tell anyone that I was wrong about something, and I outrank you so you and your social life are going to pay for my mistakes, not me and mine."