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.
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.
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.
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.
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.
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.
It is tough to balance between sweating the details and not bikeshedding (sweating the details at the expense of the big important architectural decisions)
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)
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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 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.
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.
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’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 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.
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.
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.
> 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
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.
> 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 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".
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.
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 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.
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.
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.
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.
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.
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).
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.
179 comments
[ 2.8 ms ] story [ 133 ms ] threadWhen 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.
To point out the issue but maybe not say exactly what was wrong?
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.
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.
- 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.
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.
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.
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.
In fact you reminded me of the technique right now to check the responses and make sure nobody else had already said this!
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.
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.
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.
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
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.
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 -- Someone paraphrasing Ian Fleming1. 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.
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.
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:
https://news.ycombinator.com/item?id=30382437
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
If you don't have enough time frequently, it's time to reflect.
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.
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 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"
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!
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.
Of 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.
> 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."
It's strange that finding flaws is framed negatively. This ability is a positive trait in software development.
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.
“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.
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.
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.
Not all grown up people are adults.
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.
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".
Be like my previous intern.
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.