This 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 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.
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.
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.
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.
I agree that striving for (let alone expecting) perfection is fraught. But a business's goals in commissioning software development are related to but distinct from a developer's goals in delivering it. If you write software for a living in the 21st century, and you don't find a way to incorporate constant learning and improvement, and strive to refine and master your craft, then you're definitely doing it 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 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.
I will say that as I've gotten older that I've noticed a bigger link between code others may think I'm obsessing over and job satisfaction. If I'm insisting on 'perfection' in a bit of code, coping mechanisms are definitely part of the mix. I think only twice has it come to the point of me saying "If you want it to work that way, you're going to need to find someone else to work on this," but I have definitely felt it more often than that. It feels foolish to say it but sometimes honesty is the most efficient form of communication.
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.
Believing that crypto is the wild west and any project can rugpull you is learned helplenessness. Being scammed out of your private keys is learned helplessness. The industry creates problems upstream (lack of factories and standards, wallets lets you export keys, etc) and people are internalizing their responsibility (and inability) to clean up the problems downstream.
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:
I have maybe 10 or 15 of those tasks at any given time that _should_ be fixed, but there's not really any time to do them. There's definitely an element of YAGNI/If it ain't broke, but in many cases the right thing to do is just leave it alone, even if it's not best practice.
I've turned really against this, and 'busy', annoys me when people say it now - we all have exactly the same amount of time; how we allocate it and to what is up to us.
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 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.
> 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.
Thanks for your feedback and advice, I appreciate that you took the time to write it, svilen_dobrev.
"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.
When I was a strategy consultant there were only two important lessons to learn:
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 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.
Everyone has blind spots. What makes them 'stupid' is when you're the one who ends up suffering (or someone you empathize with does). If you sniff a pattern you should probably keep looking
Once is happenstance. Twice is a coincidence. Three times is a conspiracy.
One of the nicest things anyone's ever said to me is "Feel free to blame all the problems on me once I leave." Whenever I leave a team now, I make sure to give everyone explicit permission to do so.
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.
> if you spot something "wrong", don't react immediately and don't interrupt. Let the other party finish. Make a note. Gather more information
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.
I think it is most often wrong to use the word 'wrong'. That implies there is the right way and the wrong way. But in fact there are only better ways and worse ways, to do things.
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".
We just have a guy in the team (he's smart, but very abrasive) who instead of using the word "wrong" uses "antipattern" for everything. And usually those are mostly his unfounded opinions on something but taken as a gospel as it sounds authoritative.
It is just one of those words, like never say never.
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.
This is very good advice if the goal is to retrospectively find stuff that is wrong and how it came about.
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.
calling many of those a "good reason" is.. I don't have a word. Something brittish probably.
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 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?
This happens so often, I am surprised that anyone gets surprised by this at all.
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.
This has been the hardest thing for me as I become more and more … old. I want to be like "this is wrong" "do it this way" etc. For a while there before I realized I was burning bridges, I was… for lack of better phrasing actively an asshole. There's value in letting the juniors flounder a bit.
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.
Yes, please don't be that guy. I was a lead at the last startup I was at, and we hired a guy who loved to point out everything we were doing "wrong". Literally weeks into the job and he's already writing up huge docs about everything we need to improve, with having almost no context for why we made certain decisions. The majority of things he assumed to know better on we also knew better about, but there simply wasn't enough time and man power to do things in the "right" way. He also pointed out some things that we were unaware of, but he had already tarnished his reputation by being so abrasive about the critique while putting so little time into understanding.
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.
There needs to be between 3 months to 1yr of onboarding before going in & trying to change everything. I always remind myself of this when starting new roles.
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…
I've been that engineer at a particular time in my career. And saw others be that person as well, since.
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.
The hardest part about this for me is that I often feel like that is the only time I will get to chime in. If I give myself time to think about it - whether it is important enough to discuss, and if so how to do so productively - the conversation will have moved on. The other party will take lack of objection as agreement, and I'll either forget about it until the concern becomes an actual problem (or nothing bad happens), or I'll constantly be that guy dragging up issues that were already "settled".
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.
What happens then though, is that the replacement take a lot longer than expected, because it turns out that the complexity in the old system had more motivation than expected and had a lot more problems it solved than was obvious. Fixing these issues then make the new system into almost as big of a problem as the old one, with the only difference in that now you at least have some people that understands it. For a while until enough people have left to again forget the workings of the system.
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.
I'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?
Yes, this a very good approach - it gives people the opportunity to double check and spot it themselves, and it gives you an out if you're wrong. Bit of the old socratic dialogue.
One has to be very careful with socratic techniques, they can quickly become trite, patronizing and segue nicely into splaining. They are extremely useful and help give space to the state of things, but if the people you are interacting with ever felt like they are being led down a garden path, it can feel like a big setup to getting owned. This advise comes from working on teams where the socratic method was used as a setup for being made a fool.
I'd argue that "you are wrong" can be hurtful, rather than is. It's all about delivery, the culture/environment you're in, and how receptive a person is to negative feedback.
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.
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.
This. Let's please not make engineering another field where our first concern is whose feelings are hurt.
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.
Whether someone's feelings are hurt should be a primary concern. That doesn't mean you cannot correct people making errors, you definitely should. But if you're hurting people's feelings regularly you are bad at providing feedback. I notice the only "softening" of the message you suggest is to allow pushback if you happen to be wrong. It seems you are more likely to cause persistent fixes by treating people as people and correcting them in a way that doesn't hurt their feelings.
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.
As long as that's a two street and you can take it as well as you dish it out.
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.
One of the early disappointments I had with software engineering was that I thought that I would be mostly working to formulate elegant solutions and implement them.
Didn't expect software development to need so much people management.
I wanna argue that not hurting people's feelings is better for getting shit done. Because you cannot do things on your own.
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.
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.
Fair enough. I think I may have misread the tone of the post I'm responding to because it happened to sound similar to a line I had just heard in some media - which was used by the character to justify yelling at people.
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.
> 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?
If you're talking to workers from another company, they're going to be bound by what I can only call "loyalty" to not tell you why it happened (what are they going to say, "we think our boss is dumb and he made us do this?") and instead will make up reasons, doubling down on it and starting an argument where one side has a duty to be disingenuous. It's a mess, don't start it.
Point it out immediately. And work to create a culture that understands we all share the same goal of building more robust software. If you sense feelings are hurt, explain the common goal and point out wins the other person has had in the past. But I’d recommend against preemptive caution because it will add significantly to your workload and to friction during collaboration. It may also create an atmosphere of over abundant caution - which is kind of awful if you’ve ever experienced it.
I can't agree with that. If there is something wrong, it must be dealt with as soon as possible. We engineers must learn to be professional and not let our ego get in the way.
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.
It depends on the context. Just yesterday I was doing a data centre audit with a colleague, who is many years my junior, and I am her manager, and she has hardly been in a data centre. She’s also amazing by the way.
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.
I would have had no problem pointing the wrong thing out if she hadn't 'got it' herself, but I knew she would.
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.
Think you have to deal with the world as it is, rather than as it should be, if you want to make progress.
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.
If you want to make progress you change the world as it is to the way it should be and throw out notions like thinking people are 'wired' in certain ways to rationalize the status quo.
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.
German might be brutal in the way they say things, but from my experience, it's generally to hide their mistakes and not knowing much, so nobody would dare to confront an over-confident bullshitter, after all, they are damn convincing.
Germans are careful and deliberate in a way they phrase criticism. They don't just go full in nor randomly criticize everything.
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.
I think the article could go a little bit more in depth, but overall I agree with the sentiment.
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.
"If there is something wrong, it must be dealt with as soon as possible."
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.
Eh, this is so contextual though. In the context of a code review, as in the article: no, please point out an issue if you see it, don't hold back. But raise it once, be willing to let it go, and respect that your colleagues don't have to act on your advice. The golden rule will get you far.
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 definitely have a list of things I've let go just to be nice that have caused production outages, consistent poor performance, time-consuming technical debt, etc. It's great to have a good relationship with your team, but at the end of the day, the things that you "let go" can become reasons not to buy your product or why new engineers won't be productive on the codebase. It's very easy to be the person that never says "no" to something, but at the same time, it's also easy to be the reviewer that doesn't advance the reviewee's career. A reviewer should ask themselves; "by not commenting on this, am I making the reviewee a better programmer?"
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.
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)
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.
It is tough to balance between sweating the details and not bikeshedding (sweating the details at the expense of the big important architectural decisions)
This is why I am so grateful for GitHub reviews; Being able to group comments to fire off all at once has saved me from this multiple times as I continue reading, realise something, and remove a previous comment.
In fact you reminded me of the technique right now to check the responses and make sure nobody else had already said this!
On the other hand, someone coming after you might read the code in the same order and have the same wtf moment. They may even never find that later piece you saw in the review. So at the least it should still be a signal to the Author that it appears strange.
I also really like this feature of GitHub reviews and when deleting a comment as I continue reading I try to question whether to add a code comment so the next person doesn't get tripped up because they don't have the full context in their head.
> Or maybe there are bigger fish to fry and it’s not worth quibbling over small things.
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.
This is a tooling problem. Github reviews vs. Bitbucket reviews will show this. In Github you can write your comments and send them all at once. Until you submit the review, you can just edit your comments and undo them or whatever.
Right, I think the title should be something closer to "Don't point out something wrong to make yourself feel valuable/smart/etc". Obviously in lots of contexts you do need point it out immediately (the server is down, your neighbor's house is on fire) but when it's just giving feedback, it's good to be helpful (even then there are times when tough love is required, I don't feel bad about pointing out when a mistake would have terrible consequences if it shipped).
I think there are status plays, and there are quality plays. Which is which depends on the culture.
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.
There's so much nuance in code review communication. The way I'd interpret this article's advice in the context of reviews would be: don't begin adding comments about minor annoyances and details that you've noticed until after you've read through most/all of the changeset and raised any more important structural concerns first.
When "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 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!
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.
We 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.
Ah look at that! Nice catch. Yes, I can see that something is done to fix that, though I'm not on that team (I'm backend).
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.
take your own advice. i noticed a cert was invalid or broken and mentioned it to a person who might care or know how to deal with it appropriately. In the meantime the site is less secure than it could presumably be. i'm not a paid consultant for the site so i didn't bother digging in and finding out which policy violation triggered a browser warning, but since you did, you can share it here or you can continue to add zero-value comments.
How did you even find that site in the first place? It's not in their profile, it's not in the top duckduckgo results for "CIELO Enterprise Solutions". How long were you digging around to find something, anything, to try and pwn them about their high engineering standards comment?
Perhaps there is a language or nuance barrier. I "thanked" the parent commenter for sharing their view, did an "internet search" for their publicly listed company to see what kind of jobs they might have available, and then was warned about certs visiting their site... Now I'm having a terrible conversation with you for some reason, but I hope this helps dispel your confusion. Please feel free not to reply at all with anything.
Completely disagree. I agree that the _delivery_ is important, but the interval between when discovering a problem and announcing it should be minimal.
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.
Another problem with reflexively pointing out something wrong is that it's easy to be mistaken when you're hasty. Then you have the walk back the criticism and admit you were wrong. (Or double down and quibble about what exactly you meant, if you're that kind of asshole. Dealing with these folks is very tiresome.)
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.
This "blue tape walkthrough" approach is one concrete way of introducing the delay between stimulus (hearing/seeing something obviously wrong) and response ("correcting" them on it):
> 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.
I, like a lot of other nerds, play Magic the Gathering[0], specifically cEDH[1]. This process really speaks to my deck building process - after coming up with my archetype, color pie [2], and win conditions, I grab everything that I think could be applicable, and throw it in a pile. Then, on my first pass, I sort into yes, no, and maybe. Invariably, I end up throwing out all of the cards in the maybe pile, but the process of taking it aside, considering it, thinking "this could work", then coming back with fresh eyes struck me as similar to this process you've described.
[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.
It's not about people not handling being wrong, but about introspecting on how we deliver feedback. If people cannot take feedback or accept flaws in their work, that certainly is a problem. But this article is just asking us to think about the human relationships in our work, and to hold back on knee-jerk feedback.
> 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?
I think the second example is probably meant more as ‘point out flaws’.
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.
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
> You are overthinking it. “spot flaw” here would be “point out flaw”.
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)
The author Didn’t say that pointing out flaws is bad. But that we shouldn’t rush to immediately point out a flaw when we don’t have the full context behind the issue. This is more to be applied for improving interpersonal skills, but I think if you are in a small team where you are plugged into what’s going, pointing out flaws doesn’t have to be overthought.
* 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.
There certainly is a balance to giving feedback like this. It very much depends on team dynamic and the level of trust between team members.
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.
I have something similar. We have a "blameless" culture which is nice. Genuinely appreciate it because people do make mistakes.
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".
I recall one of my interns telling me they would never sacrifice quality of code for anything else. When they left I asked them if they still felt the same. They said they had a new understanding for why that may not always be the case.
One thing you also have to be very careful of is pointing out a problem or inefficiency that exists only because of work you or your company has done.
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.
A 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.
When you're burying something, the dirt gets shoveled on after it's put in the hole, so what you're describing might actually still be described as "burying" the lede.
Instead of pointing out why I think something is wrong I just starting asking questions dancing around the subject. A lot of times it comes down to just getting to "What problem are we trying to solve here?"
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.
Just be careful, because, as a manager, you can easily lose your best people, if they constantly have to review bad code from "productive" junior developers, need to manage how/when to deliver the review and then they are expected to work on the same code-base. This needs to be balanced.
I know that engineers aren’t the most socially adept bunch, but it’s still weird how someone can go this long before having to realize that personal feedback needs to be delivered appropriately because people have emotions and aren’t just programs to be dissected like in a line by line code review.
While I recognise that engineers do this a lot, other people certainly do it too. Whenever I present any GUI work to other people (future users) they rarely consider the big picture, but just nitpick some tiny things in a stream-of-consciousness way because it makes them feel like they contributed to the process somehow. Building a UI that pleases most people is challenging and people do not appreciate the hard work (design and engineering) that goes into it, I find, preferring to turn user feedback sessions into nitpicking sessions every time. Usually they are plain wrong too, for the same reasons outlined in this article (e.g. there is a requirement they did not consider).
I don't remember if it's a quote from Kahneman or Tversky, but I always liked the idea of asking "Hmm. That's not right, but what is it true of?" instead. [IIRC, it's mentioned in Thinking, Fast and Slow].
I was just about to do this, but then thought to myself: wait, see if they realize the error and fix it and then follow up. And then opened HN and saw this post! It was a nice confirming synchronicity.
Never 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!
This is a fantastic post, thank you. I tend to do this in my everyday life and realised it recently. I hope I can slowly change and get rid of this trait.
I generally wait for the their thought to be completed, to see where they are going with it. I do this on the assumption that I could be wrong and they might know more than me.
But this benefits absolutely nobody. Not even the manager doing that. I know that in my workplace a manager would get chewed out for that, as this practice is explicitly banned by policy. Any issues should be raised the moment they are discovered.
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.
I haven’t read the article to be honest because I’m lazy and slightly drunk but I have to agree with the title.
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.
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.