Don’t point out something wrong immediately
151–160 of 180 posts
Re: Don’t point out something wrong immediately
#152Earlier 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.
Re: Don’t point out something wrong immediately
#153This 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…
I’m always surprised at “refusal to work together.” The entire point of a company is to organize people to work together, how do workers like that get promoted?
Re: Don’t point out something wrong immediately
#154I've learned to ask questions instead of utilizing call-out culture. I can ask what some component is doing, strategy to scale, etc... That usually works very well in place of me saying that I perceive something is "wrong". Example I saw empathy in the tags. How does empathy apply to this post?
Empathy applies in two ways. Firstly in realizing that saying 'you are wrong' is hurtful and can be damaging to relationships. Secondly in realizing that other people might already know your objection, but had reasons for proceeding this way anyway.
The second point is a great way to encourage silencing dissent. Interrogating why people made decisions is part of both science and engineering. Assuming they made all the right choices sounds odd to me.
Re: Don’t point out something wrong immediately
#155Earlier 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.
...Tell that to the programmers writing robust, highly-tested systems for aerospace/flight applications, which have to be designed to be as safe/'perfect' as that can be, since mistakes can not only cost millions, but be directly fatal to end users.
I can accept the proposition that the general commercial end goal of software development is the product, rather than a _perfect_ product.
But your claim that one's striving to achieve perfection in software is "very wrong" is a questionable statement, and ignorant of the 'engineering' aspect of software development.
Re: Don’t point out something wrong immediately
#156Earlier quoted context omitted.
You are overthinking it. An alternative to “spot flaw” here would be “point out flaw”. The author is just giving an example on how engineers have a habit of pointing out flaws
> The author is just giving an example on how engineers have a habit of pointing out flaws It's strange that finding flaws is framed negatively. This ability is a positive trait in software development.
Re: Don’t point out something wrong immediately
#157Earlier quoted context omitted.
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.
> If you're trying to make the software perfect, you're likely doing something very wrong. ...Tell that to the programmers writing robust, highly-tested systems for aerospace/flight applications, which have to be designed to be as safe/'perfect' as that can be, since mistakes can not only cost millions, but be directly fatal to end users. I can accept the proposition that the general commercial end goal of software d…
If you don't let your engineers take out some of their frustrations on the code, they will take it out on someone else. Some of your 'inefficiency' is bridge-building. Like any other relationship, sometimes you have to humor the other person with requests that seem unimportant to you.
In fact most service businesses are built on that mismatch - you want something to happen but you hate doing it and it's worth $N an hour to get someone else to do it, while I hate it less and $N/2 an hour sounds like a pretty reasonable incentive to do it for you.
But part of my complaint here is discovering a class of people who talk the talk about how they wish they could do something, but the moment the backlog empties out they sit around saying there's nothing to work on. The first time I encountered this, and started to wonder how many bullshitters there were at the current place, I was furious. Because for once in a blue moon integrity actually was on the schedule, and I discovered people who had none. And of course this could not be a unique situation I was in. How many other people had been saying pretty words they didn't mean my entire career?
That was, all told, probably one of the worst days in my career. Being laid off is always the worst after it happens, but when you land in something better that starts to fade. Meanwhile this experience is just there. Some days it's worse, others it's better, but my life was easier when I thought everyone was just doing the best they could.
Re: Don’t point out something wrong immediately
#158Earlier quoted context omitted.
I said a primary concern and I stand by it. Yelling or being unpleasant in the name of getting people to agree with you is counterproductive to getting stuff done. People, at least competent people, don't have to put up with your ego and can go do just as interesting things with people who are more pleasant to be around than you. I mean, unless you are Elon Musk or Steve Jobs reincarnated.
Who said anything about yelling...
In that case, it's one of those weird brain associations that pops up.
I stand by the rest, that being unpleasant or hard to work with will make it harder to do cool things. Unless you are literally Elon Musk, Steve Jobs or maybe a few others.
Re: Don’t point out something wrong immediately
#159Earlier quoted context omitted.
I actually really like the linked article ( https://blog.the-pans.com/wrong/ ), I think it is supportive of ideation and prototyping. It really made me glad to read that. When learning a new language or environment, there's no place to get an expert to pair program through it (or is there?) Baby steps always look wrong, especially when the baby keeps falling over. It's just part of growing up. Case in point I recentl…
> become a better candidate is this a (worth) goal in itself? better person, better engineer, better manager, .. maybe. but Candidate.. eh. Think about it.. And do what you would have done/doing if you were already that wanted XYZ.
"And do what you would have done/doing if you were already that wanted XYZ". I am asking how long to put a chicken in the oven for it to taste good. To be honest, your reply makes me feel like I am reading: "Just eat it as though it were already done cooking in the oven."
I feel like some more specific guidance about timing could help me finish baking it faster. At the moment I am looking for a job, I will use my earnings to support my family, raise a kid, invest a little cash in my side projects, obviously none of this happens without the job. So, it is why I want to be the best possible candidate and am looking for advice about how to spend my time. My previous positions were on an equity-heavy basis and not give me earnings to enable me to do the above.
Re: Don’t point out something wrong immediately
#160Chesterton's Fence https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence reforms should not be made until the reasoning behind the existing state of affairs is understood
What's the difference between this and "don't change things you don't understand". It would make it clearer that this is a type of approach rather than a law. Sometimes, that legacy system or class is replaced without fully understanding it, because it's cheaper to reimplement it's interface than fix it.
Implicitly assumes we know what that interface is (and this assumes that that "interface" really does include all the relevant interactions - this is, the literal interface between systems).
If we really did know this true interface, the implementation is absolutely irrelevant.
In practice, all abstractions are leaky, and it's routinely simpler to look at the source to work out what it does. This covers the gamut of interactions, from minor undocumented API details, to complex semamtocs of corner cases, to time/space/resource usage patterns.