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…
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.
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…
I remember when I first told my team lead about possibly going back to school. He simply replied, “You don’t need it.” and moved on.
I then remember talking to People Services at my company about what it would look like to get my degree part-time while working. They agreed to discuss it, but they didn’t think I would actually follow through on anything. “Let us know when you get into a program. We can talk about it further then.”
When I did get accepted into a program, my manager gave me a baffled look. He was confused. “You really…
Every year I try to take a short inventory of the books I read through that year. I find that doing so helps me solidify the concrete things I learned from each. You can see last year’s list too if you would like.
Let’s jump right in.
One of the classics, Crime and Punishment takes us through the minds of several Russians in St. Petersburg following a brutal murder. We explore the psychological and relational consequences of murder, the motivations for it, and how society plays into all of it. …
Jesus follower | husband | IJM advocate | software engineer. I share tips and tools for building great software as a team.