Tag: feedback

Don’t Shit on Someone Else’s Work

Dear new developer,

There will come a time when you are looking at a system and trying to understand the choices behind it. You may be looking at a particular class, a subsystem, or a more fundamental choice, like the language or the system architecture.

And you’ll wonder what the hell the initial implementer was thinking. You’ll wonder why this system is still in production. You’ll wonder why someone didn’t fix this.

You will be tempted to trash talk this piece of work to your colleagues.

Don’t do this.

Why?

It’s not helpful. Now, it’s perfectly acceptable to point out issues and ask questions about why choices were made. It’s a good idea to suggest improvements, whether those be code changes, removal or replacement of portions of the system or something else. But complaining about the existing system doesn’t do any of that. It’s just complaining.

It displays a lack of empathy. Chance are you don’t know the constraints and pressures that the original implementer and past maintainers faced. Making judgements based on code without knowing the constraints is like hiring someone based on the color of their shirt–you just don’t have all the information needed.

Trust me, in the future you’ll face constraints, like lack of knowledge, time or labor or money, that will cause you to make choices that are suboptimal. At least once in my career I’ve come across a boneheaded piece of code. Cursing under my breath, I wondered “who wrote this crap?”. As I pulled up the commit log, my face fell as I realized that I had. Doh!

(What should you do if the code or system doesn’t work at all? In that case, the questions about constraints and understanding how a failed system was built are even more important. But again, complaining doesn’t help anyone at all.)

In short, when you are working in a codebase and trash talk it, you are the critic, not the man in the arena.

Sincerely,

Dan

Patterns for managing up

Dear new developer,

Design patterns are common ways to implement solutions that can be repurposed across different systems and domains. This post proposes patterns for handling organizational situations.

Some really good excerpts:

No matter how amazing you are at your job, you will sometimes get feedback about things you could be doing better. It can be difficult to hear, especially if you are someone who works really hard all the time. When it comes to negative feedback, it is important to reframe the conversation. Feedback isn’t a bad thing. It is a gift, and you should always adopt a growth mindset and see it as a chance to improve.

I have received negative feedback about how I managed (I was managing how I would want to be managed, not how the employee wanted to be managed). It was really good to hear because it let me improve, but I definitely had to hold down a “wait a minute, you don’t understand” thought. If I hadn’t, I would have both lost that opportunity to learn, and possibly many more. If you react negatively to feedback often enough, people will decide that it isn’t worth giving to you.

And this is a good one too, about how to handle a problem you created:

When problems occur, there is a natural instinct to hide or deny that the problem is a problem, or that it is even happening at all. We want to minimize the problems that are our responsibility because, after all, a big part of our job is to make sure problems don’t happen. When you are proactive about sharing and fixing a problem, however, it is actually an opportunity to show you are an asset to the bosses.

Going to a boss and saying “I screwed up” is terrifying, especially the first time you do it. But going to the boss and saying “I screwed up and this is how I am going to both fix it now and make sure it doesn’t happen in the future” is terrifying but empowering too. The other alternative is to just hope that you are never found out, which is a miserable way to work (who wants to hide things? what happens if the problem gets bigger?). If you screw up, take a deep breath, come up with a plan, and solve the issue.

The whole article is worth a read.

Sincerely,

Dan