Hero image by Comfreak from Pixabay

You know the feeling. You’ve worked on this thing for weeks — much longer than anticipated.

You have faced unexpected complications.

You have struggled with bad documentation.

You had to implement functionality yourself that you thought the framework provided out of the box.

But now you’re done, despite all those challenges. You feel real accomplishment. You feel like a hero (even though you would never say it out loud). Now, all you want to do is to ship it. Other things had to wait and are piling up.

But, hey, it’s review time, and your reviewers won’t let you ship it. Instead, they have lots of well-meaning suggestions:

This function here does too much and should be refactored.

The interface of this subsystem feels a bit clumsy. Can it be simplified?

This new library that you are introducing here adds 50 KB of weight to the page. Is this really necessary?

This module should have some tests for edge case X.

Aaaaahhhhhrrrggghhh! Isn’t this just an ungrateful bunch of colleagues! Do they even know how much effort, thinking, and suffering went into this piece of work? And now they come along, with their nit-picky concerns, piling more work on top of you and delaying the arrival of this huge value-add?

Ok, let’s take a deep breath. Easy, now. Breathe in. Breathe out.

Image by Dean Moriarty from Pixabay

I know: It is sometimes tempting to think this way.

But in most cases, it’s also wrong.

Because, think about it this way: These people are doing you a favour. They hold you accountable to deliver high-quality work. They make sure that your “huge value-add” adds even more value. They see things that you have become blind to. They can save you from shipping the wrong abstraction, which would have become tomorrow’s technical debt. Or, from delivering a clumsy interface that could be much simpler, thus increasing the productivity of everyone and adding to your reputation. Yes, your reputation.

Array problems

I once created a Prettier plugin for Twig, which included an option to specify a set of directories. Naturally, these directories should have been specified as an array, like so:

{
    "plugins": ["path/to/A", "path/to/B", "path/to/C"]
}

Because, at that time, the documentation for Prettier plugin development was not exactly great, I could not figure out how to declare an option with an array type. At some point, I gave up, used a string separated by the pipe symbol, and moved on. The same setting would then look like this:

{
    "plugins": "path/to/A|path/to/B|path/to/C"
}

Not pretty, but it worked for the moment, and I had more interesting problems to solve.

Weeks later, after having been working on the project for four months in my spare time, I presented my work to some co-workers. And, of course, the weird pipe-separated string topic came up. “Would that not be easier to specify as an array?”

My gut reaction was, of course: “Why, thank you, Captain Obvious!”

However, this reminded me of the issue, and how much of a flaw it was. I had even seen it coming, but I needed it spelled out to take action.

Later that day, I did some more digging through the Prettier code base. I found out which library was responsible for the option declarations (it’s cosmiconfig, in case you’re wondering). I researched some more, and I finally found an example demonstrating how to define array options.

By changing a couple of lines of code, I was able to drastically improve the quality and usability of my plugin. This strange parameter definition with its non-intuitive special syntax that had always stuck out like a sore thumb — it was gone, just like that, and I was happy.

And I realized: If my colleagues had not made me aware of it once again, I would probably not have made another effort to solve this.

The takeaway for me was: Ask others to review your work and hold you accountable. They are doing you a favour, so accept that present. And don’t forget to return it when the time comes.

Photo by Kira auf der Heide on Unsplash

Decisions

As a developer, you make hundreds of small decisions while working on a code base.

Should I extract this into a function? What is a good variable name here? Are these types similar enough to use only one of them?

If one decision takes too long, it will block you. Maybe you cannot find a good solution, so you settle for a suboptimal one. Maybe you tell yourself that it’s only temporary. Next, you start telling yourself that it’s not so bad, that it’s something people could surely live with. And this is when you need others to give you that final little push.

I’m not saying that you will like it. You will experience resistance, because it means more work for you, and more delay, when you already thought you were almost done. Sometimes, a considerable amount of work.

However, this moment is an opportunity. It is an opportunity to grow, to set your standards higher, to train your willpower, and to deliver excellent quality instead of just good quality.

If you use this opportunity regularly, it will make a big difference over time.