melreams.com

Nerrrrd

Process smells

in best practices, process smell

I’ve been talking about code smells for a while, but code is far from the only thing that can go wrong. What about process smells? There are things in your development process that may not necessarily be wrong in every situation, but are a signal that something could be wrong. Some of these are more definitely stinky than code smells, but not all of them. As always, if you’re happy and productive with the way your process works, stick with it!

Here’s an example of a process smell: Friday prouction deploys (in case that tweet ever gets deleted or something, it’s a picture of a jack o’lantern with the words “Friday deploy to prod” carved into it and the caption “Scariest Pumpkin”). Friday deploys are almost universally a terrible idea, which makes them an especially nasty process smell, but once in a while they are actually a reasonable choice. Usually when they’re the least terrible of a set of bad options, but sometimes bad options are all you have.

If you’re fixing a severe bug that prevents a lot people from using the system at all, then it makes sense to deploy whenever you have a fix, even if that’s a Friday, even if it’s late in the day on a Friday. And if you have the unusual luck to have a dev team with staggered schedules who are all familiar with the code being deployed, then no day is really any riskier than any other (is this actually a thing? I included it because it’s technically possible but I’m not sure it actually happens anywhere).

If you work in a very rigid environment where nobody uses the system over the weekend at all ever, then knock yourself out! If no one touches the system over the weekend, then you’re not going to hurt anything by deploying on a Friday.

Most of the time Friday deploys are just a bad idea. Why?

Because no matter how great your QA department is, even they can’t test every single possible combination of weird commands and bad data and dodgy wifi that your actual users or customers can, which means things may break in wildly bizarre ways when no one is around to fix them. That sucks for your customers and sucks for your support team and sucks for your revenue and sucks for your reputation and sucks for your stress levels when you come back and discover that everything has been on fire all weekend. Oh and it sucks if you get called in to fix it when you thought you were going to have a nice relaxing weekend. Spare yourself and the rest of your team a lot of hassle and don’t deploy on a Friday (or late afternoon any day) if you can avoid it.

This process smell is really interesting if you keep in mind this definition of a code smell, by Martin Fowler:

A code smell is a surface indication that usually corresponds to a deeper problem in the system.

If you’re deploying to production on Fridays, there’s definitely a deeper problem. Who is even letting you do Friday deploys when they’re so widely acknowledged to be a bad idea? Or who is pressuring you to do them when you know they’re a bad idea? And why is that person getting away with it? Who is pressuring them? Why is it more important to say something went out than to be sure that somebody is around to fix it if anything breaks? Or, and this is really scary, is management assuming that developers can be called in any time night or day to fix things?

Unfortunately, there isn’t a neat set of fixes for process smells the way there is for code smells. If I could give you a few quick and easy steps to convincing your company that deploying to production on a Friday is a bad idea, I’d be a millionaire :) What I can tell you is that you need to understand why your team lead / manager / upper management thinks it’s a good idea to deploy anything on a Friday before you can convince them to change. If the problem is that upper management believes it’s lazy to wait until Monday when the deploy could be done on Friday, then explaining that deploying on Fridays hurts team morale by making people worry their weekend plans will be wrecked by a surprise issue isn’t going to convince them anything needs to change. On the other hand, if you remind them how angry your customers were the last time production went down on a weekend and stayed down for hours because that particular release wasn’t possible to quickly roll back and the developer who knew the most about that change was away on a long-awaited hiking trip, and tell them there’s a way to prevent that from happening again that costs zero dollars, you’ve got a much stronger case.

Context!

in best practices, career, development, software design

a railway bridge supported by brick arches surrounded by lush green jungle
Unrelated image from pexels.com to make this post look nicer in social media shares.

So I was browsing workplace.stackexchange.com questions late one night, as you do, and came across an interesting one: How to explain business priorities to a programmer.

