18
Decision logs (vitonsky.net)
all 36 comments
sorted by: hot top controversial new old
[-] overcast5348@lemmy.world 9 points 3 months ago

In a former workplace, we had a process that was close enough to what's recommended in the blog, and it worked well. Really well even, there were hardly any ego clashes, everyone would negotiate a consensus and we had "spike" tasks in our sprints so that we can take the time to think about and research complex problems.

And then the fire nation attacked...

A director left the firm and they hired someone from Amazon. He said that we should have a "bias for action", and got rid of this process, and a lot of other stuff we had going for ourselves using other such catch phrases.

Getting him as a director was probably the worst thing to happen as we were under pressure to deliver stuff quickly all the time, and we'd then have to rework most of the shit because of missed requirements, or tools used not being insufficient for the task at hand etc. He was okay with it though, because "we delivered (shit) quickly", and "our efficiency went up as indicated by the team velocity charts".

Pretty much the entire team had left the company in ~1.5 years, and customer satisfaction metrics were in the gutter when I left.

I don't know if he misunderstood "bias for action" and implemented it badly or if that's genuinely how people at Amazon operate, but I won't even think of joining AWS. Fuck that noise.

[-] vitonsky@programming.dev 5 points 3 months ago

Exactly! I see how a mindset “we delivered (shit) quickly” successfully reproduces itself, over and over in a lot of companies.

I think the actual reason is that business want to make money on promises right here right now. Business promises a lot of features to investors give money, and then business implement a lot of (shit) features. And then they continue kinda "okay, features broken, give us more money and we will fix it".

[-] otl@apubtest2.srcbeat.com 5 points 3 months ago

Getting stuff down in writing is a good step; crucial for sure. But the process/ritual of decision logs doesn't necessarily get you great analysis or effective outcomes. Two stories:

... or if your team uses arguments such as "let's use X because Microsoft uses it too", "let's do X because everyone else does", or "I used it in my previous project and it worked well, so let's use it here too" then your decisions are likely suboptimal in the long term.

I've read decision logs and design docs that have included this kind of reasoning. Many meetings, everyone gets their say, it's all written down. One time, I arrived a year or two into a project and I could indeed see how exactly they came to the decision that they did. The problem was that the reasoning was super weak. Over-emphasis on process, little on problem solving skills.

Other teams I've been on were fantastic problem solvers but super sloppy. If the right people were around, in the same room, they could solve things more cleanly in a fraction of the time of some company 10x the size. But for new staff, or if those key people were not around: chaos!

I guess my conclusion is that effective decision-making comes down to balancing a whole bunch of different behaviour.

In short: software is tricky.

[-] vitonsky@programming.dev 1 points 3 months ago

Sure, decision logs is just a step to fix a problems with decision making. Logs highlight a problems in decision making process and let you analyze a problems in your team. You still need an strong architect who may say "hey team, why your arguments so weak? it looks you are low skill engineers. make arguments more objective, or you will be fired" and then really fire weak engineers in team.

[-] otl@apubtest2.srcbeat.com 2 points 3 months ago

Logs highlight a problems in decision making process and let you analyze a problems in your team.

Yeah good point.

In that process-heavy project I joined, I could quickly see the problems; about 2 or 3 days. That meant when I was submitting code or reviewing the backlog I knew what kind of challenges I could make, and what would just be a waste of time. In others, it could take way longer - months! - to learn how the team actually deals with challenges and design.

[-] Ategon@programming.dev 5 points 3 months ago* (last edited 3 months ago)

If anyone still sees messages from the spammer in the comments let me know, federated removals are wonky sometimes

[-] joao@aussie.zone 3 points 3 months ago

Blocking the user also gets rid of the comments that haven't been removed through federation.

[-] RemiliaScarlet@eviltoast.org 1 points 3 months ago

Sneed, janny.

[-] PrinceWith999Enemies@lemmy.world 2 points 3 months ago

I can’t say what their corporate culture is like now, but they’ve had a pretty poor reputation in the past, including the notion that the lowest performing 10% should be fired every year. The Amazon folks I’ve known have been great people - not at all the Gordon Gecko types you’d imagine from that - but culture in large corporations varies a lot by the team you’re in.

I came up with a saying back in the 90s when I was doing the startup scene - “Do you want it right, or by Tuesday?” Sometimes they do indeed need it by Tuesday. More of the time they have no idea why you need the extra days to get it right. But it’s really important for those in a leadership position - whether they’re managers or senior engineers - to push back and set expectations.

[-] ThuleanPerspective2@eviltoast.org 1 points 3 months ago

SEETHE AND SNEED COPE HOT POCKETS AND ON LEMMY CLEAN IT UP FOR FREE SNEED CLEAN IT UP COPE CLEAN IT UP SNEED'S AND FOR FREE SEED SNEED SNEED'S CITY SLICKER DILATE SEED JANNY DILATE ON LEMMY CLEAN IT UP JANNY AND CITY SLICKER SUCK CHUCK SEETHE SNEED'S SUCK SNEED'S I CAN'T SNEED'S ON LEMMY SEETHE SEETHE JANNIES SNEED'S CITY SLICKER I CAN'T SUCK JANNIES FEED DILATE HOT POCKETS CITY SLICKER

this post was submitted on 21 Mar 2024
18 points (95.0% liked)

Programming

16197 readers
503 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS