This seems exactly backwards to me.
Disconnecting ego from the work was the first big lesson I had when I started working in software. I hear parallel ideas from friends across industries, in fact an electrical contractor explained to me how he expects it of his apprentices just a few days ago.
I once had a joint software team with a client and put my foot in my mouth assuming they separated code and ego the way we did. The first time I reviewed some of their work, there was a design decision that I sorta assumed was the best of a few bad options. So I asked the developer why they did it that way.
I just wanted to hear some reason, any at all would have done. Something special about that approach, or that they considered the others and found it was, in fact, the least worst. Then we'd just move on, happy enough with our implementation. I'm used to doing that (and having it done to me) dozens of times a month. But what I got was not a defense of the design decision, and more a defense that he made a design decision. I touched a nerve. I now know to hedge, apologize before giving feedback and ask questions by asking around them. I don't really think it's an overall plus. Especially when the business domain puts high standards on us.
Until you can do that, you'll always be a lesser software developer. You'll concentrate on maintaining your ego instead of developing the best software for the problem at hand. In a way that's the gist of the article.
It's interesting, but at the company I've worked at, where we've had dozens of senior developers come and go, we've never had this problem. Our approach to code reviews is purely educational. "Here's how we do it so we have the least amount of trouble understanding each others code." Everyone seems to be good with that, and egos get left at the front stoop. I've learned lots, I've taught lots, and I've never felt better than anyone or worse than anyone. It's all about the learning.
And let me tell you, when you hire some junior dev, and he gets these code reviews, and 3 years later he's a senior dev and anchoring a project, it's a pretty good feeling. I think better than any feeling you can get from lording knowledge over others.
Reminds me of a joke-ish comment I saw on here some time ago: The difference between a junior and senior developer is the willingness to say "that bug was totally my fault".
100% agree. Any code you write for your employer is not your code - you should be comfortable leaving it forever tomorrow if a better opportunity presents itself elsewhere.
Agreed that the OP took the wrong lesson - the fix is not to lower standards, the fix is to learn to deliver honest and complete feedback with empathy.
I no longer ask 'why?' inside a code review, because it immediately puts the author in the position of justifying what they did, while feeling like they have to defend a decision.
Instead, I'll take a coaching (or a more socratic) approach that doesn't risk making the author feel dumb, or like they never considered the alternatives: "what was your reason for this?", "did you try x,y,z?", "I wondered if this would work?", "what is this for?", "what does this do?"
In addition to that, if I have a suggestion (or a suqqestion ), I will always follow it up with a refactored, copy/pastable code snippet to make it clear what I'm talking about and also to help push the review forward. This is especially useful for learning by example.
This means that code review takes more time and effort, but that investment of time has value. Code reviews become an implicit, shared mentoring space, and people like it when they see your review pop up.
My ego drove me to work extra hard to try and impress others. I would become petulant if I didn't get my way. I look back on the first few years of my career with so much cringe!
I wish it was my first big lesson, it took me way to long to learn and my mental health suffered greatly until I did.
I can tell you I haven't had this feeling ever, but not for reasons I'm proud of. I hate doing code reviews. I have hated doing every one. I have disliked having to type every comment I have made on a code review. Each time I hope that everything is good enough and I can just approve it. And I won't comment unless I am convinced it is important.
I don't hate the coder, or the process that requires code reviews. I know code reviews are very important for many different reasons, so I don't shirk them, but I have become afraid of being an expert on a large team as I will have to do more of them. Not sure what is wrong, I love coding. Reviewing good code isn't so bad, reviewing bad code takes all the joy out of coding for me. If it's bad enough, I know that I need to make a lot of comments, and I'll need to make some more when it comes back with changes. I think we are just wired differently.
EDIT After further thought, I think a fundamental difference is I really want to see my coworkers succeed, and don't enjoy their failure. Also I dislike all forms of toil. But I think maybe part of the authors problem is not able to comprehend that some people can be nice like that, genuinely. In fact, I assume my coworkers want me to succeed as well, and I really think most of the time they do. But I am glad he decided to start acting that way, which must be especially difficult if you don't believe others will treat you the same way.
I assumed the same was true for them. I learned from another team member to try to phrase comments as questions. "Did you mean to do X here? It seems like it might have issue Y" etc...
You ever worked on a team a where someone would go write code in their own crazy way that wouldn't follow any sort of existing pattern or take advantage of existing tooling? So they spend like a week on a simple task because they re-wrote the strings.c because they didn't want to include it? Yeah, they get fired eventually, but they are the worst to write code reviews for, because you go into it just thinking WTH, why are they doing it this way, this entire approach is convoluted and error-prone and rigid and fragile and complicated.
If a super engineer has advice for me on how to deal with this stuff, I'm all ears. I usually just ignore it unless it directly impacts me and then go back and re-write it when we have to add on to it/make it interop with some more code/release it as an available API.
Every 4 hours or so I would ask my boss if I really had to do it. He told me to just keep going, I think he was building a case for letting him go. I still only made like 10 comments, needless to say they weren't taken well. What a nightmare.
Tangential to this whole thread, but guys like that, every day he worked took two days for other devs to fix/undo his work. Took my company a few years to catch on, he was a senior dev and also good at talking himself up. I would have paid him the same salary to go sit on a beach somewhere and enjoy himself instead of touching the code, we'd all have been happier. In fact the world would be a better place, because now he is presumably working somewhere else doing the same things.
I'm in both of these camps too. I think I'd dislike code reviews if I didn't remind myself:
* Code my coworkers write is code I don't have to write, so it's saving me toil.
* Issues I catch in review are issues that won't lead to late night debugging sessions catching heisenbugs on the eve of shipping our product, so it's saving me some of the worst kinds of toil.
A little work now to save me a lot of work later. And I've been burned by suddenly getting stuck maintaining & bugfixing code that I got lax about reviewing. Each issue I catch, I think "thank goodness I caught that now - that'd be a pain in the ass to debug".
It also makes me genuinely appreciate review feedback catching all the dumb shit I might do, which can really help when your quick change turns into a slog of missed edge cases, "can you fix X while you're in there", etc.
There's great health to be gained from code reviews. But they really do need to practiced, reconfigured, and practiced again so your team gets what they need from it.
Best way of doing code review is by asking questions.
Recently coworker recommended this talk which suggest good attitude IMO - you can find it under "strong code review" from rails conf
I tend to lean this way as well. Im of the mindset that most things that are "caught" in a code review don't add any real value. Or maybe I just have bad coding standards.
These comments stuck out:
"Because I do code review for self-identification."
"It turned out that, instead of becoming a good coder, you simply have to convince others you’re a good coder. This behaviour begets a vicious cycle that produces not professionals, but toxic asshats."
One way to nip this culture is stop hiring people who only KNOW THIS culture.
If the author is reading this, there is one solution I have encountered: diversity. If you only hire white dudes in hoodies with stickers on their macbooks you're only going to get the toxic gamergate crowd, which has not gone away at all.
Believe or not there are other kinds of programmers in the world, and the most enjoyable products I've worked on were ones that had more women and more POC on their teams. Toxic asshattery can be minimized by not giving them complete control over the culture of a workplace.
Mindlessness mixed with insecurity is a toxic brew.
The implicit -- wait, no -- the explicit argument of your grandparent post is that all white men are the same.
Of course people are going to push back on that.
But do you really care, seeing as to how you've already furthered a theory of someone else being either emotionally hostile or defensive?
And do you really not see the obviousness of how a certain situation plays out, of someone using white guy with stickers on laptop as a symbol for toxicity? Or do you see the obviousness, and that's why you're playing the situation out this way?
I still have my stance but I've found that people that get sucked in, on both sides, will get hypersensitive about detecting their opposition, and then they project all of the ideas they dislike the most onto the person in real life who exhibits a hint of it.
You might find that you are trying to find things to be angry about. You might feel very strongly that masculinity is toxic but you don't really have any examples in your life except for the two and a half times you got cat called. The "gamers" that hate minorities and women might be on the forefront of your mind, but only because you spend too much time consuming narratives online.
Genuinely how many people would be concerned about toxic masculinity if the internet didn't exist. How many people would be concerned about the culture war at all if outrage couldn't be shared.
As much as you might like to blame it on a particular skin color or gender, your happiness and peace of mind is your responsibility. If you are frustrated, angry, or sad about gamers, the gamers aren't the problem, you are losing control of your mind.
You just crossed the line from making this about the issue to making it personal. That's not okay.
He didn't imply that women and non-whites can't be self-centered egotists, only that they're less so than white men. Despite the author of the article being Russian, a very different culture than the US.
* There is some built-in diversity of skillsets, if not demographics, by pushing team communication into a continuous meeting format where non-developers are given space.
* It forces some vulnerability into the mix, which gets you into a less inhibited state: "I don't know, but" is way more common if you literally can't run off and prepare some slick answer to every question or hide behind your ownership of the solution space.
* The I/O bottleneck of having a whole crowd at one screen moves the emphasis away from the lines of code, and towards the broader parts of problem solving and getting feedback. Everyone that's experienced always says that it's not how fast you type that matters.
* Feedback becomes less punishing. Everyone gets a chance to drive, make some minor errors, and immediately correct them, which keeps everyone on the same level and encourages a healthy attitude to learning, vs the anxious/punishing "all-seeing-eye judgment" nature of batch code reviews.
But mostly, I like the idea of a hypothetical mind-melded "superdeveloper" emerging from a mob - a coder that pumps out extremely high quality code solving exactly the right problems in a single iteration, without breaking a sweat. I do think I've seen it in bursts in the past, just not in a systematic fashion. My experiences with pair programming definitely suggest that it adds intensity to problem solving that isn't there alone, and it makes me suspect that we may just straight-up be "doing software wrong" by focusing on quantities of code edits and not the overall communication flows.
(Sarcasm, Office Space reference, I'm with you on the stickers.)
By plastering your laptop with a completely unique combination and placement of stickers one can discover in videos or photographs online from conferences or talks for example, you make it a whole lot easier to pick out your unattended machine from a set, a hotel room, or luggage.
This can easily be leveraged by assisting targeted theft, destruction, or sophisticated physical access attacks.
I know that feel, but you can flair up with whimsy rather than corporate tribalism. For example, I have a strawberry from the game Celeste over my MBP's apple logo. It's even less billboardy than before!
> you make it a whole lot easier to pick out your unattended machine from a set, a hotel room, or luggage.
Laptops get mixed up all of the time in security when you fly. A sticker both reduces the probability of this happening accidentally and also makes it harder for a thief to claim innocence if you keep your eye on your laptop and notice someone nab it.
Um, excuse me? I'm a white dude who wears a hoodie and has a sticker on my macbook, and I am not in "the toxic gamergate crowd." If anything you're the one being toxic.
However, I'm not sure that diversity is really a solution so much as a symptom of a solution, which is a healthy professional culture. Adding women and POC may work tactically but it's not a great long term strategy for solving that particularly problem -- it's entirely possible for women and POC to behave in this manner (although it's quite a bit rarer in my experience). Not saying you're suggesting this, but I've seen quite a few orgs where women and POC are hired as tokens and don't get to real positions of power where they have the power and responsibility to truly run things and reform/refactor systems. Reforming your organization so that it's not toxic to women and POC is an indicator that you're not going in the wrong direction, but it's hardly the end goal. In fact, it should be positively mundane, boring, average and the norm (and hopefully, will become that way soon).
Will these problems cease at that point? I doubt it. Callous, abusive leaders exist everywhere, and short of a massive societal shift where nonviolent communication becomes required reading for managers and leaders (which is verbatim what Satya Nadella did at Microsoft to great effect), the high leverage move would be to start there and not paper over the root.
These problems come from the top -- corporate and engineering leadership. If you have a culture that accepts and allows for brilliant jerks, there are a couple root causes:
1) Your leadership aids and abets it
2) Your leadership is apathetic about it
3) Your leadership dislikes it but feels powerless to stop it
If you've got issue class 1 or 2, it's likely more pragmatic to leave than try to wage a cultural coup (of course, more power to you if you can pull that off). If you've got issue class 3, well, maybe you've got some options. You can convince leadership that they've got a certain kind of problem -- easy enough. Then you've got to convince leadership that a given approach could ameliorate it -- doable, but tricky and not at all a guaranteed success. Finally, you've got the hardest part: actually implementing it. The resulting shift in power could result in folks trying to sabotage things, and success will be doomed unless it is unilaterally supported and individually guided through by leadership. This is rare, but possible (again the Nadella reference). But again, the goal should be to create a cohesive, respectful, supportive teamwork oriented environment, and the means should support that.
If you can pull that off, achieving not just diversity but a safe, sustainable place for folks of diverse backgrounds to thrive becomes a real possibility. I think that's why it's worth setting our sights there in the first place.
Then I started to worry that I was coming across as passive-aggressive, that these suggestions would be taken as veiled demands to fix things.
As a countermeasure, sometimes I'd explicitly say things like, "you can submit this as-is, but here are a bunch of things you might want to think about." This works ok for stylistic changes or things that aren't actual bugs.
That's not always realistic. Another trick that I think maybe we should do more in the industry is what I'd call ping-pong code review: When you get a review, either submit it if it's good enough, or rewrite it and send it back to them for review. Then they can either submit it, or do another rewrite and send it back to you.
This helps the most if there extensive changes needed, and you are a picky person who likes to have things just right. But, if it goes against company culture, you might need to make sure that people understand what you're doing and everyone gets proper credit for helping with the patch.
I agree with the approach of asking questions and making comments like "some things to consider with this approach".
Generally speaking I find that code reviews are invaluable, but it takes some practice and good language skills to find the right "style" and wording in order to appear constructive vs. bossy know it all.
I've only done it a few times where I was the project owner, and I apologized in advance for being overly picky. There was also good reason for it since we were many timezones apart.
Telling someone to change the code (and maybe having them misunderstand) is often less efficient than changing it yourself, due to the extra round trips.
If you're sitting right next to each other, some other technique like pair programming is going to be a lot faster.
For example, if you're sending a patch to the owner of the code and they are known to be very picky, maybe it won't be considered an insult to rewrite it, since in the end it's their project and it saves a lot of back and forth? Or maybe it's a team where they have gotten used to it?
Believe it or not, starting from a patch that actually works is actually pretty helpful and does save time compared to starting from scratch.
No, you want to believe you're an alpha male. If you have to keep proving it every day it's not true.
You're acting out because you're insecure as hell and you're trying to prove to yourself that you're an "alpha male". A big part of being secure in your own opinions is letting other people be wrong sometimes.
At some point nothing you can say will stop them. Now you have to switch over to contingency plans. If you're absolutely sure it's going to break if they do it that way, then you need something more constructive than 'I told you so'. People trust you when you pull their fat out of the fire multiple times. Not when you dick wave at them.
> and in a way that I contemplated quitting the industry. I was too dumb for all this.
No, you're not too dumb. You're just wound tighter than a kettle drum. What you need, and I'm being sincere here, is a therapist, not another book on code styles.
We all have our histamine reactions to different things. While you're worried about 5 things someone else is worried about 3 others, one of which you never even thought of. I would hate to be on a team where everyone only cared about exactly the things I care about. My priorities help find issues faster but I don't find them all myself. A team of me would be almost as lopsided as the things I push back against. I try to remind myself that when I'm having trouble with feeling like my #1 priority is someone else's #15 or NaN.
The guy was undeniably brilliant, pretty clearly smarter than anyone else on the team (including me), but he had a way of bringing down the entire team to a point where it actually felt like we were less productive a result. After about a year of this, he was fired.
Ironically after he was fired he and I became pretty good friends, and I feel that, at some level, I became the new toxic douchebag with my (probably unearned) feelings of superiority. When I realized this, I actively tried to employ a bit more empathy when looking at code reviews and dealing with people that I felt were stupid, since I was the "stupid" one before.
I often discuss with people the philosophical question of "is it better to have someone who's really smart but also an asshole, or someone very nice who's barely competent?". I tend to lean towards the former, but I can't say for sure.
I wish I had a magic blog-post-length formula for how that happened. I don't. I know I personally talk about it in interviews, and we hire for developers who think about development as a team sport rather than a solo FPS rampage, and we talk about code review sort of a lot in onboarding.
The way I explain it to noobs is that a collegial review culture is a question of trust. When we all believe that we are all on the same team with the same goals, we feel safe, and we can trust that (1) critical feedback we receive from others is intended just to improve the code, not to score points on us personally, and (2) if we give feedback that is critical, it will be received in that spirit as well. And it's our responsibility to give critical feedback where the code under review doesn't meet our standards of efficiency, readability, and maintainability.
Grandstanding or mean-spirited reviews break down the team-wide spirit of trust and the feeling of safety; they are a far greater danger to the integrity of the code base than a badly-coded method or spotty test suite.
Presumably, codestyle comes easy for them due to their neurotype, but they have a hard time reining themselves in and just end up wasting thousands of other developers' hours for zero business value.
I've never understood why these people don't just spend a few minutes adding some rules to ESLint or whatever.
However, while this person really feels like an asshole, it's incredibly mature of him to recognize his past behavior and try to improve.
For many developers, it's incredibly satisfying to "be right", and due to the fact that's it's easy to leave some comments, the humanity of their coworkers can often take a backseat.
Its probably too carte blanche; but ive reached the point where I will refuse to rule on codestyle issues (general answer; whoever did it first sets the style)
Code authors who don't see the value in consistency of code are potentially a problem - if authors are submitting code reviews with hundreds of actual style issues, that's either a failure of process or the author to write readable code (not sure if that's what happened in your examples, to be clear).
Style is not consistent across authors, codebases, projects, even companies. I had to learn to read code in many different styles.
Enforcing consistency can be done with formatters/linters. It doesn't need to come up in review.
Tooling is great, but I think there are a lot of style issues that aren't readily enforceable with linters - commenting, naming, control flow, abstraction, etc.
Sometimes the quite serious bugs are just hard to notice, as well. I recently reviewed a large changelist dealing with lots of multithreading and locks, and cases where locks aren't taken to avoid deadlocks. I have 0 confidence I caught all edge cases, which terrifies me for multi-threaded code.
Simplifying is easy. Early versions of this code, years ago, were simple. They weren't even multithreaded! Just a simple implementation to unblock other devs.
But now it's a highly used bottleneck that must be high throughput, low latency, support asynchronous cancellation of requests, interacts with the main thread for third party APIs that aren't thread safe (such as d3d9), interacts with the main thread for our own APIs which aren't thread safe by design (our debug replay system replays the events of the main thread), but must avoid synchronizing with the main thread for performance elsewhere...
Simplifying this without performance or feature regressions is significantly more difficult. Possible, but difficult. And benefits from slow, testable, incremental changes. But that means reviewing incremental diffs on the large and complicated existing system in the interim. At least it has some of our best test coverage, including lots of tests to help try and tease out threading bugs. They don't always succeed at that, but they do help.
I can generally differentiate between personal opinion and bad form. I rarely comment on things like variable names, or function names unless they are really confusing or misleading. I have my own style, but the existing style of the code should be what we code based on, not personal opinions.
I think the OP is shirking their responsibilities for what they’re being paid for. If they are doing a code review it’s for the benefit of the team, so that the team member understands what their expectations are. You don’t have to be mean to be a good code reviewer.
When I submit my code for review, I don't just want a rubber stamp, I want thoughtful feedback. If something can be improved, I want to know about it so that I can do it better next time. I try to pay other people the same courtesy. Another commenter said it's all about "disconnecting ego from the work" but I don't really agree. I care a whole lot about my code and that's why I take code reviews seriously. But that doesn't need to translate to anger or feeling emotionally devastated as the article's author somewhat bewilderingly seems to ascribe to his "victims."
Another thing that I keep in mind is a joke I heard one time that you measure how good a piece of code is by the WTFs per minute exclaimed when reading it. It's a metric, not an emotional reaction, and it's going to be at least unity no matter how good the code is.
Then again, I've had the good fortune to work with good people, so maybe I'd be seeing red too if my coworkers were writing really awful code all of the time.
I don't know you, so you might be 100% right but if the article makes you feel slightly defensive, perhaps it's a good reason to do some introspection.
Great developers see the opportunity to grow someone.
The former shows ownership of the code, but is generally bad for a business.
The latter understands that a successful business is more than simply his competence.
Reaching this level of realisation is critical for being a good lead; I interview loads of clearly solid programmers who havent figured this out, and sadly price themselves out of the market (I blame their previous managers for missing their growth opportunity)
> No big deal if the code’s not good, I can fix it myself it I need to.
A mentor can't be passive like that. Don't leave 200 comments like you used to, but distill them into something smaller, more cogent and digestible. More importantly, drop the idea of "good" and focus on what the implementor was thinking. I think the author understands the need for more effective communication in code reviews, but unfairly reduces the exchange to an "argument."
It's also dangerous to correlate work-life balance with incompetence. It's not a contradiction to be good at your job, current with the industry, and present for your family.
The purpose of code reviews is to get quality code. Quality code makes the project work. But why do we work on projects to begin with? To benefit people.
This guy is realizing the conflict between the two goals of getting quality code but also serving people.
People need criticism to improve, but it needs to be constructive, otherwise the fragile human psyche inside of every person may not recover.
Many times developers get held to standards that they didn’t know existed. This still triggers developers to feel bad about their work (or themselves). It’s usually after someone has left that they find out some ‘standard’ only exists for that particular company.
It’s hard to make global standards, but company standards are easily do-able without having to endlessly specify every coding situation. What the standard doesn’t cover should be addressed in code review or before.
I try to view code review as my chance to pass this on. It's about teaching someone how to read their own code with a critical mind. It's definitely not about superlatives like best, perfect, whatever.
Humans need face to face contact, because this kind of contact gives you instant feedback about what effect your words and actions are having. It's how most people experience empathy.
I'm one of those who is far better at text communication than face to face due to the luxury of being able to carefully consider my words and their effect rather than having to clumsily do that in real time, but a side effect of this is that my every word gets rewritten multiple times as I try to get the overall tone right, and try to head off potential misunderstandings. My success rate isn't super great, but it's far better than my face to face.
With most people, the opposite seems to be true. Worse: they seem unaware of text communication's shortcomings in terms of the social and emotional feedback loop - empathy. The most toxic people online are often an absolute delight in person, completely oblivious to the damage they're doing because they're empathetically blinded in the other medium, and unaware of the fact.
Nobody can read his mind but yet he's expecting rookies to write like veterans.
Typically experienced developers mentor junior developers. If that's not what the author wants to do, then hire only senior developers to not worry about junior mistakes.
Also instead of pointing out all the wrong things, pointing out the good things too are a way to boost the junior developer's motivation.
Wrong on so many levels. Taking pleasure from someone else's mistakes is a sign that something is wrong with you. That is all. The only thing that is exceptional is that this industry has a high tolerance for this behaviour.
It also sounds like this guy is destroying value. If you are such a poor manager that you try to get rid of someone rather than bringing them up then you are a net negative. Again, I have come across this in other industries: the manager will go before the junior. No question. Writing bad code is nothing compared to the impact on culture of one bad apple.
Instead of "Why would you ever do it this way?", try "I think I would probably do this like (example)"
Also, be liberal with complementary reviews, as well. I see a lot of pull requests where the solid, workday, well written code is just passed over, or given a ":+1:", even though it's definitely worthy of praise.
You wrote a new class extracted from an old confusing method, it has good tests, and the feature is working as requested? A triumph.
I'm 100% like this. I'm not proud of it, and while I guess I can hypothesize about "why", my takeaway is the same as the author's : it's a horrible and potentially very hurtful anti-pattern.
Kudos to this dude for raising his hand and acknowledging his own problem. All I can say is, I'm the same way and I can and should do better.
But you want to look at it like an artifact that you'll later on refer to. Don't be a pedant and ding based on style. If there are substantial design flaws, politely note your concerns, and then hash it out over chat or in person. Your goal is constructive collaboration, and it's really important to use the right collaboration tool for the right job.
Often times, what happens in code reviews is that we find up front design that we neglected to do, or which was done in a way that has structural problems. That's fine -- in fact, the ability to do that incrementally is part of why lean works well. But that means that you've got to then do a proper design session (formal or informal) to get to a better ending place. If you really want to be cooking with gas, figure out a lightweight way to structure and record the results of these design sessions so that people will use and refer to them.
I've seen teams grind to a screeching halt over poor usage of these processes, and not because any of the engineers were poor individual contributors!
I have a done a lot of review not as much lately but my principle is pretty simple - Can this be made better to the best of my understanding and knowledge. I will give it the same attention as I will my code. When my first version of a code or the POC is done I will think of what can be improved upon with the goal of the final version to be cleaner, faster and more robust if possible. My job is to help the author and the company to make sure together we get the best version possible merged of course with an understanding of cost-benefit.
The language is of course important but not catching issues on every line if that's what I find. I will appreciate if someone does the same thing for me. At one point I have reviewed more than 50% of the codes in my company and I know how hard it can be to do so with full care so I take it as a favor when somebody does a good review on my code finds mistakes or potential improvement. I have had way junior developers giving me feedback ranging from better names to serious bugs. I have also always explained why a certain idea should be explored or might be better with the author regardless of how junior they might be. I have always liked the developers best who leaves the ego out of it both a reviewer and author of a certain piece of code. Pride and Ego I find are unrelated. I take pride in giving my best both when writing a code or reviewing one all the while knowing not just that there are other developers much better than me but even someone who is on average worse than me can still find potential improvements in my code. I like to think that I can take any comment on its merit and not my perception of the person.
Because unlike people that think there are right ways I know that it's all religious arguments. Last I checked there are 0 credible reproduced scientific studies about what is the correct way to program. Or even a better way. So as far as I'm concerned it is all opinion based and sure I also have my opinions but, consistency, rule of least power, DRY, agile, OOP, single responsibility principle etc etc are all religious notions.
There are only 2 things that matter: does it work? does it work fast enough?
And normally the arguments boil down to:
"Oh but it is not changeable!" - maybe you should make something new
"I can't read it!" - I also can't read Chinese
"I don't like it" - well not everyone likes chocolate
What is not clear in your comment though is that that means looking at the code and making sure there's no mistake too in it too.
It may seems like it's working as expected, but maybe you'll find an edge case that was missed by the original developer.
It's possible too that the solution of the original developer was clear to him, or that it's clear knowing the context of the ticket, but once in the wild, that code may become incomprehensible (which later on can bring more error because someone misunderstood why that line was there and changed it incorrectly for example). That can be easily fixed by adding a tiny comment there.
Sure doing what it's supposed to do in an acceptable performance is great, but I think there's a bit more into a code review and ignoring theses can be quite problematic.
> "I can't read it!" - I also can't read Chinese
Doesn't this show there's an issue though in the long term? If you are the only one that can read Chinese in the company, maybe it would be a better idea to consider using English?
Or to put it another way, the human costs of maintenance and bugfixing are usually large, and may even be the largest costs on a project.
For example, in a recent code review I found a function where an argument was being passed in but not used, and a constant of the same type with a similar name was used in the body of the function. That obviously happened because the author got halfway through refactoring their code and didn't realise, and we were both happy to fix it.
When I’d justify my decisions they’d go Google and always manage to find a counter point. But their having to Google it made it obvious they lacked deep understanding of much of anything.
There was one guy who was particularly notorious for being harsh and awkward to work with. I found this to be true but he was also the only guy who seemed to understand concepts so I was able to work him (to everyone’s surprise!)
I saw many other developers frequently get a bruising but I always managed to take a step back and focus around the real problem - the people in charge were just angry.
"Greater in battle than the man who would conquer a thousand-thousand men, is he who would conquer just one —
himself. Not even a God, an Angel, Mara or Brahma can turn into defeat the victory of a person who is self-subdued and ever restrained in conduct." -- Dhammapada 103-105
I'd rather have ten mediocre developers who can be part of a team than one gifted diva.
We recently managed to get rid of someone that wasa this sure of himself that he had the impression that he carried the team.
While his technical skill was sound (though no better than any halfway-decent senior developer) the reality was he was a poor communicator, kept knowledge to himself, posted snarky comments on reviews and cast apersions on everybody else's skills.
He was an egomaniac and the team has fared much better without him.
If you ever find yourself with a team member like the author of this blog post, be mindful of the damage they can cause because of their own inflated sense of self-worth.
> It can’t be open-sourced or used to lure new developers.
This is a mostly unrelated takeaway that I wish more companies followed so that I could take a look at what I'd be working with when they try to recruit me.
My feeling is that criticism, no matter what the domain, should be relatively dispassionate (neutral in tone), and come from a desire to help and with a dose of humility. Of course, I sometimes fall far short of that ideal.
This is why I try to word reviews as questions, not statements of facts:
"Is this supposed to be reversed? I think it might not do what you want it to"
"Having a bit of trouble following this logic.. is there a way to make it more clear to future readers?"
"I might be missing something, but I don't see how this code can be reached?"
Don't give the review in such a way that implies you know everything and the other person was wrong. It should be a dialog, and be based on the assumption that we don't yet know the right answer and are working together to figure it out.
My personality today isn’t my disease. It’s a disease of the whole industry, at least in Russia. Our mentality is predicated on the cult of power and superiority. And that’s what we need to fix: just stop being that. It’s quite easy, actually.
A bit of irony in the, "It’s quite easy, actually," given the thesis. I can't imagine a harder talent to learn than emotional intelligence. I would rather teach someone...I dunno...concurrent programming than how to stop being an asshole.
People that are really good at things are graceful and helpful usually.
PS-Question: Author mentions Russian culture being an influence. I feel like he's saying there is an emphasis/high value on ultra-competence ultra-stoic unshakability sort of state of being? The meme is that Russians are intense, which I fully respect.
Often code reviews come in after someone has put a few weeks of work into something and its too late to change how it was done. Or a review is passed in by someone in a hurry without actually critiquing it.
* Authors are expected optimize for readability of code, even if it takes longer to get the code in.
* Reviewers should generally only start reviewing code if they are ready and willing to continue the review to completion (i.e. no drive-by reviews). Once they start reviewing they should try to minimize response time.
* Focus the reviews on testing, correctness, readability
* Consistent code style is important (see optimizing for readability)
* Break code reviews into the smallest reviewable units. Often these are somewhat large because parts of the change don't make sense in isolation
* The code author is responsible for writing code in a way that it convinces the reviewer that it is correct (see optimizing for readability)
* You should approach it collaboratively - you're working together to get the work done and make the codebase as maintainable as possible
* You should aim to leave each bit of the codebase that you touch in at least a good a state as it was previously
If code review breaks software developer's psyche, then this software developer is unlikely to be any good in the first place. How can you be good without ability to listen to code review feedback?
I disagree that pointing out every flaw in a code review is a bad thing to do. I believe that these could be positive experiences with the right attitude from both the reviewer, the submitter, and the team's management. A few things that really bugged me while reading this:
- The reviewer feels like pointing out a flaw is an adversarial zero-sum sort of action that affirms his superiority over the submitter.
- The submitter will feel bad about each feedback given (at least in the POV of the author). If the feedback is mean-spirited, then sure, but if it's constructive, then this shouldn't be the case.
- His team fired the developer who received "too much" feedback. I'm sure there's missing context here, but if that's the main reason, then this is pretty messed up.
Finally, his conclusion to not submit the review really bugged me. I do agree that no review is better than a mean-spirited destructuve review, but IMO this is still a failure on the part of the reviewer. He should write the review in a constructive manner and work with the submitter to hash out the issues. If it's an argument, then fine, work through it... but teammates should help each other grow and be better.
In this case, by not submitting honest and comprehensive reviews, I believe his team and his product suffers in the following ways:
- The reviewer has to waste his time "cleaning up" the code later on.
- The submitter loses out on the knowledge transfer that takes place during a good code review.
- The product potentially has unfixed bugs.
- A fear of conflict is further instilled in the team, and criticism now becomes off-limits because it is considered destructive due to the negative attitudes of everyone involved. This further hurts product quality, and the result is that everyone codes in isolation out of their ivory towers instead of collaborating on a product together, among many other detrimental effects.
I think the solution at least begins with:
- A better team commitment to personal growth, and a sense of responsibility on the part of everyone to help out their teammates in this respect.
- Clear team guidelines on lint/style standards to eliminate the need to argue about it.
- An attitude that feedback is about the code and NOT about the person submitting it. Everyone should feel like an owner of the code, and all discussion should be about the code and how to improve it.
- Comprehensive code reviews. Note everything you find. Maybe call an in-person review if you feel like there's too much to comment on.
I hate this. This always shows a developer whose only idea of a good developer is himself.
Articles complaining about the reality of code reviews seem to be commonplace. But if they're not working out, why not just abandon them, maybe try something different?
The one alternative that (some) code-review advocates seem willing to accept is XP-style full-time pair programming. But that leaves even less room for individuality and solo accomplishment.
Dollar for dollar, code reviews are more effective at finding and fixing bugs than any other activity we can do, including QA tests. However code reviews are very hard on people, and can easily create conflict.
Which one matters more, and how careful people are, varies widely by organization.
Comments on pull requests are not on the same level and those findings shouldn't be hastily generalised.
Change your position to .NET (uppercase). There's no technology called .net (lowercase).
Actually, can somebody write that? :P
Kudos for saying it aloud though. Honesty is gold (at least in my books).
If your codebase is going to be maintained for a long time, letting sloppy or inconsistent code in is going to make it much harder to maintain or evolve in future, so just lowering standards to make people feel better doesn't work. It's totally reasonable to hold people to a high standard if they're submitting code that others will have to maintain.
A lot of the problem is if people start off with the expectation that their code should be merged with minimal modifications, they're going to be upset when a code reviewer seems to be moving the goalposts on them. Also if the reviewers comments are arbitrary (or seem arbitrary) because they're not obviously grounded in consistent standards.
I've seen a project go through the process of tightening up code review standards and it was initially painful (a lot of people used to the old way feel like they can't move fast enough, etc) but ultimately worked out and resulted in people shipping working features at higher velocity with far less time spent on rework and maintaining overly-complex and buggy code.
There's also way less conflict in onboarding new developers because standards have been made clear in advance and reviewers are expected to be respectful and coach newcomers through the review process.
The hard part, I've found, is working with developers who can't or won't get code to the expected standard, even with coaching and detailed feedback. As in, repeatedly making the same simple mistakes pointed out by reviewers and failing to understand and address relatively straightforward feedback.
I'm not sure if there's a solution to this, beyond minimizing the damage and trying to move the person to a role that they're more suited to. In one such instance the person was, in retrospect, a complete liability - they switched to a different team with looser code review, got a "bugfix" committed with some obvious errors that, if not luckily caught by our team, could have potentially had disastrous consequences for some customers, then left the company. Maybe the lesson is that high code review standards contain the damage from such people.
Edit: I also think this requires code reviewers to approach the reviews with the attitude of "what do we have to do to get this merged without compromising our standards?", not a desire to tear down the person or block the code change.
basically starting a rant about being a tightass about code review with a bad piece of code
I'm tired of dealing with people like this. It does not have to be this hard. Tech companies should fire more people just for being jerks.
> I was mad that, while I spent my nights learning F#, my daughter started calling everyone around “fathers”.
Huh, you mean missing out on the good parts of life while martyring yourself for a company that does not give a shit about you can lead to resentment and toxic work culture? YOU. DON'T. SAY.
Honestly, a lot of the time management will stoke the "hero coders" ego so they will do the free work.
Management: Oh, Hero Protagonist! We need you! How will we ever earn enough to give our CEO the 15 million bonus if you do not martyr yourself for this feature?
Hero Protagonist: They're right. I am the best and smartest. I better dump all of my emotional labor onto my coworkers and significant others and bury myself into doing free work for my company.
> When you work as a developer, you always have to argue. You, as a team, arrive on a solution after a lot of argument, even though we call them “discussions”.
I do not feel this way at all. There are productive ways to have discussions that do not involve getting defensive and arguing.
The fact that you have to drag all of your discussions into toxic arguments in order to save face is... sad.
> And yet it’s somehow important than your arguments “win” more often than not, just to feel good and confident in your power.
No, it is not. That is just how you feel to justify your constant toxicity.
I see very little "power" in bullying all of the other developers on my team into following my opinions.
> This review I kicked off the article with? I didn’t send it. Instead I gave the guy a couple of comments and politely asked to fix a couple of things. No big deal if the code’s not good, I can fix it myself it I need to. But I can’t fix the psyche of a guy broken by dozens of harsh reviews.
> My personality today isn’t my disease. It’s a disease of the whole industry, at least in Russia. Our mentality is predicated on the cult of power and superiority. And that’s what we need to fix.
Further, unless I am misreading the tone of the article, the author is listing out all of the defects you quoted not to defend or justify, but precisely to highlight their ridiculousness and falseness.
The author actually addresses that. It's just the style of the article takes you on a journey in his mind before getting to the conclusion. It's a different style of writing. From the article:
If we were being laughed at while young, it doesn’t mean you have to return the favor later on. The vicious cycle can easily be broken. Life becomes easier if you learn to lose arguments, if you can admit that another developer is more talented than you.
The article is thought provoking. It makes good points, even if you don't like the author. I can relate to a lot of his examples.
I love having my code thoroughly reviewed. It does not ruin my life to see someone say "I don't think this is a good idea." I think you have to be operating on a different level to be ruining lives through pull request comments.
Meanwhile, your comment levies personal criticism toward him using pretty inflammatory language ("toxic," "sad," "asshole," "jerk," etc.), because of the way he responds to people who are learning.
Interesting juxtaposition, that.
The problem is that the traits that make someone a 'jerk' are often the same traits that make a '10x developer'.
Are you kidding? Call me a liar if you want, but I don't feel that way when doing code reviews, and never have.
Yes, when I was a teenager I wielded my knowledge like a titan. The meager amount of knowledge I had.
But as a professional, I have never once been mean-spirited in a code review. Everything I send back is to keep the code clean and maintainable and to help the developer improve.
Not everyone feels the need to be "right" all the time. And by that, I mean being perceived as correct, even if they aren't. For me, that was a function of actual skill.
The better I got at programming, the less I needed everyone else to acknowledge how good I was.
Even better, that applied to the rest of my life, too. I haven't felt the need to show off my intelligence or skills in a long, long time. I simply do my thing and if/when someone notices, it's a great feeling. If they don't, I still enjoyed doing it well.
As a kid? I'm sure I did. I probably even did it about code on the internet. But I wasn't a professional then and wasn't employed as a developer.
A lot of elitism comes from going through a high level of discipline for no reward.
Just do what is fulfilling
Rich people collect money; find themselves empty inside; seek more money;
Find no reward in shredding through meaningless suffering; demand payback; be forced to extract blood from your fellow turnips.