That one didn’t go at all the way I thought from the title. It turns out the business priorities actually did make sense (the business had this wild idea that queries, even especially complicated ones, should take less than 4 hours to run) and the programmer was being unreasonably rigid in following “best practices”.

But weirdly, one of the answers said that both parties were wrong – that the programmer shouldn’t have been so attached to having nice looking code and the manager shouldn’t have insisted on using an anti-pattern. What? The anti-pattern (using raw SQL instead of the ORM) improved performance by multiple orders of magnitude! If performance matters at all, you cannot possibly tell me that massively improving performance was the wrong thing to do.

Okay, there is some nuance there :) If your ORM performs that badly it’s likely not configured right for your situation, so it might be better in the long term to fix your config than to keep writing custom SQL for every query that’s the least bit complicated. On the other hand, if you don’t have an expert handy who can tune your ORM config, it might be easier to ditch it, at least for the more complicated queries, and just write some SQL. Or hey, how about a compromise? Use a stored procedure, that’s what they’re for! If it’s a query you run a lot, it might even make sense to make a view for it.

No matter what you end up doing, it’s still not wrong to use a supposed “anti-pattern” if you have a good reason to do it. It’s the context that makes something a bad idea, even the best idea can turn bad if you use it the wrong way. The only way to know whether your “anti-pattern” is actually a bad idea for your particular situation is…. to look at your particular situation! You can’t just say something is an anti-pattern without knowing what the person using that anti-pattern is trying to accomplish.

Let’s look at another datebasey example. It’s generally considered a bad idea to denormalize your database, every database design course will tell you so. Normalizing your database ensures all of your data is always right by isolating everything that can change independently. Since you don’t usually bother to keep data at all if you don’t care if it’s all accurate, you almost always want your data nicely normalized.

But sometimes correctness isn’t the absolute most important thing. Let’s take browser or mobile games, for instance. If your game takes too long to load, your players will just go do something else and they might not ever come back. It’s much more important to be fast than it is to be perfect if you want to make money on a game like that. And if something does go wrong and a player gets mad because their data didn’t get saved correctly, you can just give them game currency until they’re happy again.

In a situation where performance is more important than correctness, normalization is the anti-pattern. Like I said, it’s all about context!

To be clear, there are some things that are just a terrible idea no matter what you’re doing. I don’t care how clever you think you are, your variable names need to make sense. And no matter how well it performs, if your system is so confusing than no one can make updates, then it’s a bad system. But for the most part whether or not something is an anti-pattern is about what you’re trying to accomplish more than it’s about the “anti-pattern” itself.

Everybody likes code that makes sense to them, and everybody likes to feel like they’re doing things the right way, but rigidly following “best practices” just isn’t good enough. If it doesn’t help you achieve your greater goals for your application (ie not just gold-plating your code, but providing value to your users or customers), it’s just not a good idea no matter how many experts call it a best practice.

And yes, that means you can’t know if your code is good or bad without knowing exactly what you’re trying to do. Welcome to professional programming!

Be a better programmer while still having a life: part 12

in becoming a better programmer, best practices, development, making stupid arguments look stupid

a waxing moon a little over half full against a deep blue sky
Unrelated image from pexels.com to make this post look nicer in social media shares.

Keep it simple!

It sounds obvious, but I have wasted so much time debugging problems that turned out to be something ridiculously simple like my browser cache being outdated, having forgotten to deploy my code, having made my updates in my local database instead of the staging database, etc, etc. Better developers are more productive, and you know what instantly makes a person more productive? Wasting less time!

Double checking extremely simple obvious things can save you massive amounts of time. Like I said earlier, a little self-doubt is good for you. If you can’t ever doubt yourself at all, you’re going to waste a lot of time on silly mistakes you could have just double-checked.

This can be really really hard to remember as a dev, so don’t feel bad if you mess it up sometimes. My best guess is that’s a side effect of working with complicated problems all the time, so we assume the problem has to be more complicated than just having deployed the wrong code like a dope.

Another great way to keep things simple is to build the simplest possible solution for your problem. This is such a common problem that we have an acronym for it already: YAGNI (you ain’t gonna need it). Before you write more code ask yourself “Do I actually need this?” Protip: if you actually need the thing it will be obvious. If you don’t actually need it, don’t build it. Yes, things should be somewhat flexible, but there’s a limit.

Names are a great clue to whether you’ve built something so flexible that all it’s really doing is adding complexity. If you can’t guess what your object/function/module is for by looking at its name, it’s probably too vague. Using Java reflection is also a bad sign :P

Another way to check whether you’re building something too flexible is to try to explain it to someone else. If they can’t follow what on earth you’re doing, it’s definitely too vague. Even if they can follow your explanation, another person who isn’t attached to the terribly clever idea you came up with may be a lot more willing to say “No, we don’t actually need this, this, or this. That part is really cool, though.”

You can also try asking yourself if there’s anything you could possibly take out of your design. If you were doing the thing manually (just imagine your database lookups are done in a filing cabinet or giant binder instead), what would be different? Would there be fewer steps? Fewer people/processes/forms/approvals involved? This can be a tough one for programmers because for many of us, super complicated “solutions” make us feel smart and we love to feel smart.

I’m not going to pretend I’m any sort of UI expert, but this definitely applies to UI too. Do you really need a setting for everything? No! Make a decision already, if you’re going to leave everything up to the user, what are you even for? At least provide a sensible default setting and hide the fiddly stuff no one cares about under an “advanced” tab or something.

You know who failed at keeping it simple? Yep, it’s Google bro. Hey, if he didn’t want to be used as a terrible example over and over he should have been a better engineer. Given the choice between ignoring all of the existing science about gender differences in humans and making up a ridiculous and complicated fairy tale about how even though sexism obviously exists that couldn’t possibly be the reason there are fewer women than men in tech (let’s just ignore the fact that programming started out as a job for women while the men physically built the computers), no it must be some bizarre feature of our silly ladybrains, and the simple and obvious explanation that sexism exists, dude went with the most complicated possible explanation.

The more complicated your idea, solution, or design is, the more chances it has to fail. That’s still true even if your argument wasn’t built on sand in the first place. Simplicity, on the other hand, tends to work a lot better. The fewer moving parts you have, the fewer things you have to worry about holding in your head while you build it. As a bit of an aside, if you’re ever wondered why even extremely expensive software produced by armies of highly paid contractors is so often terrible and buggy, it’s because there are too many moving parts for our poor fleshy brains to keep track of.

Simplicity is incredible timesaver, for both you and your team. Simplicity in your code reduces the number of bugs you create, and avoiding creating bugs is orders of magnitude faster than fixing them. It also makes it easier to fix your bugs when you do run into them. Simplicity in your design can be the difference between a project that actually goes into production and does something useful, and something that just never quite gets launched. Simplicity in your problem solving helps you catch silly mistakes that waste hours of your time, so keep it simple!

Be a better programmer while still having a life: part 9

in becoming a better programmer, best practices, career, development, making stupid arguments look stupid, unsolicited advice

brown wooden wheel on an old cart with fallen leaves around it on the ground.
Vaguely related image from pexels.com to make this post look nicer in social media shares.

Don’t reinvent the wheel! I’ve touched on this before, but it definitely merits its own post.

A huge part of becoming a better developer is understanding when you don’t need to write new code to solve a problem. The more code you write, the more code you have to maintain, the more chances you have to screw it up, and the more time it takes to write it. So before you write new code, see if there’s a library, a plugin, a product, a design pattern, or a best practice that solves your problem. At least see if anyone wrote an article or blog post about a similar problem and learn from what they did.

To be fair, sometimes what you need really isn’t well served by an existing trustworthy product or library and you do need to write your own custom code, but that needs to be an informed choice, not a reflex.

