I just don't agree. Much better to set a culture where people are encouraged to put their ego aside and accept being corrected immediately and politely. The repetition and fast iteration is good for learning.
Don’t point out something wrong immediately
61–70 of 180 posts
Re: Don’t point out something wrong immediately
#62Earlier quoted context omitted.
> we never got the time to fix it The older I get the more convinced I become that this is Learned Helplessness. "We didn't have time." is essentially the same dodge as "C'est le guerre" was in France. "We don't have time" is a conversation killer. "We are working on that bit by bit" is essentially the same statement once you've subtracted the helplessness. Nobody is ever gonna schedule time for you to have integrity…
The goal of writing software is rarely to produce a piece of well-engineered software. More commonly, the goal is to produce a product in a given time frame using the team of engineers available, which may be of variable quality. If you’re trying to make the software perfect, you’re likely doing something very wrong.
Businesses are in business to stay in business.
Frequently nobody notices how much decline in capability the team is struggling with because 1) the change comes slowly, and 2) people are getting 'better' at taking calculated risks that keep the tempo up, masking the real situation until the company hits a brick wall and all estimates go from 3 weeks to 3 months overnight.
As a customer these sorts of changes in behavior are hard to accommodate. It's almost always better to set an expectation that things take just a little bit longer than the customer would prefer but the software actually works when we do get it.
When you have a date driven 'emergency' you deliver a small increment that handles the particular situation the customer actually has. Everyone mistakes wants for needs. When you foster that then you become part of a codependent relationship at best, exploitative at worst.
Also if you swoop in and clean up everyone else's mess every time, they never experience any backpressure and you end up burning yourself out while they learn absolutely nothing. See earlier reference to The Power of No.
Re: Don’t point out something wrong immediately
#63We had a DevOps engineer who was brutal this way. Personally I found it only occasionally annoying, but our PM almost fired him several times. I talked him down by pointing out that risk aversion is a good quality in an engineer. When we interview for engineers, we always ask candidates if they are risk-taking multi-taskers, because those are desirable qualities... In some other field.
I appreciate the sentiments. i think the cert for https://cieloconnects.com/ is expired.
It isn’t expired, look more closely at it. (And, cough, see thread topic)
Re: Don’t point out something wrong immediately
#64Earlier quoted context omitted.
I now use the discovery of something obviously stupid as a fairly reliable detection mechanism for either a broken system/process and/or a context cue that I am missing some larger, typically organizational, part of the picture. I also often use my internal voice to say "shut up and listen to myself," when I want to immediately engage in a conversation or correction.
The problem with this heuristic is that every nontrivial piece of software contains something obviously stupid. Which sounds like a refutation of the validity of this inference altogether, but—no, take heart: It still works, because it turns out every organization has a broken system or process or larger organizational dysfunction. So in a sense yes, this logic works, but you can save yourself some steps.
> The problem with this heuristic is that every nontrivial piece of software contains something obviously stupid.
Sturgeon's Law has entered the chat.
90% of everything is crap.
Once is happenstance. Twice is a coincidence. Three times is a conspiracy. Re: Don’t point out something wrong immediately
#65A particular flavor of this I've become familiar with over the last few years deals with how you enumerate problems rather than bringing up a single one.
It is, I think, a variant of Burying the Lede where you start out with the serious issue, but then you keep going on and on for so long that eventually everyone forgets that the first point you brought up was "The building is on fire."
Sometimes the lede should go at the end, be repeated at the end, or you should keep your comments to what can fit comfortably into short term memory. No flooding.
Re: Don’t point out something wrong immediately
#66This is the hardest lesson I had to learn in my consulting work. It is is especially important if you are not familiar with the full context - which is almost never the case. The main insight for me was that yes, things can be "wrong" due to lack of knowledge or incompetence. Sometimes. But more often than not there is a good reason. Like: * we know this is stupid, but we had immense time pressure and this was the on…
The other side of this is how nearly every engineer is going to trash talk the prior coders, when they inherit a codebase. So I already know to ignore it.
> trash talk the prior coders
This is one of the things that make the software life worth living! It's even better when you realize that the prior coder was, in fact, your own damn self.
Re: Don’t point out something wrong immediately
#67When "something is wrong" in a large system, it might not be straightforward to say which detail is wrong exactly. One of the reasons that you shouldn't "point out something wrong the moment you see it" is because there might be multiple candidates for the "wrong" thing that needs to be addressed, and addressing any of them is enough to make the system as a whole "not wrong" (or at least, less wrong). If a colleague…
Coherent But Wrong is a known failure mode for architecture. All of the parts make sense when taking in context of all of the other parts, but when you step out of the system the whole thing seems a little nuts. It's basically the Echo Chamber (circular reasoning) condensed into code.
Re: Don’t point out something wrong immediately
#68Earlier quoted context omitted.
Even with a code review, though, you might want to wait until you’ve digested the rest of the review instead of firing off a comment. Maybe it makes sense in context. Or maybe there are bigger fish to fry and it’s not worth quibbling over small things.
> Or maybe there are bigger fish to fry and it’s not worth quibbling over small things. I've taken this approach with one of our engineers, and now we have a huge pile of "small things" that has created some pretty serious technical debt. My perception is that they don't try to understand what I'm pointing out, and come up with rational for how they have it. I think I have a lot to learn.
I think it's a matter of picking a few things you're going to comment on, and any time the person actually stops needing to be corrected on one of them, you add one of the others in. Any good teacher or mentor does this. But it's a balance because you need the student to see that the reason you're complaining about something new is because they have in fact progressed, and we have moved on to the next thing to address (which has probably always been there)
Re: Don’t point out something wrong immediately
#69Earlier quoted context omitted.
> Or maybe there are bigger fish to fry and it’s not worth quibbling over small things. I've taken this approach with one of our engineers, and now we have a huge pile of "small things" that has created some pretty serious technical debt. My perception is that they don't try to understand what I'm pointing out, and come up with rational for how they have it. I think I have a lot to learn.
I'm still learning too, but I think that something I'm trying to develop is a sense for the longer-term costs and implications of apparent defects. - Is this a component that every engineer is going to interact with and that will stay with the company for decades? - Can this technical decision be reversed easily? Either in the sense of an individual commit revert, and/or in terms of a series of code changes? - Is thi…
> Can this technical decision be reversed easily?
One of the most exhausting failure modes that I've had to deal with is deciding not to decide. Some people will build elaborate Rube Goldberg machines so that they "can change their minds later" but in fact what they've done is decided that choices are now everybody else's problems.
There's a whole hell of a lot of rewards to having the maturity to be able to say "I was wrong" and move on. Writing code in a way that you could rework it to use a different library to accomplish the same thing is making a reversible decision. Creating a rules engine to let a config file make the choices and leaving a cartesian product of states (75% of which are invariably illegal, which you are just supposed to know) is definitely, definitely not. Just pick something, man.
Re: Don’t point out something wrong immediately
#70Never point out something is wrong immediately. Immediately set off to work on a secret rewrite, and then point out what is wrong in a big commit sent to the review system 17 weeks later!