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…
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.
For several years, all I heard about was Ansible. It was going to solve every one of your deployment problems. It was going to make life easier. Heck, it was going to take us to Mars — well as long as SpaceX used it…
But after a short while, Ansible seemed to fall flat. As the infrastructure-as-code movement grew and the immutable infrastructure alongside it, other tools seemed to overtake Ansible. I stopped learning it at this point since I started work on Kubernetes-based applications, which fully embraced immutable infrastructure.
Recently, however, I’ve been working on some applications that use…
A few weeks ago I shared about Why I got My Master’s Degree in Computer Science. I went into depth about my background, story, and even my planning process.
Today, I want to answer the question of if I think my degree was worth it.
To do that, I decided to break it down into my Top Five Takeaways. These are my top lessons, learnings, and skills that getting my master’s degree taught me and why I think my degree was worth it.
Learning is a subject I’m very passionate about actually. In my undergraduate days, I minored in cognitive…
Jesus follower | husband | IJM advocate | software engineer. I share tips and tools for building great software as a team.