What I think makes a product trustworthy is active development and a large userbase. The main advantages of using a library instead of writing your own code is that you don’t have to update it and that most of the bugs have been worked out already because so many people use it. By all means use a small library that isn’t maintained if it’s convenient and not a core part of your project, but for the love of god don’t depend on a framework/database/core part of your project that isn’t actively maintained and/or doesn’t have any users. That will just end in tears.

You also don’t want to import a library for every little thing, the more libraries you import the more bloated your project becomes and the more chances you have to run into a bug in one of them (and let’s not forget the left-pad debacle), but for stuff that would take more than a few hours to write, see if somebody else already wrote it.

For example, writing your own regex to validate email addresses is almost certainly a waste of time. Are you really going to write a better validator than the Apache Commons EmailValidator? No, you’re not. And do you want to have to maintain it forever even if you do write a great validator? No, you don’t. So use the library and move on with your day.

Yes, writing code is way more fun than integrating a library, but when you’re at work your job is to get results. If writing your own code gets the best result, do that, but if integrating a library gets the best result, do that instead. Of course, to understand what gets the best results, be it a library, a whole product, an API, a design pattern or whatever else, that means you have to understand what’s out there.

As a bit of an aside, that’s why the Google bro is an incompetent engineer – his ridiculous screed shows he either didn’t read or didn’t understand any of the existing research about personality differences between men and women (spoiler: there aren’t any statistically significant ones). While junior engineers get a pass on not searching for or not understanding existing libraries, senior engineers do not. If you can’t Google (see what I did there :D) existing research or existing libraries, you simply are not operating at a senior engineer level.

Sometimes it is useful to reinvent the wheel – modern wheels with inner tubes and shock absorbers make riding in a modern car a lot more comfortable than riding in the first cars with their solid wheels (Google bro’s wheel, on the other hand, is square and the axel is off center, which is just embarrassing). If you can’t do better than existing wheels, just use what’s already out there and save yourself some time.

Ironically, admitting that you aren’t the greatest developer who ever lived makes you a better developer. Accepting that actively maintained, well-used libraries are often better than what you would write on your own not only saves you a lot of time, but also makes your final product better.

Link of the day

in best practices, development, software design

Jessica Kerr has a really interesting blog post about how code reuse is often overrated. Back in college I learned all about how important code reuse was and how duplicated code was the worst, but we never (probably because we had a lot of material to cover in a limited time) talked about how code reuse can cause problems. Jessica gives a great explanation of how bad code reuse can paint you into a corner, you should check it out.

 

 

What’s a code smell, anyway?

in best practices, code smell, development

a rugged metal tower, possibly a lighthouse, seen at low tide on a rocky beach with puddles all around
Unrelated image from pexels.com to make this post look nicer in social media shares.

Design is one of my favourite parts of programming, but I constantly run into the problem of how to tell whether my design is any good.

Before we go any further, I think we should define what makes a good design is. My definition is that if you can change it in the future without cursing your past self, it must have been good design. You may have noticed that using that definition makes it difficult to figure out whether a design is any good until potentially months after the fact when you need to change it. It would be nice to know ahead of time whether your design is going to lead to a lot of swearing in the future, and that’s where I have trouble.

To be fair, if I could definitively answer the question of whether a design was good without having to try to change it, I’d be a millionaire and I’d be writing this post from my own private island :) Whether a design that seems good now is going to continue to be helpful in the future is just a hard problem and there’s no getting around that.

That said, I think code smells can help a lot there. A code smell is, in the words of Martin Fowler, a surface indication that usually corresponds to a deeper problem in the system. The term was coined by Kent Beck while he helped Martin Fowler with his book Refactoring.

