Don’t point out something wrong immediately
blog.the-pans.com
blog.the-pans.com
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 only way to get it done for the deadline; we never got the time to fix it
* external system constraints (like legacy applications, legal/certification requirements, ...)
* particular domain constraints that you might not be familiar with, and that only make sense if you know the details
* important senior engineer X designed this and no one had the guts to call it out as flawed
* the company paid a lot of money for product Y, so we just had to use it
* a manager read a blog post on how technique Z is awesome, so he made us do it this way
* political infighting between parts of an organisation (redundant work, refusal to work together, deliberate sabotage)
* ...
But you will usually not hear these reasons right away. And being critical can easily put others in a defensive stance and make it very hard to get that information at all.
So my best tip is: if you spot something "wrong", don't react immediately and don't interrupt. Let the other party finish. Make a note. Gather more information. Ask why it was done this way, who is responsible, if it has been effective or not, and whatever else could be relevant.
You can still be as critical as required later.
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. If your self image depends on blaming fate or having a scapegoat elsewhere in the organization then you really should take a hard look at yourself, your team, and your motivations.
Sometimes, the only way for things to get better is if you can get consensus from the developers that tasks that look like X really should take 3N units of time even though historically we've been quoting 2N units. On some teams you can't get that consensus, and you're going to have to be okay with that or move on. But the power of No is there you just have to use it. If you don't at least try, then shame on you.
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.
Most of them do that quite regardless of whether they have any integrity or not.
...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.
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.
The solution is almost always to put pressure on the industry and the system’s administrators and designers to improve it (as govt recently has been trying to do after SolarWinds fiasco)
This phenomenon is EVERYWHERE and once you read this you can’t unsee it — check this out:
If you don't have enough time frequently, it's time to reflect.
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 recently sent someone a (let's say) figma prototype but I decided to cobble it out of a production language I never used. (So, not actually figma.) It sort of worked but wasn't close to being real. I did it while I was waiting for my laundry to finish. I'm trying to think of how I would apply your standard to the figma wireframe.
If I focus my efforts on doing what you find acceptable, how do you think I should invest my next 200 hours? I have these alternatives:
- I'd like to finish reading the book Pro Git as git is the sine qua non most important tool of the trade and mastery would be very nice. I'm on github and can do basic operations but I think I would benefit from being a master.
- Improve my code demonstration's efficiency. I have a code demonstration up on my github at https://github.com/robss2020/dictionarysequences - I can improve it by approx. 75% with a few lines of code. This will just take a few debugging sessions.
- Redo the above in C. This would be so much fun for me because instead of fake pointers based on Python strings I can use real genuine C pointers to actual memory. And I can implement a hash lookup table that is so much fun. The result would scream with speed it will be 40x to 100x faster than my Python demonstration and I know enough C and C++ to do it perfectly. It's just a straightforward translation of the efficient python code, except C doesn't have a built in hash lookup like Python does so I get to implement one myself. This will let me add a demonstration of one of the most valuable skills, I can potentially use it in high-frequency trading applications (the skill of being able to wrangle efficient data structures in C). It is a massive source of value for me to demonstrate my proficiency in C.
- launch a statistical project. I have a statistics side project I could put work into launching. Right now I have no useable side project online, just my potfolio web site ( https://taonexus.com )
- Finish a technical writing article I started. This would be my portfolio project for technical writing.
My plan was just to do all of the above. First, finish reading pro git but not properly just enough to make sure I can look up what I need to, second improve my code sample but also not properly, just add some breakpoints and putz around to see if I can add the code I'm thinking of, if it works push to my github otherwise just discard it, third, do the translation to C but just cobble together existing libraries for the hash, don't reimplement it myself, fourth launch the statistical project based on cobbled together code, reduce the scope until it's trivial, and as for the technical writing project, use screenshots I've been saving and my final results or impressions just based on the ultimate outcome. Don't make it into a 10,000 word article, don't do further market research etc.
For each of these things, I could put in more time.
How do you think I should budget my time? My ultimate goal is that I am trying to change to a new job as a technical product manager (my resume is on the bottom of my site). Given my goals, how should I budget my time to become a better candidate?
I can't do all my plans your way but I'd be curious to know your feedback about how and where to invest my time.
"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.
General advice goes thus far. noone knows what you situation is, to go any deeper.
as of raw-chicken-ish: what i said is: if you imagine already eating it, what good-taste means? Then pursue that
(which translated back from chickenish, might be: which company? which field? which environment? which kind of job? which kind of team? etc)
good luck, and do not despair
1. Be a manager. You are not there to be their friend. You are there because they are horrible and their leadership needs you to clean up the trash. If you are not there as some form of management with a title and ownership you will quickly become their bitch, which leads to my second learning.
2. Don't get sidelined. As an outsider operating under contract the problem people want you gone but cannot remove you. Their best weapon is to sideline you. If they cannot own you they will ignore you. They will rearrange their meeting schedules and ensure you are not invited. They will create and release prototypes and delivery plans without your involvement. They will write reports and opinions to their management with all kinds of complaints and fictions and you have nothing because you are out of the game.
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.
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.
Sturgeon's Law has entered the chat.
90% of everything is crap.
Once is happenstance. Twice is a coincidence. Three times is a conspiracy. So I already know to ignore it.
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.
That's really about the only time you can actually be sure that the prior coder deserves to be trash talked.
Junior engineer logic
The problem is that people doing the " wrong" thing (with varying degrees of wrong, which I did too and still do) will think they are right, they will usually do a presentation of their solution to people that are less knowledgeable than they are to win the "this was the only practical way given the time we had and also it works" (kinda, if we don't count when it fails) argument, lure them in their teams, keep pushing out half baked solutions that they will then rewrite "to improve them" for karma points, wasting everybody's time and company money.
It works because there are always processes that are worse than bad software.
So bad software usually is not the worse thing you can find in a company and can always blame some other department for being horribly inefficient, everybody wins, salaries are paid every month and 2 years later nobody knows what "the thing" does and why.
But it's an excuse not not do better when it's possible.
a task that takes half an hour can't take 12 days and 6 meetings "so we can talk about it" they say, truth is they are simply pushing their view.
I get people are different and have different incentives, but we don't let people like me go into space just because we shouldn't point out a problem when we see it
Software development is about being as thorough as possible while also being flexible.
I always wonder why we keep asking people who see the problem to stay quiet while people causing them are encouraged to keep making them, so they can learn.
What if people doing the "wrong" thing start listening and do what they are told and if it doesn't work they can blame who said them they were wrong?
Saying no sometimes makes you the lonliest person in the office, but somebody gotta do it or nothing will ever change.
The "right way" somebody envisions to be THE right way can be worse than something even better.
So instead of saying "Hey you are definitely doing it wrong" you can say "I can see an alternative way of doing this which might be better in some cases, for some purposes, for some users".
agree, that's why the word "wrong" in in quotes in my post.
I usually say "I see a potential problem here" and explain why I think it could be.
I think the article has a good point, it's not good for team dynamics if we are often and overly critical of other people's accomplishments. It is their baby after all.
1) Don't lose track of the outcome, "being critical can easily put others in a defensive stance and make it hard to get that information", this also applies to the phase after you've gathered all the necessary information and need to fix it, if you've been too fast and loose with the blame cannon, good luck getting anyone's help afterwards fixing it or earning any respect for future work.
2) From the OP "This is when we should take a pause before pointing out something is wrong", this might sound weird bringing this up, but Mindfulness techniques as often also employed in CBT, which encourage you to observe the immediate thoughts, e.g. in this case fish out the blame cannon and let rip, but instead acknowledge them and don't act on them are great for developing this "pause".
3) From a Systems Thinking pov, complex adaptive systems often evolve in many small steps, rather than are designed so I'd extend your "But more often than not there is a good reason" to more often and not there may be many good reasons all bubbling away in the melting pot of despair. As an example my last company tried to implement the Spotify Squad model and it was a disaster, but it wasn't just one decision by one person that sunk it, it was a whole combination of decisions taken over time and feeding off each other, many taken by people who didn't even work there any more.
I think there a counter point that if someone else had not deferred or neglected pointing out something was wrong there would be less wrongs to discover.
It’s certainly socially easier and nicer to avoid pointing out flaws but it doesn’t always result in better technical solutions.
But yeah, just calling it out straight away sometimes shuts down communication, people become combative, and that's not good if you want to fix something eventually.
I'm going with "Heroically empathetic"
The entire point of a company is to make money, with the people/resources they have. More often then not what they want is not the best available to them.
Most people are horrible, managing a bunch of highly egotistic but talent people is hard.
I had a conversation with my manager about this just a couple weeks ago. One of our junior developers was having trouble getting his local dev environment working with a self-signed certificate, pretty obvious problem, easy fix, and my gut wanted to just remote control his desktop and fix it.
My manager however was like "Let him figure it out on his own, it'll be good for him. If he asks questions, answer them, but let him work his way through it" - I think that's some pretty sagely advice.
It took a realization myself that my 20 year accumulated knowledge, insights, skills, mental models is not something most college grads can grasp (there are very, very few exceptions). And telling them verbally doesn’t help either.
Ex: due to that experience, I can pick up any language & ecosystem and be productive in 3 days max (from js to c++ to haskell). I can’t expect that from a bootcamper or new grad.
Now the twist in this story, is that through this interaction, I reflected on a past job and realized that I had been that guy once! That sure was a moment of personal cringe. It's cemented into my brain how important it is to ask questions to fully understand the context decisions are made in before chiming in to say how wrong they are.
One time my old team hired a hotshot in the gaming industry that came in trying to change everything in the first 2 weeks. It rubbed everyone the wrong way. He had a habit of interrupting one of the women on our team way more often than any of the men on the team. We ended up letting him go. If he would have just shut up and listened, he’d probably end up being a fine addition to the team (assuming he wasn’t actually sexist).
What always sticks with me is that in retrospect, most of the changes he was advocating for were good ideas…
In my view, commonality between I and others I've known with that behavior was that we came from a long multi-year project. After experiencing daily maintenance of big projects for a couple of years, you tend to have a strong opinion of things you don't want to see again when moving for greener pastures.
It just seems to disappear with time. Maybe because at some point people accept that telling others what to avoid is pointless, people tend to learn only from their own mistakes.
- Do not criticize without understanding the root issue
- BUT, ask questions about the issues you encounter AND, document/explain the quirks/history as you go
IMHO the important thing is to learn that:
1. you don't know the whole context, ask around before criticizing
2. keep your eye open for quirks, don't let a general "laissez faire" attitude take over you
update:format
reforms should not be made until the reasoning behind the existing state of affairs is understoodOf course we need to understand the system before changing it.
But we shouldn't browbeat those wanting to improve the stuff we left no guidance about.
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.
Sometimes the easiest way for a company to relearn about a problem space is to rewrite it though, so it is not necessarily a bad thing to do. It can also be that the market has shifted and some of the complexity in the old system was no longer necessary, so the new system ends up easier.
In any case, spending time understanding the existing system (including developers that point out corner cases and nonobvious cases) make the end result so much easier than adjusting a solution to handle a complication angle that wasn't part of the original plan.
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.
Example
I saw empathy in the tags. How does empathy apply to this post?
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.
There are, of course, better and worse ways to raise concerns. "Why did you do it this way? It seems to me that . . . " leaves the conversation open to the possibility that there is good reason for something you don't understand. And if there are major problems, it might be better to privately approach someone (and/or their supervisor?) rather than torching them in public.
But if there is a problem, you aren't doing anyone any favors by keeping quiet.
I guess what I'm saying is that "hurt feelings" is most often a result of how feedback is provided, not what feedback or even how much feedback.
No.
Whether shit gets done is the primary concern, when the primary reason we get together, is to get shit done.
But often it's not. Often the people who like dishing it out are the most easily affronted if you tell them they are in the wrong.
Don't get me wrong: I actually agree with you. It's just an unfortunate reality that working with people means dealing with people and feelings are a part of that.
It's hard to establish mutually respectful relationships where both parties are equally able to be straight shooters and actually get things done. When it happens, it's wonderful.
But in most workplaces, that's just not reality. So it's very often the case that taking the time to try to not hurt feelings in the first place is more efficient than dealing with the damn idiotic fallout.
Didn't expect software development to need so much people management.
But I disagree with you more fundamentally. Getting shit done together is a way to enjoy spending time, but in the end, the enjoyment is more important than the result. A job where you are successful but miserable is not worth it. So a job where you are successful by making others miserable isn't either, unless you are somehow special.
That doesn't mean bend backwards trying to avoid any hurt feelings. It does mean putting in some effort to not be hurtful when avoidable.
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.
What makes you think it wouldn't [be | have been] easier for them too, if they'd [learn | have learned] to be less of an arsehole?
Sorry, but everybody should be doing this in every job, and in all walks of life, all the time (however, like anything, there are limits).
Concern for other's feelings isn't weakness, nor should it be a second thought - it's a common courtesy.
Maybe it is a cultural thing ? I worked once in Germany and thought at first that the error pointing was brutal. But you get used to it and learn not to involve your self esteem. And retrospectively I found it to be a fair and effective work environment.
So when I see her doing a few things that I wouldn’t have done, I could have just reacted and pointed it out and told her how it should be done. For sure I wanted to, I’m an engineer!
Or I can have a bit of trust that, given a minute and a few more repetitions, she’ll get it. Which she did. And now she’s learned something, and now I’m not “that guy”, and now we have a better relationship, and so on.
I appreciate that this might not be the sort of thing you had in mind. If there’s an error in code that isn’t going away if someone doesn’t say something then, sure, say something.
The question is why pointing out something wrong would have automatically damaged your relationship with her ?
Everyone can agree that making mistake is natural. Can't people learn not to get upset when being told they made one ?
One way is by exposure in an environment where the feedback is factual and without drama.
The thing to avoid here is being the know-it-all who tells everyone how things should be done when, given just a second, those people would figure it out anyway. Nobody likes that guy.
I’ve always found accepting that ego thing to be very difficult as I’m quite happy for people to scrap my ideas if they’re bad, but a lot of people aren’t wired like I am and I don’t hold that against them. Could be a genetic thing. I have other faults that they don’t, so tolerance is needed in both directions. Humans are buggy.
These bug issues or bad software practices are results of a culture, and work cultures can be fixed. Hence OPs example of experiencing a very different culture in another country, and presumably German's aren't genetically built different to respond better to software error reports.
And the best time to fix it is right now because it'll be more expensive in a year.
And above all, they don't phrase things for maximal emotional impact. They dont exaggerate. They dont go out of way to make criticism sound funny. Which is unlike majority of "nerdy" or "geeky" criticism found online in tech circles.
For starters, saying "this is wrong" is the least helpful way to present a problem. Of course it can work, but it's better to say what is your specific concern, why do you think it's important (and possible consequences) and a possible solution. That usually leads to better and more efficient discussions from the start.
Then there's the issue of you being wrong about being wrong. The good thing about starting the discussion in the way I said is that it helps you to actually form your thoughts and a lot of times that process leads you to the important questions, to the holes in your understanding and sometimes even the solutions.
The article was short, but I don't think it disagrees with you. It's more about how you say things. Try to lean into your curiosity and ask questions, instead of just straight up saying "that is wrong". Because asking curious questions makes the other person want to engage with you, while pointing out mistakes makes them defensive and likely to distrust you.
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.
Something I've noticed is that acquaintances will be nice to you universally, but actual friends know when to broach subjects that may not be considered "pleasant" or "nice". Don't give your friends "acquaintance-level" code reviews.
- 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 this change likely to remain isolated to this part of the codebase, or will the pattern infect or be copied to other locations widely?
It's super challenging -- and also intellectually rewarding when you can master it and gather team consensus and alignment.
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.
Technical debt isn't always avoidable, but I sure know the difference from when teams are heavily invested in pair programming vs not.
Good pair programming is hard to ingrain in a culture though.
In fact you reminded me of the technique right now to check the responses and make sure nobody else had already said this!
This was my excuse to not be thorough when giving feedback in code review, when I was last in a position to do so, while on the Windows accessibility team at Microsoft. I told myself I was on a mission to make Windows more accessible, and there was no time to delay new features or fixes over inconsequential things like coding style or even code organization, as long as it worked.
Edit: At least I didn't use that excuse when responding to coworkers' reviews of my PRs.
The motivation is completely different - one is parasitic and narcissistic, one is constructive - but they can look and feel very similar, especially to those on the receiving end.
I strongly suspect orgs tend towards a status culture unless carefully steered towards quality. I haven't worked out what the full secret is, but it may have something to do with strongly valuing and respecting skills and input outside of reviews, so specific criticisms aren't experienced as part of a consistent pattern of devaluation.
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 says something that sounds immediately wrong, try to let them finish what they're saying and try to figure out why it doesn't immediately seem wrong in their own eyes - it might be that what they're saying is only wrong in the context of a larger system, and the colleague simply has a different understanding of the larger system from you, which causes them to not immediately think that it's wrong. Sometimes the "actually wrong" thing might be somewhere else in the system, and if your colleague hadn't been allowed to finish their thought, no one would have realized where the "actually wrong" thing is!
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 think the cert for https://cieloconnects.com/ is expired.
And to address the debate below, I do in fact appreciate risk-averse and focused engineers. The 'don't say no' thing I think has merit when interfacing with business. But within the team, as long as you're in your own lane I appreciate it very, very much when my coworkers help me find flaws.
Most of this comes up in planning anyway, when we're spit-balling best approaches. If the problem is difficult enough, someone will get a research spike to discover best practices and form a set of initial proposals and alternatives.
ETA: and yes this is my public profile. I don't mind. I'm proud of my work at CIELO.
To point out the issue but maybe not say exactly what was wrong?
There's a huge difference between maintaining the social etiquette of allowing your conversationalist to explain themselves fully, and waiting a little while before announcing a problem. Announcing right away in a respectful manner also let's you get a correction right away.
This is a big reason why batch-based code review systems are great. I can quickly work through a pull request and point out every little thing that I notice because it's all a draft. Then I go back through and review my review. Sometimes things that I thought were problems are just things I didn't understand yet. Sometimes things I pointed out initially aren't even worth bringing up. And for the remaining points I can check that my feedback has the right tone and will come across well.
I really miss this cycle when I need to use something like google docs as a feedback mechanism, where all the comments I leave are immediately mailed out.
Slack is another system that encourages hasty responses. My critical feedback is better when I'm writing up an email and not participating in a realtime conversation.
https://randsinrepose.com/archives/the-blue-tape-list/
> It’s a surprise when a month passes, and you review your blue tape list and discover how items that seemed urgent at the time now seem entirely irrelevant.
[0] for those of you who don't know, MtG is a card game for two or more players who have a 'library' of cards they draw from, and play. It has a very simple premise - win the game by reducing your opponent's life total to 20, removing all the cards from their library, or playing a card that says that you win the game - and an insane amount of complexity; for example, one of the standard variants is provably Turing complete using the base rule set.
[1] One of the reasons for the longevity of MtG (been going strong since 1993) is that there are many variants of the standard rules that allow for a wide variety of play. Standard uses only the most recently released card lists, while Vintage lets you play with (almost) any card ever printed. cEDH stands for competitive Elder Dragon Highlander, which is a format where you have a 100 card library that has no repeating cards ("there can only be one!"), and they all have to share colors with a chosen 'commander'.
[2] MtG mechanically uses cards called 'lands' to produce a resource called 'manna'. Manna is used to pay for spells, which when resolved have some effect on the game state. Spells have color - 3 blue, for example - which can only be payed for by appropriately colored manna. There are 5 colors of manna, and each color is associated with different types of spells. Red is fast and aggressive, green is ponderous but mighty, etc.
Don't work with people who cant handle being wrong and fixing it.
> For engineers, the cycle is "see a problem" -> "spot flaws" -> "feel good".
Maybe I'm missing some aspect of the text? AFAIK, "feel sad" and "eat chocolate" are different things (with a cause and effect relationship) and "see a problem" and "spot flaws" are the same thing expressed in different words, so what's the cycle here?
Having someone point out flaws, while sometimes an important ingredient in actually fixing flaws, can just as or more often be about as useful in really solving something as eating chocolate can be in addressing why someone is feeling sad.
Aka, not much.
OK, that seems likely, but why use a word "spot" that does not mean "to point out" ?
The distinction is clear here: https://dictionary.cambridge.org/dictionary/english/spot
Spot: "to see or notice someone or something, usually because you are looking hard" e.g.
"If you _spot_ any mistakes in the article just _mark_ them with a pencil."
You could be correct, but you are assuming something that's not in the text. I don't think this is "overthinking": to spot (to perceive, notice, become aware of) _does not mean_ to "point out" (to show, to tell people)
I checked the dictionary: https://dictionary.cambridge.org/dictionary/english/spot
"Spot: to see or notice someone or something, usually because you are looking hard." e.g.
"If you _spot_ any mistakes in the article just _mark_ them with a pencil."
If we're talking about "things that the word doesn't mean" then there's a lot of options.
It's strange that finding flaws is framed negatively. This ability is a positive trait in software development.
* Say yes first. Acknowledge everything and say what you agree with.
* Use the phrase "tell me more." Use this to get context in a nonconfrontational way (as opposed to "why" which can get people in defensive mode).
* Avoid using "but". People don't like to hear it and it makes them forget the past before it. Everytime you want to use but, see if you can use "and" or "at the same time", or nothing, and almost always the result is better.
I have experienced lower levels of trust and worsen proficiency in giving and receiving feedback described in this article since the whole WFH thing started, especially as teams at my employer change and we bring on new team members. People are a lot more sensitive, everyone collaborates less and we are accepting a lot of bad code into our projects than ever before. We had about 1/3 of a crucial team leave recently. At their exit interviews they all described how one of the reasons they left is because the code base has turned into a pile of junk and no one wants to work on it.
I recently agreed to join this team to help turn it around because I have a reputation for ensuring good engineering practices and giving feedback is a strength of mine. But boy, this environment is challenging with developers all working from home. I'm curious if this resonates with anyone else, specifically if others have similar experiences with wfh.
But our codebase has become progressively worse because nobody tells the truth about their experience. There are teams making bad choices which throw other teams off the cliff. Sometimes product managers come up with elaborate projects without due diligence only to waste 6 months of engineering time.
Because of such activities, engineers lost faith in their team/org. They just coast or switch teams/companies or straight up lie to management.
There is zero incentive for anyone to improve anything because pointing something out is bad for "optics".
“Wrong” is a subjective outlook and usually is not a helpful conclusion. Especially if the system is already active.
Better to discuss in detail the benefits of an alternative.
Be like my previous intern.
I have a very problematic supplier of business critical bespoke software that we can't move away from, and the devs there have a nasty habit of pointing out flaws in our processes, talking down our other suppliers and making snarky comments, when those flaws are usually either workarounds to deal with the shit system they have developed or persist because while we would like to do things in a more modern way we can't as we can't rely on them to even implement an address validator that works. Frankly the only reason they're still alive and I have a job is Covid and remote working.
Rather than jump to calling out something as wrong, it can be helpful for mutual understanding to first ask questions framed in the terms of the apparent misconception, even if it sounds wrong to your mind or risks making you look stupid. Sometimes you'll find that there was actually no mistake, and other times you may make a positive contribution in a way that's more collaborative than adversarial.
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.
Many times the original person might have made some small assumption and then that filters down and causes the current situation to be "wrong". Or maybe I am making the wrong assumption and I simply need to understand what the problem is, at its simplest, that we are all working together to find a solution for.
Most systems are built for nothing but subsequent failure (even if it's 300 years into the future). Think about that.
It's also a tactical thing to do in an adverse one. Understanding the balance of those two will help you gamify your own value more.
Because some people have the habit of dominating discussions or steering discussion away that paints them in a negative light.
Even without the said policy, it doesn’t benefit the business, because if it’s a problem employee, you’re pointlessly keeping them on a payroll, and it doesn’t benefit the employee, because if you hit them with everything at once, little of it will resonate with them.
Not all grown up people are adults.
You need to give people enough rope to hang themselves with so you have a tangible reference point in which to start an opposing argument. Broken down into an expenditure of effort consideration it’s cheaper to say I told you so then sit in endless meetings convincing someone they’re about to do something stupid.