3 ms·

>If you can make a decision and you don’t think it’s going to get you fired, just do it. This advice only applies to people with enough experience. I'm thinki

>If you can make a decision and you don’t think it’s going to get you fired, just do it. This advice only applies to people with enough experience. I'm thinking of a certain ex-employee that followed that advice all the time, despite us constantly correcting him. Even on their final day, they was still insisting that they was doing good work. To this day, we are still finding code they wrote or modified that is wrong or broken in horrible ways. Why? Because they didn't have the experience to know the difference between a quick fix and a good fix, and when to employ them. (Hint: The "quick fix" is almost never good enough.) My personal line is a long way away from "Will it get me fired?" and I've got decades of experience. I've always said that programming is all about making assumptions. And I'll frequently send off an email stating some assumption I'm making and start coding based on that assumption. If I get corrected, I can change pretty quickly. But I'm usually right. But just not asking? Forget it. If I'm unsure enough to bother with sending a 2-line email, it's worth asking.

sharmanaetor 9y ago
Isn't the solution to this a good code review process? Even the author of the article states "I either wrote up a plan and shared it beforehand, or I just announced what I’d done after it was completed". This is very similar to asking someone review your code.
- wccrawford 9y ago
  Again, my comment was about having the experience to make these decisions properly. I'm sure he didn't tell people about every single decision he made, only the ones he needed validation on. However, I noticed that he only told others after it was completed sometimes, which is often far too late. Experience lets you know which ones that's okay for, and which ones it isn't.
naasking 9y ago
> I'm thinking of a certain ex-employee that followed that advice all the time, despite us constantly correcting him. The natural addendum then is, "listen to feedback".
dep_b 9y ago
You are talking about programming, but this is about questions like "should I add feature x" or "should I try to improve the build process by using tool y". Somebody that can't program still might take the right business decision. I had the "pleasure" of maintaining the ColdFusion "programming" of a guy that sold airline ticket systems to a lot of different companies and in terms of business decisions he's about a few millions dollars better than I am.
- wccrawford 9y ago
  My examples were programming, but I also make decisions about processes and tools. They follow the same logic. If I'm unsure, I ask and go ahead instead of sitting and doing nothing. Only if I'm very, very certain do I not bother asking. And I've certainly got non-programmers around me that make business decisions all the time. It's their job. I'm not sure how that's relevant? The same thing applies: They should only be doing it without consultation if they have the experience to back it up.

sharmanaetor 9y ago

Isn't the solution to this a good code review process? Even the author of the article states "I either wrote up a plan and shared it beforehand, or I just announced what I’d done after it was completed". This is very similar to asking someone review your code.

wccrawford 9y ago
Again, my comment was about having the experience to make these decisions properly. I'm sure he didn't tell people about every single decision he made, only the ones he needed validation on. However, I noticed that he only told others after it was completed sometimes, which is often far too late. Experience lets you know which ones that's okay for, and which ones it isn't.

naasking 9y ago

> I'm thinking of a certain ex-employee that followed that advice all the time, despite us constantly correcting him. The natural addendum then is, "listen to feedback".

dep_b 9y ago

You are talking about programming, but this is about questions like "should I add feature x" or "should I try to improve the build process by using tool y". Somebody that can't program still might take the right business decision. I had the "pleasure" of maintaining the ColdFusion "programming" of a guy that sold airline ticket systems to a lot of different companies and in terms of business decisions he's about a few millions dollars better than I am.

wccrawford 9y ago
My examples were programming, but I also make decisions about processes and tools. They follow the same logic. If I'm unsure, I ask and go ahead instead of sitting and doing nothing. Only if I'm very, very certain do I not bother asking. And I've certainly got non-programmers around me that make business decisions all the time. It's their job. I'm not sure how that's relevant? The same thing applies: They should only be doing it without consultation if they have the experience to back it up.