This whole concept would probably make more sense with an example. An especially designy code smell is a class that does too much. Ideally a class should have one responsibility – if it’s concerned with more than one thing that’s a strong sign it should be broken up into separate classes. The specific problem with a class that does too much is that it’s likely to lead to long, messy methods that do too many things and don’t make sense because of it, and it generally makes it hard to reason about your system. The more one class does, the more state it’s likely to need to keep track of, and the more state one class keeps track of, the more chances you have to completely mess it up. You may have gotten a hint here that software design is about accepting that humans are bad at it and trying to work around that basic fact :p

The thing with a code smell is that it’s not a hard and fast rule, it’s just a hint that something could be wrong. Sometimes it can be reasonable for a class to do “too much,” it depends on the exact thing you’re trying to accomplish and the context (i.e. the rest of your application) that your class is part of. Having a good design is more about the thing you’re trying to accomplish than it is about following all the rules whether or not they make sense in your particular situation.

The great thing about code smells and design patterns and all that is that they let you take advantage of other people’s experience. Can you imagine how long it would take to get good at software design if you had to make all the mistakes yourself? I love hearing what other people have messed up so I can maybe avoid that particular problem. And from the other side, I’d love it if anything I’ve told another dev helped them avoid a problem. It’s all well and good if I solve a problem for myself, but if I can help a couple of people avoid the problem in the first place and if those people help a couple other people avoid that problem, then I’ve done much more good than if I quietly fixed my own code and moved on.

Stay tuned for more posts about code smells, there are plenty of them to get through :)

Let the computer do it for you

in best practices, development, tools

Loosely related image from pexels.com to make this post look nicer in social media shares.

Many years ago when I was in college, a friend taught me something that’s been really useful for my whole career. That lesson was to let the computer do it for you. Unless there’s a compelling reason to do things the hard way, just let the computer make things easier for you.

Learning lisp? Get a plugin for your text editor or a simple IDE like Dr Racket that matches your parens for you.

Working with fixed width files? Get Record Editor, it’ll save you so much time!

Fighting with javascript? Get WebStorm! Seriously, it’s freaking amazing.

If you have to do something tedious and fiddly, get the computer to help you. That’s what it’s good at. There is a tool out there that will make your life easier, you just have to go and look for it. The hard part is remembering to go look for it :)

It’s normal to think that if there was a tool you could use your teacher or your boss or someone on your team would have told you about it, but thinking to look for tools like that is surprisingly unusual. And to be fair, it can be a real timesink to try tool after tool just to find out none of them are better than what you’re already using.

That said, if someone on your team hasn’t already told you that they’ve tried everything they could find (and searched for tools recently), it’s worth doing at least a little Googling and seeing if there’s already a tool that would make your life easier. Other people use lisp, you can safely assume there are tools out there for it. Other people use fixed width files, you can safely assume there are tools for those too. And tons of other people use javascript, tools for that are getting better all the time.

If there isn’t already a tool, you might be able to build one. That’s exactly what bash or powershell scripting is for – fiddly things that humans are bad at and tedious but simple things that humans just don’t wanna do. If you’ve ever run a build script, you’ve used a custom tool that someone wrote to automate building your application so it gets done the exact same way every single time. No matter what OS you’re running, there will be other scripts out on the internet that you can take apart to build your own custom tools.

Whether you find tools or build your own, remember that boring stuff is the computer’s job!

Link of the day

in becoming a better programmer, best practices, career, link of the day

Julia Evans has a great guide to asking good questions, you should read it :) Asking good questions is such a useful skill, I wish programming education spent more time on it.

Getting really good at asking questions is also a great hack for looking like a better developer (it’ll also help you actually become better, but in the short term it’s a good hack). When you ask a bad question, like “My code isn’t working, can you help me?” people have to wonder what you’ve tried already or if you tried at all before giving up and asking someone else. If you ask the exact same question with more detail, especially about what you tried already, like “I’m trying to send an email but I’m getting an error message I don’t understand. I tried googling it but I got a bunch of different answers and I don’t know which one applies to my problem. Can you help me sort through them?” then it’s obvious that not only did you not immediately give up, but you also respect your answerer’s time enough to make it as easy as possible for them to help you. Telling them what you’ve tried already means they can skip suggesting things you already did, and asking a specific question means they don’t have to do the work of figuring out what the question actually is before they can even start thinking about how to answer it.

