My views have been mainly shaped by my experience with a particular kind of code review — the pull request. Like many devs, I’ve grown accustomed to the pull request model to help facilitate reviews. While it isn’t perfect, I’ve always found it to be a great tool and overall an improvement to formal code review processes or reviews over email.
Learning patterns has become a core aspect for many people on their journey to becoming software engineers. Countless articles have been written about patterns and how to apply them. Courses, YouTube videos, and GitHub repos all exist to help engineers master the power of patterns. I’ve even written about patterns before myself.
As a senior engineer, however, I’ve started to wonder if we went in the wrong direction with patterns.
The more code I write, the more I use the same patterns and the less I care about the others. I don’t memorize them or even have a page bookmarked…
Writing simple code has become something of an obsession for me.
I find myself trying to simplify any and every piece of code I write. I often add comments on pull requests that we don’t need to complicate things or plan too far ahead; the existing code is simple enough to maintain. Why use a pattern if the current code just needs a
switch statement? If you need to change it later, you will.
Did I just lose all of the clean coders? I thought so.
👋 Hi there! This article is a response to some comments and critiques on a previous article — I’m Changing How I Review Code. These comments and critiques raised some great questions that I’ve spent some time thinking about. I hope I’ve put together a reasonable and seasoned response and one that inspires software teams to think and work together! Let’s dive in.
Trust is a complicated topic.
Some might disagree with that. They might say trust is simple: you trust someone, or you don’t. …
The software industry is chaotic.
To the gurus that might say, “follow steps a, b, and c, and you’ll achieve a zen-like world where everything is always easy,” I would node, grin (an impish one), and politely disagree with them.
Even the best team’s in the world deal with chaos. It isn’t the absence of chaos that makes them great but how they respond and adapt to it. They find ways to wrangle the chaos into something manageable rather than running away from it.
But what is the chaos I’m talking about?
Chaos is trying to keeping straight who is…
We all have that one friend. That friend who will is just a little too smart for their own good. That friend who is always trying to “hack” things or systems or games.
Instead of trying to learn and understand whatever they are presented with, they try to outsmart it. From the first moment, they are trying to find a loophole in the rules. They are trying to find the trick that will ultimately allow them to out-maneuver the rest of the competition.
I saw this happen firsthand a few weeks ago. I was playing a social deception game in…
Like most complex work, the software industry is full of overloaded or ambiguous terminology. Teams or companies can often create unique definitions of their own for terms like service, integration test, or even quality assurance to match how their teams work.
That is all well and fine as long as the teams agree on the definition and work hard to make sure each definition is easily discoverable. I.e., new team members should be able to find and learn these new definitions (and challenge them too!) so that the team stays in sync.
Sadly, this is hard to do. Every person…
Communication is hard. We all know that.
What makes communication even harder is when we use terms that have or phrases that might mean different things to different people. Whenever two or more people are trying to communicate, and everyone brings their own interpretation to the table, it becomes complex. This is especially pronounced with temporal things around scheduling or “new”/”old.”
Let me illustrate with an example conversation:
On a Sunday morning…
Jennifer: “Hey! Want to get lunch next week?”
Samantha: “Sure! I’m free tomorrow!”
Jennifer: “I can’t tomorrow — I meant next week, not this week…”
While the above…
There are many — many — analogies to writing software.
Building a building. Creating a city. Trying to change the tires of a car while driving.
None are perfect, but they each help convey an idea about the complex work that is writing software. There are many factors to consider, an ever-changing set of requirements, and needs to be met. Plus, once you build software, you usually don’t demo it and start over — even though sometimes that is the only thing you can do.
I want to add another analogy: growing a garden.
Full disclosure, I’m new to gardening…
It was around two years ago that I decided I wanted to start blogging more consistently. I had written a few articles on Medium, but I didn’t have any readers at the time. I was just writing into the void.
Since then, I’ve published 50 articles on Medium, moved my writing to my own domain built with Gatsby.js, and started cross-posting to dev.to. I haven’t had the viral success that many bloggers talk about — I’ve got a lot to learn about SEO and good copywriting — but I have seen some success that keeps me coming back.