People love it when you make things easier for them, and when you show them you’ve put some effort into doing so, they’ll think you’re a better programmer than the person who makes getting the real question out of them like pulling teeth even if both of you are around the same skill level. That’s the hack part :) The becoming a better programmer part is that stating a question really clearly (yay rubber ducks!) and listing everything you’ve tried already may trigger that flash of insight about what you haven’t tried but should or what assumption you made that could be wrong. If you get into the habit of reflecting on what you’re doing, you’ll learn a lot faster than someome who sits around and waits for help.

Be a better programmer while still having a life: part 5

in becoming a better programmer, best practices, career, development

Unrelated image from pexels.com to make this post look nicer in social media shares.

Today’s tip for becoming a better programmer while still having a life isn’t just good for you, it’s good for your whole team. That tip is documentation.

I know, nobody actually likes doing documentation. Fortunately, I’m not talking about dry design docs or endless specifications, I’m talking about a simple wiki (or whatever works for you), written by you and your team for you and your team. It doesn’t have to be polished, it doesn’t have to be formal, it doesn’t even have to be spelled perfectly. All it needs to be is correct and understandable. The idea is to explain things just like you would to another dev on your team, not to waste hours proofreading.

Great, but what should you document? In short, anything you’re going to want to know later. Especially useful things to write down are why architectural decisions were made, how parts of the system work at a high level, guides to testing certain features (great for complicated payment provider integrations, not that I’ve been fighting with those), and especially guides to setting up your development environment, whatever that thing is that you forget every time and have to look up again or ask someone about.

Just saving yourself time relearning parts of your codebase will help you get things done faster, which is basically being a better programmer, but explaining things (even if you’re writing to yourself) helps you understand them better. Explaining something forces you to think about every little detail, and putting something in your own words helps it stick in your brain – it’s the same principle that helps you remember things better when you take notes on them, whether or not you ever look at those notes. The better you understand your codebase, the better decisions you can make about how to add new features or fix bugs.

As a bonus, reflecting on why you made certain decisions and being able to go back later and see if the reason you did things the way you did holds up over time also makes you a better developer. You don’t even need to make a special effort to do this, if code gets used it gets changed. All you need to do is wait, eventually you will have to revisit the code you documented and by the time you do that, you will probably have forgotten the details and will need to go look it up in that handy wiki you created :)

Writing things down also helps you get that answer again without interrupting anyone, and the less you can interrupt teammates the better considering how expensive interruptions are for programmers. I couldn’t find a hard number, but I feel comfortable saying that it takes at least ten minutes to get back into a complex task like programming once you’ve been interrupted. It can be even worse if you get interrupted at just the wrong time. I have a terrible time getting into a task when I know I’ll have to stop soon for a meeting or appointment or whatever, which means an unfortunately timed interruption can kill a solid half hour of productivity even if it only took a couple of minutes to deal with the interruption itself.

All the benefits you get from making knowledge about your code available and searchable also apply to your teammates. If you just document how to set up your development environment, that can save hours every time someone has to set up their environment whether it’s a new employee starting or a long time employee getting a shiny new computer to replace an old one. It’s even better for everyone around you if the whole writing things down idea catches on – then they also get the benefits of explaining things and documenting the particular things they forget and need to look up as well.

And best of all, this is another work thing you can do at work that has no effect on your personal time.

Be a better programmer while still having a life: part 4

in becoming a better programmer, best practices, career, development

Unrelated image from pexels.com to make this post look nicer in social media shares and because red pandas are adorable.

As much as we would all like to believe that programming is about logic, not feelings, being able to deal with your emotions is incredibly important if you want to be a better programmer. For example, one of the best things you can possibly do for you career is to learn to take criticism. Logically everyone should be thrilled to get feedback on their work but you know what gets in the way? Yep, it’s emotions.

It can suck to hear all about what’s wrong with your code, especially if you worked really hard on it and thought that this time you finally got it right. Hearing about what you need to improve is incredibly helpful (who has time to make every possible mistake on their own? that would take forever!), but that doesn’t mean it never hurts your feelings. And when people’s feelings are hurt, it’s really hard for them to listen. Sometimes emotions get in the way of your improvement as a developer.

So how do you learn to take feedback even when it hurts?

First of all, you’ve got to accept that it’s normal to have feelings about being told that your code isn’t good enough. There’s no fixing a problem that you can’t admit is happening, after all. That absolutely does not mean you should be ashamed of having feelings – not only is it just plain wrong to shame anyone, including yourself, for being human, but it’s a huge waste of time. All it means is that if your feelings are keeping you from being able to take feedback, you’ve got to get a handle on them. You would debug a program that couldn’t handle certain inputs, right? Sometimes your mind needs debugging too.

One way to do that is to remind yourself that feelings aren’t facts. Just because you feel attacked or like everything you do is stupid and terrible and you’re never going to be any good at this and should just crawl into a hole doesn’t make it true. That’s just your brain freaking out, if you give it a minute it will calm down. Yes, it sucks in the moment to hear that your code needs work, but you’re going to feel fine tomorrow. With practice, you’ll get used to hearing what you can improve and start skipping the boring angsting step to go directly to fixing things.

A common thing programmers do that makes that way harder is to get really really really attached to their code. You should absolutely care about whether you’re doing a good job but you’ve got to remember that your code is not you. The quality of your code has nothing to do with your worth as a human being and any one piece of code doesn’t even mean much of anything about your skills as a programmer. Everyone has off days, making a mistake does not mean you’re a bad programmer, will always be a bad programmer and should just go find a hole to crawl into. Everybody makes mistakes, you’re not that special ;)

Quick side note: code reviews are never supposed to be mean. Aside from being a tremendous dick move and thoroughly unprofessional, it’s a waste of time to be a jerk when you’re giving feedback. If people hate doing code reviews they will find ways to not do them and the quality of code on your project will suffer. If you can’t be nice because it’s right, be nice because it’s effective. And if your team lead/senior dev/whoever does your reviews can’t at least be civil, find a new job. Life is too short to put up with dicks.

Something else you can remind yourself about when you’re having feelings about a code review is that nobody gives advice to people they don’t believe can do better. If you believe someone can’t learn you don’t bother giving them a code review, you quietly fix what you can while they’re not looking and hope they eventually get fired. Bothering to give someone feedback is a statement that they’re worth the effort.

The most important piece of advice I can give you, though, is that you need to be able to take a step back both from your feelings. Meditation is great for this, by the way. I’m going to steal Headspace’s traffic metaphor here because it’s really good: training your mind isn’t about forcibly clearing it, it’s about learning to watch your thoughts and feelings go by like cars on the road and not needing to run out into the street and direct traffic. Having a feeling doesn’t mean you have to do something about it right then, you can wait a bit and see if it’s still important.

That stepping back thing is useful for more than just code reviews, too. Professional software development can be really frustrating for reasons that have nothing to do with writing code. Features get changed or cut, projects get dropped, companies change direction, sometimes things never make it into production no matter how much you believe in them or how hard you try. If you can’t step back from your attachment to a project and accept that things don’t always go the way you wish they would or even the way they logically ought to, you’re going to have a bad time in this field (or any other for that matter).

While you’re at it, literally step away from the computer now and then and do something else. Not only can you become a better programmer and still have a life, but having a life will make you a better programmer. Nerds tend to hyperfocus, which is great when you have a concrete task to get done but not quite as great when you lose all sense of perspective because you do nothing but code all day. Having other things you’re good at and other things to look forward to really helps put that one bad code review into perspective.