DEV Community: Dan Goslen

The Problem With Feedback - It's Hard to Listen To

Dan Goslen — Sat, 10 Dec 2022 13:00:00 +0000

The day is August 18th, 1969. A dwindling crowd remains after an endless night of music at a farm outside Bethel, New York. After a long and full lineup of music all weekend long, only one artist is left to play at Woodstock.

Jimi Hendrix and his band began playing somewhere around 8:30 that morning. They played some of his hits with added space room for improvisation and general jamming.

But what most people remember about this set wasn't one of his hits. It was a rendition of the Star Spangled Banner.

In his version of the US national anthem, Hendrix utilized something known as feedback. Feedback is when some fraction of a signal from some output is fed back into part of the input of that signal. When it happens in a musical or audio setting, it often creates deafening shrieks and unpleasant sounds, sending hearers to cover their ears and yell at an unknown person, "turn it off!".

When Hendrix used feedback, though, it was intentional, and it was part of the melody and part of the timbre. He used feedback as a tool rather than something he had to work around or avoid.

But it's a delicate balance between using feedback to create music and creating a cacophony of screeches. Even when a guitarist uses feedback creatively, as a listener you still have to learn that it's intended to sound that way. It's still hard to listen to. There is always that inclination to wonder, "is this correct?" and start looking around to make sure the guitarist on stage or the AV guy in the back doesn't look frustrated about what is happening.

The same is true for feedback workplaces, and teams. Feedback can be hard to listen to.

It's Often Loud

Have you ever been in a packed room where everyone is talking? Everyone keeps getting louder and louder, trying to talk over everyone else. Before long, no one can hear anyone anymore, and people start to leave. Even if you went to see your favorite band play your favorite song, it wouldn't sound good if the volume was too loud.

Feedback can be the same; it's often hard to hear because it's "loud." Direct feedback - even when true - can be too much to hear. We'd rather put our hands over our ears and walk out the door.

If we want to hear the feedback, we might have to listen to it through ear muffs. Not full-blown noise-canceling headphones per se, but something to help turn down the volume.

Of course, we can't put literal headphones in our next one-on-one or performance review. So how do we turn down the volume? How do we make it easier to listen to? Everyone is different, but here are a few strategies that have helped me:

Ask for written feedback instead of just having a conversation. While written feedback might not work for you, having a written set of feedback delivered an hour or so before any formal conversations helps me process it. I can respond more easily than react to it after reading it a few times. This is especially helpful for performance reviews or formal check-ins.
Be willing to say you need more time to before hearing feedback. If someone wants to offer you feedback about a meeting or situation before you are ready, say so. Not everyone will do this, but many ask, "Can I give you some feedback?" A valid answer to that question is, "Not right now." Admitting I'm not ready to hear feedback gives me the time to compose myself (if needed) and process the situation on my own ahead of time.
Focus on hearing the feedback first and processing later. Instead of trying to react or respond in a conversation, I'll focus on listening to what the other person has to say, writing it down, and processing it later. Even if I'm asked, "What do you think about that?" I'll often say, "I'm not sure right now, but I'll get back to you."

It's Often Out of Tune

If you listen to Hendrix's Star Spangled Banner, the feedback pushes and pulls the notes out of tune. As the speakers blast more and more sound, the guitar strings start to vibrate from the speakers rather than from being plucked. New octaves and harmonic frequencies begin to emerge. And it can often sound unsettling. And then there is the intentional note bending and neck warping, making it all difficult for the untrained ear to listen to.

All this to say that feedback can be "off." A detail about work you have accomplished might get overlooked or amplified more than you think is right, or someone might mischaracterize your intentions. In any case, you feel that you're getting feedback this isn't accurate or trustworthy.

When this happens, it is essential to remember that delivering feedback can be as challenging as receiving it. It is unlikely the person giving you feedback is intentionally misrepresenting something. When appropriate, ask if you can correct them or provide more context around a particular circumstance. Practice responding vs. reacting here too.

An additional tool is to find something to agree on before offering further context or correction. It's sometimes referred to as the "yes, and" rule. By affirming something true about the feedback and adding to it, we welcome collaboration and working together towards the truth or the goal rather than trying to figure out who is right and wrong.

This tool is especially helpful for delivering feedback during code reviews. If we have feedback around an implementation that might be slow or could be improved in some way, start our feedback with a positive agreement ("This will work") and then follow it up with our feedback ("and we could improve it this way"). By initially agreeing that that existing implementation works, we can move more towards feedback around building something better vs. getting caught in a battle about right vs. wrong.

There are times, however, when we do need to correct something that was clearly incorrect or when someone is disregarding important facts. In my experience, this happens less than it might seem. Learning how to leverage the "yes, and" rule can be helpful in tense moments when something is slightly out of tune to keep things on track.

Delivering Feedback is Hard to Master

Just like creating feedback on a guitar is difficult, delivering performance feedback is difficult to master. Even the most well-intending manager or colleague might say something the wrong way or at the wrong time for it to be helpful. This makes it difficult to receive as the other person isn't perfect.

There are many posts on how to deliver feedback (including my own), but you can't assume that everyone has read them. We can't walk in expecting the feedback deliverer to be an expert - though it would be much easier if we could! Instead, we must remember everyone is working it out in real time.

It's like going to see a high school garage band concert. We know what everyone is trying to do, and we hear the places there are pretty close, but we also recognize it's still just high school. Their skills aren't there yet.

Of course, if you are receiving feedback from someone who isn't working to be kind, humble, and objective in their feedback, it can be frustrating. I'm not saying we excuse that behavior. But if someone is trying to do those things, let's lean in rather than pull away. Work to see through the fumbled delivery if you can. Then be ready and willing to deliver feedback to the deliverer on how they could improve their delivery.

TL;DR: feedback is difficult to hear. And while I'm just a software engineer writing about my own experience, we can learn how to hear feedback better by being aware that it is often loud, somewhat out of tune, and difficult to deliver.

It will always be difficult to hear negative feedback, but we can learn to hear through the noise and even find the parts that will help us learn and grow.

Happy coding!

Be Willing to Change Your Mind

Dan Goslen — Fri, 25 Nov 2022 13:00:00 +0000

I heard something not too long ago that stopped me in my tracks. I was listening to a podcast while doing some yard work. The guest on the show was an author who had recently unpublished a book of theirs, citing it has caused more damage than good. They had come to realize their stance on an issue was wrong.

The host said something profound. "You changed your mind!" she exclaimed. "Do you know how rare that is today?"

It's true. Humans are often unwilling to change their minds on many things. We get entrenched in our opinions often without being open or willing to listen to another perspective.
Unfortunately, software engineers are some of the least likely people to change their minds; I've been one of them. We learn to think so critically and deeply about complex ideas that it is hard to shift them once we make our conclusions.

However, growth and learning are often predicated on being willing to change - or at least morph - our understanding of the world. We will only learn if we are willing to change and challenge our current mental models.

Why Don't We Change Our Minds?

If changing our minds is foundational to learning and growth, why are we so resistant to it? I think there are a few reasons.

First, engineers have subtly been trained not to do so. Our industry has long touted the phrase "strong opinions loosely held" which has enforced the need for engineers to create a strong opinion - even on things they don't care about. It sounds good at first, but it often becomes a way for engineers to use passion and intensity as a means to get their idea accepted, regardless of whether it's the best idea in the room. The louder you are, the more right you must be.

Second, changing our minds often feels like admitting were aren't good enough. Putting our own idea down to prefer someone else's idea feels embarrassing. We start to think we can't cut it as an engineer. It's imposter syndrome all over again.

Last, we are afraid that changing our minds means we are weak leaders. We are worried that if we admit we were wrong about something, we will lose our credibility or following (as if we had one anyway). Or perhaps we fall prey to the sunk cost fallacy touting that "we've already come this far." Leaders are often more willing to ruin their culture and credibility rather than admit they were wrong about something and then course correct.
These are legitimate concerns, to be fair. It is challenging to admit being wrong or to be willing to take a fresh perspective on something. To learn, though, we have to be willing to do so.

Toolboxes vs. Multi-tools

One way I've become more willing to change my mind is by focusing on collecting tools for my toolbox rather than trying to find the perfect multi-tool.

There are many different tools in a toolbox, each with unique capabilities. Almost every time I've needed to build something (outside of an Ikea shelf), I need several of those tools in the box. If I was missing just one of those tools, I wouldn't be able to finish the task.

The same thing happens in software. Knowing different languages, patterns, and processes will allow teams to find the right solutions for their problems. Teams should be collecting tools rather than trying to find a perfect one-size-fits-all approach.

However, I focused on doing just that for a long time. Instead of collecting tools, I tried to find the perfect multi-tool to do everything. I thought I would have all I needed if I could only find one with a sharp enough knife and the correct combination of screwdriver widgets.

The problem was I kept coming up short with every "multi-tool" I bought. No process was perfect, and no pattern would fit every scenario. But still, I kept looking for the fabled ideal solution.
I also noticed that even though I knew these tools were coming up short, I would quickly defend them. I had sunk so much time into picking the "perfect multi-tool" that I was much more zealous in defending it, which is silly if you think about it.

By building a toolbox, I'm more willing to put down a tool that isn't working in favor of another. I'm also much more willing to replace or supplement my existing tools with new ones rather than searching for a singular perfect tool to replace my entire toolbox.

Good, Better, and Best

Another helpful way I've been rethinking how and when to change my mind is by remembering that not everything is a right or wrong decision. Many ideas fall along a spectrum of good, better, and best.

This is especially true in software engineer. We often have an array of options to choose from when faced with a problem. The solutions we come up with are rarely entirely wrong, but there will likely be better ideas too. There will also be worse ideas, but even those ideas aren't wrong either.

If we approach these decisions with a mindset of right vs. wrong, we are likely to miss the best solution. We'll be so focused on defending our idea that we won't listen to other solutions - even when they are extensions of our own idea!

This happened to me not too long ago. I had spent a lot of time thinking about a solution to a problem, and I was optimistic it would work really well. During a design session, one of my teammates threw out an idea that was pretty aligned with what I had thought about already, but I was so convinced I was right that I didn't pay attention. It wasn't until the next day that I realized, "oh, that is a much better idea!" 🤦

Let's practice willingness to change our minds. Let's bring humility to the table when discussing trade-offs with our teams. We don't have to change our minds on everything either. When you have an idea worth advocating for, advocate, for it!

The point is we need to be willing to. We must be reflective and humble enough to question our conclusions and opinions. We need to let go of bravado and be willing to come to the table admitting we were wrong about something. It takes strength to do those things.
But we won't reach our full potential until we do.

Happy coding!

The Importance of Vision as a Developer

Dan Goslen — Fri, 18 Feb 2022 19:27:43 +0000

Fixer Upper. We all love it. Even if you hate it… you still kinda love it.

If you are unfamiliar with the show (living under a rock?), Chip and Joanna Gaines help prospective homeowners build their dream homes by finding cheaper “fixer-upper” homes and remodeling them, saving the homebuyer’s money. The process is called house-flipping, and it has become an enormous phenomenon - especially here in the US.

But how can someone take a house in shambles and turn it into a dream home? How do they avoid getting stuck while remodeling and throwing in the towel?

Many qualities are required; persistence, skill, sacrifice, etc.

But there is one quality that is neccesary. One thing that is the predictor for success or failure.

That difference is vision.

What is Vision?

Simply put pision is the ability to see. In the creative context, vision is the ability to see how things could be. The ability to grasp a different perspective unique to everyone else. The ability to imagine a different world than the current reality.

This is why we call visionaries, well, visionary. They can envision things no one else can. And the household names we remember are the ones who had vision and the ability to bring it to fruition: Bell, Edison, Earheart, Jobs, etc.

But it all starts with vision.

Why is Vision So Important?

Why is vision so important? Isn’t it just the same as having a goal or plan?

I’d argue that true vision comes before creating goals or laying out a plan. Vision is something more significant. A vision says, “We can do something different. We can change how the world works. We don’t have to accept the status quo.”

A strong vision is more immersive than a goal or a plan. It might be so grand that a single goal can’t contain it. It might be so hard to articulate that no plan seems to accommodate all of the complexity to make it happen. A vision is more like a guidebook, helping you choose plans, steps, and goals to realize the vision you have.

Many successful athletes and actors talk about picturing themselves getting the medal or landing the role. Climbers or runners describe what it will feel like to send the summit or cross the finish line. House-flippers and creatives can talk about the potential they see in an old house or a blank canvas in exquisite detail.

Vision like this acts as both a direction and a motivator. It sets the course for where you are going and provides enough tangibility to something distant in the future to keep you motivated.

Vision in Development

If that sounds like a bit of mumble-jumbo self-help garbage to you, stay with me just a little bit longer. Vision isn’t just about achieving your dreams of changing the world. It’s also crucial for building anything significant or complex - like software.

Let’s go back to house-flipping for a second. If you bought a house with the goal of flipping it for profit, you might get stuck halfway confused about what to do, how to do it, and what direction to focus your energy. You might have been so focused on the goal of making money that you forgot to see what was possible - and if it would be profitable. Even if you did have a thought-out detailed plan, you might run into a roadblock and realize that your perfect plan wasn’t so perfect after all.

But vision is different. Bringing a vision to fruition can still be possible, even if the concrete plan changes frequently. In software, vision is critical for that exact reason: plans and goals can change quickly, but we still need a motivator for technical excellence and a direction to march towards.

An excellent technical vision describes how developers feel when writing code and the ease with which they can monitor their software. It explains how teams work together and the breadcrumbs they leave along the way to make the path clear for the next team. How people feel working on the engineering team and how they feel supported by management might be included too.

Vision can also be micro. A senior engineer might have a vision for how a particular codebase is organized. They might describe the reliability of their service or how easy it is to be on-call for that service because it rarely goes down. They might even discuss the throughput they think is possible to supercharge the business.

Creating a Vision

If you’re still here, the next logical question is, of course: how do you create a vision?

While there is a lot to explore in the answer - much of which can’t be covered in this article - there are a few key things to cover. The most important aspect is found in answering two primary questions:

What will the future feel like when your vision is achieved?
How will things be different from today?
Be as detailed as possible. Don’t say, “Work will be easier.” Say, “Work will be easier to accomplish because our codebase is easy to understand, and we have tests to identify when we’ve broken functionality.”

When you have this level of detail, it paints a more vivid and clear picture of where you want to go. A stick-figure picture of a mountain is much less compelling than a painting of a mountain with color and dimension. Create the painting.

Gaining Buy-in

The hardest part of a vision is articulating it to others to gain buy-in. You will likely need their support, especially in the world of software where teams own software and not individuals.

How do you gain that buy-in?

The power comes from being able to articulate the vision in your head in a compelling way to others. This is another reason why having an extremely clear vision is so important. The more detailed and clear your vision is, the easier it will be to describe to others.

Naturally, some will disagree with your vision. Others might hear it and be impartial; they don’t hate it, but they don’t like it either. But other will get it and buy-in. As more buy-in, it becomes easier to gain more since everyone wants to be part of a movement of some kind (even if it’s small).

Keep talking to your team or fellow leaders about how you think things can be different how your vision can take your team to the next level. Practice humility, of course, but don’t be shy either. As Andy Hunt and Dave Thomas remind us in Pragmatic Programmers, the best idea is worthless if no one knows about it.

Building great software and great teams requires a vision for the future. One that elevates the current reality into a better one. And while goals and plans are great, having a foundational vision of what that world looks like in the future will help you stay motivated, navigate changes, and create buy-in along the way.

If you are a leader (or becoming one) in your software team, take an inventory of the current work environment. Take a look at how teams operate and how work flows through your organization. Identify a few things that could be better and imagine what it would be like if none of those issues existed anymore. What would that world be like?

Write it down, make it abundantly clear, and start working towards it.

Happy coding!

Cover photo by Matt Noble on Unsplash

How to Get Software Documentation Right

Dan Goslen — Wed, 26 Jan 2022 15:59:58 +0000

I recently joined a new team. An entirely new company actually. I’m now an engineer working for Policygenius - the leading online insurance marketplace (in the US at least). I’ve enjoyed the change so far; it was well needed.

When joining a new team - and a new company - there are a lot of things to learn. Most of that learning starts with loads of things to read, including process documentation, system diagrams, API specifications, and data models for software teams. Then there are even more docs on culture, how to respond to incidents, and decision logs.

It can be a lot.

As I’ve been going through the docs of our engineering team, I had a few takeaways about how to do documentation right - and why it is so hard to do so. Today, I want to share my perspectives while still fresh as a recently onboarded engineer.

And to be clear, I’ve been blown away by how good the documentation at PG (Policygenius) has been. I don’t think there hasn’t been a question I’ve asked that didn’t have an answer with a document, Wiki, or slide presentation to help me understand the answer in more depth.

Understand There are Different Kinds of Documentation

And that each needs a different medium or format to be effective. For instance, system diagrams and data models should be captured in a visual format - i.e., boxes and arrows to show relationships and data flow rather than text descriptions. On the other hand, describing expectations for how a team operates and the responsibilities of individual engineers is best done with articulate prose.

One of the best things I’ve seen to help with this is a flowchart to help the whole organization agree on what kinds of documentation should live in what kinds of formats. While these decisions are pretty intuitive, they can help remove as many deviations as possible. Better yet, add where documents should be and what tools to use for each type. Should text-based documents be stored in a Google Doc or a Wiki? Should project folders be under team-specific directories or the root directory? Should we be using diagram tool A or B? In the world of documentation, the more consistent you can be with these sorts of decisions, the easier it will be to discover and subsequently add to your docs.

Code is Truth

When describing software systems, we must trust the code over the docs. Why? Because the code is what your software is doing. There is no way to avoid that.

This is why engineers can be pedantic about comments. Comments explaining what code is doing can easily get out of date and confuse the next engineer trying to change it (or even understand it). I won’t open up the comment wars here, but it is good to be aware that your code serves as a form of documentation for your software - because it is your software.

Therefore, part of maintainers’ responsibilities is to look at the code when a question is raised about system behavior. When a difference arises between what the documentation says vs. what the code is doing, the team must decide which is incorrect and correct it. Keeping a tight loop here is especially important for public APIs and API specifications (which we will discuss further in a moment). In either case, when a gap is identified, don’t be silent. Raise the issue and work to understand what the code is doing and decide which thing - the code or docs - needs to change.

Generating Docs is Usually a Good Idea

Given that code is truth, anything we can do to keep our documentation in line with our code is usually a good idea. If you can generate docs from your code, you minimize documentation drift as much as possible. Tools like JavaDoc or godoc make it easy to turn comments in code to HTML, text, or even man pages for the software. Standards like yuml allow teams to store easy-to-change and understand text documents into UML diagrams.

These tools, coupled with continuous integration and the API-driven web, can allow you to generate documentation from your source with every commit to your code mainline. Just think how great that is! Every time you change a data model, a new ER diagram is generated and stored in your team’s Wiki! Such low-friction tools can be a game-changer to how your team operates.

One caveat here is that you also need to consider the difference between a contract/specification and other documentation. You want to drive requirements for your software from specifications and contract definitions, but you also want to have documentation about your software.

This topic is especially pertinent to the API lifecycle - do you build your documentation from source code since that is what your API is doing? Or do you drive documentation from your specification because that is what your API should be doing? Opinions vary on this topic, but the one thing to take away here is that specification documents for your software need to be treated differently than documentation about your software.

Documentation Drift is Unavoidable

The sad truth is that even if we create great processes and automation to keep our documentation up-to-date, the reality is that at some point, something will need to be updated. Some links will be broken. A section will be old and incorrect. Out-of-date documentation might not be true for more static systems, but for the ever-changing world of modern web applications, it will be.

Instead of avoiding this, opt to minimize it and be quick to make changes when you notice something is wrong. Everyone in your organization should have some ability to suggest changes quickly and effectively or have the ability to make changes themselves. Treat your documentation like an Agile product: make it easy to get feedback and make adjustments so that you can respond quickly to changing needs of your growing team.

Documentation is a Tool

After all of this, remember:

Documentation is a tool for helping your team succeed.
Effective documentation will tell your team members what you do, how you do it, and - most importantly - why.
Go to the code when you can - generating anything possible to minimize drift.
Make the docs easy to change - just like code.

Happy coding!

Originally posted on dangoslen.me

My Top Takeaways from Team Topologies

Dan Goslen — Tue, 14 Dec 2021 13:58:30 +0000

I’ve played team sports my whole life, and I learned the unique power and ability a team can take on early on. I’ve seen how a great team can elevate each team member to achieve better results than if alone. Being a part of a team is something everyone should be a part of.

In many contexts, the structure and identity of a team are relatively easy to understand. In sports, a team has a clear mission - win games. A band has a clear mission of creating incredible music. The structure of such teams is also usually pretty simple - a captain or band-leader is primarily held responsible for setting the team’s tone, vision, and direction. Other team members still work together around a common goal with well-defined roles within the team. Forming a team is easier when you know the roles.

In software and other business contexts, though, things can get murky. We know teams are good, but we don’t know what a great team should look like. The mission and structure can get complicated - should this team be building that? Do we need to hire a database administrator for a team or hire one to support multiple teams? Is a manager a tech lead? And when mission and structure are lacking, the team itself can begin to suffer.

Team Topologies is a book targeted to help fix this problem. Written by Manuel Pais and Matthew Skelton, the book captures their insight into the world’s top software organizations. Focusing on teams that have undergone various DevOps and Agile transformations, the authors provide an inside scoop onto the secret sauce for these companies. While being a little dense and academic, the book still provides direct actions for organizations trying to make changes to increase their productivity.

Let’s dig into their findings.

The Big Idea

The core driving idea of Team Topologies is (unsurprisingly) that software organizations need to focus on how their teams interact with each other to improve.

Sounds underwhelming, right?

That was my initial reaction as well. However, the book does a great job of identifying why this component can be so critical. It helps identify that no two teams are created equal and that they, therefore, have different goals. The book suggests four core team types that an organization should consider and how each of those teams should interact with each.

I won’t get into each in this article as you can see them summarized easily. Instead, I want to focus on the underpinning concepts that can help your team(s) start to discover what type they are and how they should begin interacting with other teams.

Create a Team API

Software engineers know all about APIs. An API defines a responsibility boundary between different systems and a contract used to enforce those responsibilities. This is similar to how a legal contract is written between two parties. The contract defines the responsibilities of each party and consequences of breaking those responsibilities.

Teams also should have such an API. Teams should have defined boundaries (often referred to as domains) that they own. As such, teams need to know how to interact when a system or a design requires collaboration across domains. Hence, an API should be defined to help establish the “what is yours” and “what is ours.”

A team API should likely include

the team’s mission
how to contact them
a definition of the domain they own
the preferred way to collaborate with that team
Don’t pretend this will be easy. In many organizations, lines have become blurry over years and years of shared code (we’ll address this next), constant collaboration, and even bad software design. Teams might even have to collaborate with one another to agree on domains (“you own that - not us”). Many teams might have never even thought about their core mission - they’ve just been writing code according to the product specs from their product owner without giving a second thought. All this to say, creating a team API will take a good amount of effort.

Define Code Ownership

Along with domain ownership and boundaries, the code within an organization needs the same rigor. Every repository or module needs clear and explicit owners. Without such ownership, code can be neglected and left to rot. Or, when a bug is discovered in a system, no one can agree on who should fix it, which does nothing more than waste precious time to fix an issue.

Ownership doesn’t mean that only one team can contribute to a codebase. Hardly. A good software organization should allow any software engineer to contribute to any project as long as it has the approval of the owners of that code, which can help alleviate bottlenecks. An engineer who uses a module or service provided by a different team can make the necessary changes to finish their work instead of waiting for another team’s availability. The owning team, of course, needs to participate in code reviews or other approval processes required, but this is often much less time than writing the code itself.

However, without oversight from owners, such changes would likely lead to confusing and fractured codebases that are hard to maintain over time. Such “shared-source” models sound great at first but can slow any high-performing team down to halt even if the initial first few interactions seem to show a decreased cycle time for some product initiatives. Be really careful about this model.

In short, just like domain boundaries and ownership, code needs the exact same treatment. Take an inventory of codebases that teams’ interact with identify the owners. If there is a disagreement, work together and appoint an owner as clearly as possible. Keep revisiting the codebase based on who makes the most contributions or has a clear vision for the code. And remember: you can change the owner in the future if needed.

All Teams are Aligned

Lastly, each team within the organization needs to align their priorities to a workstream. No matter the concrete team type, they all need to be aligned to a specific workstream within the organization. This priority enables all teams to work with the flow of change within the organization rather than against it.

Finding this alignment is, unfortunately, not easy. The book recommends a few steps to gain this alignment, all based on the teams operating within the organization.

The first step, and the simplest, is that work steams need to be defined. What are we building here? Why? How many products should we have, and how will we organize them? Compare the current product offerings and make some critical decisions about how work should flow within your organization.

Second, platform, subsystem, and enabling teams (aka supporting teams) should gather their requirements from the stream-aligned teams. This allows the work to flow from the root source of customer needs properly. i.e., if a stream-aligned team says, “we need a better and simpler way to monitor our applications,” the proper supporting teams can then take that requirement, perform additional discovery, and help those teams find the right solution. Otherwise, they might be working on the wrong thing.

Wrapping Up

There you have it — my top takeaways from Team Topologies. There is much more to cover from the book, but these key things to me are the core things you can start thinking about with your team to level up tomorrow. Even if the rest of the organization isn’t on board, if your team can define their API, identify domain boundaries, and gather their work according to a workstream, many other conversations can occur.

Happy coding!

p.s. I know a big part of Team Topologies is all about Conway’s Law. And it is indeed. However, focusing on Conway’s law might be premature. The reason is that leaders might see a poor architecture and decide to change it via the inverse Conway maneuver (using Conway’s law to design your system). The problem is that there is often a large disconnect between a leader’s perception of what is happening in the organization vs. the team’s perception. Therefore, before an organization can start talking about how to re-design their architecture with Conway’s law, I believe they first need to understand how their teams are currently operating. And no one else except the team is prepared to speak about how they operate.

Cover photo by Cas Holmes on Unsplash

Originally published at dangoslen.me

Let's Talk About Trust

Dan Goslen — Thu, 19 Aug 2021 15:19:44 +0000

👋 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! Lets 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. Others might think trust is impossible to attain - it's an ideal, not a real thing.

Regardless of what others might think, research has found that trust is vital to a team's success. However, it can be hard to pinpoint what trust is. One of those "you'll know it when you see it" situations. It requires intuition rather than computation.

This leads to confusion about what trust means on teams (especially on software engineering teams where computation is what we do). Trust isn't thinking a teammate will never make a mistake. Instead, it's the assumption of good intent and effort. Trust is about knowing that you are safe to do your best work within your team, that you can depend on one another, and everyone else feels the same way.

Let's dig into this a little bit.

Trust Is Important

Before going further, let's go back to why we need to talk about trust.

In their famous re:work-study, Google found that high-performing teams had a handful of traits in common - and they had nothing to do with individual performers or ability. Instead, they found that other factors about how the team operated were more critical. The top two factors were psychological safety (do team members feel safe to take risks without feeling insecure or embarrassed?) and dependability (are team members delivering high-quality work on time?).

When taken together, these two items form what I think of as trust. If I feel safe on a team and know that I can depend on them, I can trust their intentions and efforts. This makes it easier to focus on my work without worrying about if others are doing theirs. I can feel confident when collaborating with them as I am sure they aren't trying to embarrass me.

Trust on a software team is especially pronounced. We all know the stories of senior engineers that act like dictators towards their team. Instead of collaborating, they force a specific pattern or design. Instead of delegating complicated coding tasks, they don't allow anyone to touch the code but themselves. In my experience, these teams tend to deliver low-quality work behind schedule.

On the other hand, software teams with high trust seem to deliver higher-quality work faster. Why? I have some thoughts...

Why Does Trust Work?

You might have noticed, we've been talking a lot about intention rather than the outcome. Here is why.

If I were asked to trust that my teammate wrote perfect code, I would decline. Why? Because humans are fallible. We make mistakes. I simply can't trust that any teammate will write perfect code with perfect tests (I don't trust myself in this regard either).

But what if I did say I trusted my team completely? What would happen if I genuinely thought that they never made mistakes? That they never fat-fingered an Ansible playbook? That they never confused requirements?

In that case, most of what we have in our modern software development lifecycle would be waste. If we trust and then expect our teams to be perfect, the rigor of our modern software processes just gets in the way. Code it, ship it, move on to the next thing.

We, of course, know that this isn't true! The best software teams are ones that, in a sense, expect themselves to make mistakes. They know no one is perfect. That is why they automate tests, automate deployments with smoke checks, and inspect each other's code routinely.

Now let's go back to that initial question and change it a bit. If I were asked to trust that my teammates have put their best effort forward, I would say absolutely. Imperfect code written by an imperfect person can still be trusted in the sense that it changes how I approach them, their code, and even reviewing it.

If trust is about our teammate's intentions, it opens up a lot of possibilities. We can approach our teammates with humility but with a keen eye for problems or bugs. We can be collaborative since neither of us is perfect.

How To Create Trust?

The obvious question then is this: how do we create trust in our teams? If it is so important, what steps does our team need to take the build it?
Sadly, there is no magic checklist for building trust in a team. It requires a whole range of disciplines and tools.

There are two, however, that I have found to be particularly helpful: humility and willingness.

When we are humble about our abilities (knowing that we can always get better; being open to others' opinions), we are easier to work with than if we were arrogant. We are likely to learn and improve our own skills faster since we know we can always have more to learn.

When also need to be willing. We need to be willing to listen first, extend the benefit of the doubt. We need to be willing to try others' ideas. When we are willing rather than willful (trying to control how every little thing happens), we earn the trust of others by showing them we are more concerned about solving problems together rather than doing things on our own.

Trust Can Be Lost

Trust is also not fixed. You don't create trust one time with a teammate and never have to think about it again. Just like software, property, and physical health, trust needs to be maintained.

This is important because it shapes how we work as a team. You can't create trust with a teammate, start treating them like a jerk and expect them to trust you. You can't continue to be wrong over and over on a technical fact and expect the team to "take your word for it." We have to keep investing time and energy into maintaining trust in our teams.

Aim to build trust with every interaction you have amongst your team. Bring humility and willingness to code reviews, team planning meetings, and even as you have one-on-one interactions. After some time, your intentionality will have a huge impact on how your team trusts you.

In summary, we need to trust each other on a team. High trust also doesn't mean we accept each other's work as-is without additional thought or inspection. In fact, it allows us to continually improve upon each other's work because we trust their intentions and effort vs. expecting code to be perfect.

Happy coding!

Originally posted on dangoslen.me

Cover Photo by Sandra Grünewald on Unsplash

Three Ways to Reduce Chaos on Your Team

Dan Goslen — Wed, 28 Jul 2021 16:20:08 +0000

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 working on what, when, and why. It is not knowing what changes are in a software version, what version is in production, and when the next deployment is (though automation can help in all of these cases). Chaos is drowning in meetings, support tickets, and coordinating all of the communication around each, unable to get work accomplished.

And while I don't have all the answers, I do know tools that can help reduce some of this unnecessary chaos. I want to share three tools my teams use to help. We've been using these tools for a while and have seen great results.

Let's dive in!

Changelogs

Changelogs are exactly what they sound like - a log of notable changes made in a software project. While it seems silly that keeping a simple log file would make such a difference, it does.

When you keep a changelog, you are committing to keeping an accurate record of history. If that doesn't sound useful, think of the many questions often asked of a software team. "When did that change go out?" or "who worked on that story?" I'll wager these questions inevitably arise in your work every day. If you had an ideally kept log of the history of a project, it would be easier to answer those questions. A changelog helps teams do just that.

Of course, changelogs aren't perfect. They have maintenance costs associated with keeping them up to date, which can get burdensome. In my experience, however, the pros outweigh the cons.

If you are interested in keeping a changelog, check out the tools and articles I've already written on this topic!

Designated On-Call and Interrupt

Part of the regular day-to-day chaos of software development is that software breaks. When it does, it usually needs to be repaired or fixed as soon as possible.

Aside from software breaking, there can also be regular interruptions that need attention. Another team has a question about part of the system you built. Tickets from customers need addressing. Someone needs to push the deployment button (or you could automate it!).

In both of these cases, the result is the same: distraction and disruption.

What I've found helpful is to have a designated on-call/interrupt person at all times. Whether deploying an application, being the on-call support, or answering customer tickets, they are the first to tackle those tasks. The role gets assigned to different team members on a schedule (or a rotation) since it can be a lot on someone.

In my experience, this has two major benefits.

First, because everyone shares the roles of being on-call or support, everyone gets extremely comfortable with those tasks. Better yet, it forces everyone on the team to understand the good and bad parts of those operations - which means everyone has the motivation to make it better. If only one person (say an SRE) is on the team, it can be difficult for the team to understand what needs to change in the code, deployments, etc., to make it easier to manage and support.
Second, it allows those not on-call to focus. By having the on-call/interrupt person handling incoming requests and disruptions, the rest of the team can focus on writing code or doing their "typical" work. They can protect their most valuable asset - time.

One quick word of caution: the on-call/interrupt person isn't - and shouldn't - be expected to handle every incoming disruption! The rest of the team can and needs to help if many requests come in. Most of the time, however, only a few will come in at a time and can be handled by the designated team member.

Regular Deployments

If you've been following the latest trends in software engineering over the past ten years, this isn't a surprise. The industry has discovered that teams can achieve high stability in their software by making smaller, more regular deployments. The conventional wisdom before 2010 was to touch production as little as possible - if it works, don't fix it.

My own experience is that frequent deployments do indeed bring higher stability to your software. Not because deploying mediocre software every day suddenly makes it better. And not because it is any less risky. The stability of your software increases with more frequent deployments is because it forces teams to build automation to handle the risk much better, and it forces versions to be smaller.

It won't be easy. Being able to have automated deployments to production requires disciplined, focused thinking and development. But it will be worth it!

If you want to learn about this topic, take a look at The DevOps Handbook and my own post on what's the point of CI anyway?!

Working as a software engineer will likely never be a zen-like experience where every requirement, software component, and timeline work in perfect harmony. There will always be bugs to fix, customers to serve, and complexity to navigate.

But we can help reduce the chaos! By protecting our time and energy through investing in automation, documenting as we go, and finding ways to focus, we can control the mess instead of letting it control us.

The tools I've shared here have made a major positive impact on how my team works, and I hope they can help your team too!

Happy coding!

Originally posted at dangoslen.me

Cover Photo by Alina Grubnyak

I'm Changing How I Review Code

Dan Goslen — Wed, 14 Jul 2021 10:43:07 +0000

I'm a big advocate for code reviews. I've written about my experiences reviewing code, including lists of dos and don'ts, how to survive your first code review, and why we should review code at all.

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.

Recently, though, I've been seeing thoughts expressing a different sentiment. Many devs are starting to become frustrated with the pull request model. There is a sense that pull requests actually might make it too easy to comment on a line of code. This ease might be leading to the conflicts and hyper-zealous commenting that frustrates many in our industry.

Another common critique is that the pull requests encourage reviewers to only look at the code. They never even pull down the changes they are reviewing! To be completely transparent, I'm guilty of that myself.

After reading the article and seeing some related ideas via Twitter, I wondered: are there better ways that I could review code? What could I do differently?

After asking, I've decided to start making some changes in how I review code. They've been helping me recently, so I think they could help you and your team as well.

Commenting on Code vs. Collaborating on Code

One of the top thoughts that made me start questioning how I review code comes from the article above:

Pull requests are an improvement on working alone. But not on working together.

That struck a chord. Indeed, pull requests aren't the primary way to collaborate with people after all.

Collaborating on code is vital to a team's ability to maintain a codebase. If a single member of a team is left to write an entire codebase without working with other team members, there is a high probability that the rest of the team won't be able to contribute to it after a while. Worse, if left alone, a single team member might even get things wrong or be unable to solve a problem. Therefore, collaborating early and often is a good idea.

The next question that arises is this: how does a team collaborate on code? Further, can a team collaborate too early? Too often?

Many teams seem to have concluded that a pull request is a great place to have collaboration. I don't think they are wrong. First, a team member feels ready to share a version of their code with the rest of the team for direct feedback. Then, like an author writing a book, they submit it for a first review to get feedback. The rest act as editors, ready to help get the draft ready to print.

There isn't anything wrong with teams seeing pull requests as a place for collaborating. The problem is when teams think collaboration is restricted only to the code review process.

Teams should be working together on problems, ideas, and code well before code is submitted for review. Mentors should be advising mentees, peers should be offering help to each other, and pair programming or debugging sessions should be routine. If an author were to send the first draft to their editor without disclosing what the book is about, it would make it harder for the editor. The editor now has more they need to understand to give useful feedback. As a result, the publication date is likely to get pushed later than anticipated.

Genuine collaboration is more than just leaving a comment or a suggestion. It's discussing alternative solutions, prodding at requirements, and having real-time feedback loops with your team.

I will be working towards making this form of collaboration more common within my team. I'm hoping to move us beyond collaboration via comments and get back to real-time collaboration.

Run. The. Code.

Commenting on and rejecting a pull request without ever running or stepping through the changes made sounds silly when said directly. But many developers - including me! - do this all the time.

As engineers, we shouldn't evaluate code only by how "clean" it is or how wonderfully abstracted it is. Instead, we still need to measure code by how well it does what it is supposed to do - deliver some value when it runs.

To drive this point home, when was the last time you looked at Google's source code for Google Search? If you did see it, would it change how well you think it works as a product? Probably not.

I'm not trying to be hyper-reductionistic here. The quality of code does matter! It should be clean, crisp, mutable, etc.

But part of what makes that code good is how well it solves a problem. Does it do what it needs to do to meet requirements? Will the end product be better? At the least, all code needs to make the end product better.

What is the best way to see if the code makes the product better? You have to run it. Treat a pull request as a chance to do a mini-demo of the added or fixed functionality. Use it. Poke at it. Heck, even test it yourself!

I've been incredibly guilty about this. I tend to trust our automation that the code changes produced the desired behavior changes without observing the behavior myself! I want to start changing this and running code more frequently.

More Navigating and Less Backseat Driving

When a problem (or even a difference of opinion) is spotted in code, it can be easy for a reviewer to recommend a concrete change right then and there. For example, they might include a block of code in their comment or add a GitHub suggestion of their improved implementation. They might even include citations and links.

And they do this for every issue they see.

While there are times adding such comments can be appropriate, it often can feel like the reviewer is attempting to take control. They are dictating what the code should be rather than providing feedback on the written code. The reviewer is giving directions as if they were a backseat driver. And no one likes backseat drivers.

Great code reviewers know the difference between being a backseat driver and being a navigator. Both give directions, but one has the destination in mind while the other is trying to control the driver. A navigator knows multiple ways to reach a destination, but a backseat driver complains when the driver takes Martin Street instead of Hampton street - it could have saved one whole minute!

What does a navigator look like in a code review? Instead of focusing on how to change the code, they are focused on why the code needs changing. They care more about the final outcome rather than the concrete classes that are written. The navigator is primarily focused on understanding where they need to go and to help them get there.

I want to be more of a navigator. Not every single detail needs commenting, and not every difference of opinion needs to be shared. I want to review code in such a way that I'm helping rather than controlling.

The goal of all of this is really more than becoming a better code reviewer. It's about becoming a better teammate. Knowledge work isn't just an individual grinding away on an intense thought or task anymore. Knowledge work - or at least meaningful knowledge work - tends to be accomplished by teams.

And I want to be a great teammate.

Originally published at https://dangoslen.me.

Photo by Francesco Gallarotti on Unsplash

Reflections on Two Years of Blogging

Dan Goslen — Fri, 16 Apr 2021 13:57:55 +0000

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 here on DevTo. 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.

Today, I wanted to share a few of those successes and a few failures on my part. I'll reflect on what has worked for me, what hasn't, and tell you how this will shape my future writing. If you have considered getting into writing or blogging, I hope my first few years of it can help you along your journey!

The Beginning

I started blogging because I had just joined a new team after having had a terrible experience with a failed project. I was burnt out and tired. But I was also excited about this new role.

Once I joined, I realized I had something to offer my new team. But not coding know-how or technical expertise. I had some insights on team culture from my past experiences being so terrible. I wanted to create the best team I could by offering my perspective of what not to do.

So, I started thinking critically about what I could do to help build a great team. I shared my ideas with my teammates, and together, we refined them until they made sense. Then we gave them a try.

After a little while, I realized that my current team was becoming a great team after all. We weren't perfect, but it was a far cry from where I had been. The insights and ideas I had brought to the table were making an impact.

Maybe others would like to hear this?

I started writing about the things our team was doing that were making us a better team. I wrote about code reviews and why they matter, how hasty abstractions can crush your team, and how great user stories have drive clarity. I also noticed that by writing, I solidified my own opinions and learning to express them better with each article.

Gaining Readers

Like many bloggers, my first articles didn't get read all that much. Part of this is a failing on my part (hint - I'm bad at marketing). The other part was that I wasn't writing for anyone. I was simply sharing my experience but not writing about how you - the reader - would benefit from reading what I wrote. I still struggle to do this well today.

In October 2019, though, I wrote an article about simple code that started to gain real readers.

It wasn't a viral success, but it was enough to start to get my views into the thousands for the first time!

I realized that maybe - just maybe - I something to offer.

I decided that I needed to publish more articles. I started working to create as soon as I could. The name of the game is publishing content all the time, right? I have some thoughts on this idea towards the end of this article, though :)

I published another article one week later. Guess what? I got even more views! I was hooked.

Getting "Serious"

At this point (early November to late December), I started to think critically about how to grow my audience. I began reading resources on improving my content. I read some books on content creation, signed up for a handful of blogging email courses, and created my own content calendar.

I also started to experiment more and more with the topics of my writing. Why? Two primary reasons:

It can be hard to come up with unique content all the time. Sometimes falling back on sharing an experience or what you have learned (#todayilearned and #learninginpublic) is all you can do
I was curious to see if I could find patterns of what content I wrote connected with readers. Sadly, Medium is very narrow in this regard. You can tag your article with topics, but they are so broad it can be hard to tell what tagged stories are actually about. I did find a few patterns that I will share at the end.

But I also started to feel - like a machine. I've come to dislike the term "content creator." Perhaps, I'm a creator. But not a creator of content. I like to position myself more as a creator of thought or systems. But this is all a bit tangential :)

Getting Tired

After a few months of trying to keep a content calendar with a full-time job, going to master's school, and preparing for my wedding - I couldn't keep it up anymore. I was just too tired.

But additionally - I felt like my ideas had transformed into, well, content. I didn't feel like I was bringing unique perspectives to the table. I wasn't thinking deeply about the topics I was writing about.

I was doing what content creators have to do sometimes - find ways to write about something I knew, grab a reader's attention, hold it just long enough to read a brief article, rinse, and repeat.

I'm not judging that approach. I think it's an extremely demanding regiment to follow. I just realized that I want to be at the bottom of things rather than on top of things, as legend Donald Knuth puts it. Not to say I am anywhere near his intellect or ability!

What Has Worked For Me So Far

While I don't have the most impressive analytics on this - a gap I am working on correcting moving forward - I have enough to notice a few trends to point towards success. I'm not an expert writer or content strategist (I still don't like the term content), so this is meant for observation rather than prescriptions for someone to try.

Columns are Views, Reads, Read ratio and Fans

Being Vulnerable

Two of my top three posts on Medium are My Biggest Mistakes as a Junior Developer and I'll Admit It. I'm a Jealous Developer. In each of these posts, I shared my insecurities, vulnerabilities, and failures. While I got some criticism for not being insightful or original in either of them, I have to remember that not all writing has to be insightful or creative to help someone else.

Topics I'm Passionate About

Eight of my top ten articles focused on a few areas of software engineering I am passionate about: simple code, effective code reviews, and software patterns. I've also written articles about improving the culture of engineering teams through continuous improvement and the danger of "hero" programming that have resonated somewhat too.

I believe these resonated with readers because:

1) They could tell I was passionate.

2) It's an area where I can share stories from personal experience (see vulnerability above).

3) I've worked hard to deeply understand these topics through my studies and my work.

Combined, this means I can offer value to my readers rooted in experience rather than fishing for something to write about. And I think readers can tell.

The Right Publication(s)

My most read articles were all published under a publication instead of just me. But not all of them are created equal. I've found a few publications seemed to get more readers than others. I won't post which publications those are since success with each is dependent on what you are writing about - and I don't want anyone to think submitting to one of them will be a "silver bullet."

While this is last, I think this is really important. Without getting a publication or two to bring in my article, I don't think I would have gotten any readers. If you are considering writing on Medium, don't make it your goal to get a publication to accept an article, though.

Focus on high-quality writing, and you'll eventually have publications asking you to submit your article to them!

Moving Forward

With this in mind, I'm trying to re-evaluate where I take my writing for the rest of 2021. I'm still going to be experimenting, but generally, I have three pillars I want to set for how I move forward.

More Focused Writing

I want to focus more and more on writing about the same topics. When I first started writing I thought I would exhaust all things code reviews or building trust in your teams. I've found there is actually a TON left to write about in both of these domains.

I've also become much more passionate about the idea of sustainable development - that development teams should be able to maintain a constant pace indefinitely. Everywhere I look, I see developers who are overwhelmed, exhausted, and beat up. They are burned out.

I want to help devs avoid burnout.

I believe that by following the right software engineering practices and building teams built on trust, that devs can avoid the common burnout problem. I want to focus my writing on helping devs and teams adopt those patterns so that they can avoid burnout.

Building & Learning in Public

I'm a huge fan of building or learning in public. Sadly, I'm not great at it. 😔 What I'm planning on doing is moving where I share about what I am building or learning in public to Twitter rather than my blog/writing.

I'm doing this because every time I try to write a whole article on building or learning in public, they get too long (this post for example 😅). I'm hoping using Twitter to discuss what I'm learning and building will keep my thoughts short and focused on my audience.

Building Resources

As I've been spending more and more time refining this idea of helping devs avoid burnout, I want to build more resources than just my blog. I've already been building some (very) small GitHub Actions to help automate a few tasks, but I want to build even more. There is a lot of room to improve the monotonous parts of even the best software development lifecycles.

I have a few ideas for some e-books (yes, yes. I know everyone has an e-book) that I would give away and a few that I might charge for. A few topics swirling in my head are surviving your first year as a developer, practicing healthy code reviews, and how to set boundaries at work. I've struggled with those last two, so I hope I can offer some helpful insights.

I'd also like to do more interviews around the idea of burnout. Not a podcast, I don't think, but perhaps a newsletter where I interview devs who have experienced burnout. If you have a story about burnout that you think would help other devs, shoot me a message on LinkedIn or Twitter! I'd love to hear about it and see if this idea resonates with others.

If you've made it this far - thank you! What a long one that was. I write all this because I want you, the reader, to know where I'm going to be focusing my attention in the future. I'm trying to help devs like you avoid burning out. I want to do that through continued writing about software engineering practices, sharing more of what I learn and build in public, and building a collection of additional resources for helping devs avoid burnout in a few sticky areas.

Happy coding!

Cover Photo by Aaron Burden on Unsplash

Our Obsession With Patterns

Dan Goslen — Wed, 03 Mar 2021 20:23:59 +0000

Learning patterns have become a core aspect for many people on their journey to becoming software engineers. Articles and 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 to look them up quickly. I certainly don't go attempting to use a pattern just because it is in a book or article.

I think we are over-obsessed with software patterns. And I don't think we should be.

The Wrong Direction

One of the reasons engineers have become obsessed with patterns is because patterns offer solutions. The idea goes "If I can learn every pattern, then I write any software and solve any problem". That thinking is kinda like "If I had everything in the world, then I would be happy."

Sadly, neither are true.

The reason is the direction is wrong. The best software engineers don't focus on memorizing existing solutions, they focus on solving new problems in the best way possible. The happiest people in the world aren't those that focus on wealth or money or possessions. The happiest people in the world are those that have immense clarity about what they love and they focus on that.

Don't get me wrong - learning about patterns is helpful. Knowing them will give you more tools in the proverbial toolbox that you can reach for at any point in time (more on tools later). But just because you have a hefty toolbox doesn't mean you know the craft of writing software.

Patterns Can Actually Be Really Limiting

Patterns can provide incredible flexibility and evolvability within your codebase, but only if your codebase is of the right type. Object-oriented languages and statically-typed languages of course do well with patterns. Function programming and dynamically-typed languages tend to not benefit as much. This is especially true for languages such as Haskell, lisp, or even prolog.

I mention this because most engineers can program in more than one language and the type of language used on a project is based on the problem space. Yes, you could write a Java application to send a simple HTTP call to set up data for a test. Or you could write a bash script. Applying patterns in a bash script isn't the same as Java. And you don't need a pattern anyhow to send a simple HTTP request.

If you learn patterns because you think knowing patterns will magically help you write any software in any language to solve any problem, think again.

Patterns Are Tools. Not multi-tools.

I've found that while patterns are useful to solve the problem they are meant to solve when applied before that problem actually exists, it only creates confusion. Engineers take the patterns they have learned and attempt to apply them anywhere and everywhere. They treat them like a multi-tool that can "solve anything".

Have you ever actually used a multi-tool? They are bulky. They are really heavy. And they rarely can do all 2,897 functions promised by the attendant at your local outdoor store.

Tools on the other hand tend to be much different. They have one, maybe two extremely specific use cases for which they are designed to solve. You wouldn't use a screwdriver to drive a nail and you wouldn't use a sander to cut a board in half. Even within a tool like a socket wrench, there are different sizes for different needs.

We should think about patterns like tools. They have specific use cases that they were specifically designed to solve. Trying to use them to solve different problems isn't going to solve anything. When used correctly they will improve your ability to implement the solution you have in your head. Used poorly, and you'll be spending extra hours fighting against yourself.

Patterns Can Lead to Over-Engineering. Fast.

Have you ever worked in an old, crufty codebase? You know the ones I'm talking about. Where classes are 10000 lines long, functions take 7 different boolean arguments, and some comments say "Please don't touch this code!". I have and it isn't fun.

But have you ever worked an over-engineered codebase? It feels really clean and concise. Small classes, small functions, etc. But it feels like a smoke and mirrors game. Where the crufty codebase felt like trying to untangle a massive knot of wires, an over-engineered codebase feels like trying to make it through one of those fun houses at the fair - it's all smoke and mirrors, and you constantly question what things are real.

What leads to these over-engineered codebases is often the overuse of patterns. Even when the right pattern is used for the right "problem", simpler code would have been plenty sufficient. I'm a big fan of writing simple code before anything else as I believe the simpler a codebase is, the easier it is to build upon.

And keeping things simple is actually not that easy. It takes constant refactoring, thinking, and tinkering. Patterns can quickly create complexity if not used judiciously.

I'm still a big fan of patterns and using them where appropriate. This article is simply a caution that patterns don't solve all your coding problems - they only solve the ones they were designed to solve. Think critically before applying them and always - ALWAYS - start simple.

Happy coding!

Originally posted on dangoslen.me.

Why Getting My Master's Degree Was Worth It

Dan Goslen — Mon, 15 Feb 2021 23:05:33 +0000

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.

I Learned How to Learn

Learning is a subject I'm very passionate about actually. In my undergraduate days, I minored in cognitive science to understand more about how we learn effectively. In graduate school, I put some of those ideas to the test.

And then some. I learned how to read academic papers to understand the core ideas - and why nuance can be a massive shift in thinking.

I learned how to break vast topics (machine learning, for instance) into manageable chunks that I could understand, apply, and then reason about. I learned how to quickly determine what information was and what information wasn't important (hint - not every detail of every algorithm is, but knowing when, why, and how to apply an algorithm is).

The best way to learn isn't by just memorizing information or even grasping the general "rules" of how things work. The best way, I have found, is to make as many connections between your knowledge as you can. Link what you are learning to your existing knowledge and to related ideas you are in the midst of learning as well. In fact, this how our brain actually works! Check out this brief but comprehensive explanation.

I Learned How to Ask Better Questions

Part of being an effective learner is asking the right questions. And make no mistake: there are no wrong questions. They are just more effective ones and less effective ones. I really like this take by Artem Zakharchenko where he discusses how important the role specificity is to asking good questions.

For instance, let's say you are trying to store a record in a relational table. Databases are new to you, and they are currently blocking your ability to move forward with your task at hand. Well, asking "how do relational databases work in general to store a record?" is likely too broad of a question at the moment. You need to learn enough to figure out how to store the record. So you Google or ask a friend, "how do I store a record in this SQL Server table?"

However, you soon realize you need to learn how to update a record in the same database. Now is probably a good time to ask, "how are records stored so that I can update one that exists?"

Notice that your first question was specific - how to store a single record in a single table. Your second question was broader - how are records stored so that they can be updated.

Learning when to be specific, when to be broad, and when to ask a question about applying an idea in another context is an art. And like all art, you only get better by practicing.

I Learned I Will Never Know Everything

I know you are thinking, "I could have told you that, Dan! Everyone knows you can't know everything." In fact, I told myself that.

But there is always that inkling, for me anyway, to always be learning and growing. Even in my classes, the semester would end, and I would think, "That's it!? I need to know more!"

That is the funny thing about learning. The more you learn, the more you realize how much much more there is! Machine learning is massive. People earn PhDs for one algorithm! The rabbit hole goes deep.

The take away with this for me is that I don't need to understand exactly how a complicated network works to send requests over it. I don't need to understand every aspect of how distributed file-systems work to write efficient map-reduce jobs. I just need to know enough to do the work in front of me - and I can learn the rest.

I Learned That You Can Do A Lot In a Small Amount of Time

We have in our heads that making anything takes time. And that is certainly true. In my experience, however, what you accomplish sometimes has more to do with effort than time. We tend to think that effort and time both work on roughly the same scale when they aren't at all.

Programming, for instance, is a great example of this idea. In my school programming assignments, I could crank out code extremely quickly - even though I was coding on the edge of my comfort zone. The reason is that I've programmed enough that coding doesn't scare me. I've become enough of an expert programmer that once I understand the problem, I can enter into a flow state quickly and knock it out. Most of the time, I would do my coding assignments in under 4-5 hours - half a working day!

Again, this isn't true for everything. Knowledge work does require long periods of uninterrupted time for growth to occur. But as you grow, you will find that the amount of effort you can exert on novel problems within a given time also grows. It's incredible.

I Realized I Am Capable Of More Than I Thought

About half-way through my first semester, I almost fell apart. I remember going to dinner with my family and thinking, "I can't do this. I should give up." Somehow I managed to push through.

I experienced a moment like this every semester. A moment where it seemed I was about to fall apart. And yet, every semester, I was able to find a way to learn what I needed, get the work done required, and get a decent grade.

I don't say this to brag about my ability to push through; I had insane support from my wife, family, and co-workers. I say this because sometimes we get so overwhelmed with the work to be done, we never actually start.

When I focused on doing the work in front of me and doing my best, I was able to do more than I thought. It didn't matter if it was a homework problem that was too hard, a paper that seemed too long, or preparing for a test. Focusing on the immediate work in front of me helped me finish ALL of the work I had to do.

All this to say that the most important takeaways I learned from my degree aren't things specific to computer science or software engineering. Certainly, those aspects are crucial, and I did learn a ton that will help me in my career. The most important takeaway for me is how graduate school helped elevate my mindset. I've cultivated a learning mentality that gives me confidence (but not arrogance) that I can achieve just about anything in front of me.

Many people reading might already have that mindset - and that is awesome! You don't need to go to graduate school to get it. It's simply how I did.

Happy coding (and learning!)

Cover photo by Ekrulila from Pexels

Why I Got My Masters Degree In Computer Science

Dan Goslen — Fri, 29 Jan 2021 01:09:57 +0000

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 are going to go for this thing, aren't you?" he said.

Eventually, all of these people came to support me. However, they all had the same question many people have when I tell them I went back to school for a master's degree.

Why would you do that?

I've answered this question a handful of different ways over the years. But I've never given a very comprehensive one. This article is meant to be that answer. I'll summarize my motivations, my situation, and why I ultimately went back to get my degree.

To answer this, though, I need to get a running start. I can't just start at two and a half years when I started school. I have to start with how I came to love software in the first place.

Teenage Coder and Undergraduate

I knew I wanted to be a software engineer since I was 12. My parents bought me a LEGO Mindstorms set, and I was hooked on the coding part. My high school had coding classes (lucky me!), and before I know it, I was writing Visual Basic and Java. All before I could drive.

By the time I got to college, I was on a mission to understand computers as deeply as possible.

I'm also a genuinely curious person. Like many software engineers, I liked understanding how things worked. If I didn't know how something worked, I would break it apart, trying to understand it; often not being able to put it back together.

Having a desire to understand the world and a desire to understand computers, in the same way, led me to set a goal of getting my master's. It just seemed like the right fit for me.

As I was wrapping up my undergraduate degree, though, I realized I needed to get a job. I was in debt, and I was tired. Like really tired. I needed a break from the pace of academia.

So I got a job thinking that I might one day go back to school, but it was more of a pipedream at that point. No one goes back to school when they don't need to, right?

Career Engineer

After a few years of writing code, the itch to go back started to grow more noticeable. My brother was going to medical school, a few of my friends were getting their graduate degrees, and coding was starting to feel... routine.

I wouldn't say I was bored. I was learning and growing in my skills. I just recognized that the majority of the problems I was solving were pretty close together. I was being challenged in some ways, but not in the deep, technical understanding of how computers worked.

Around this time, I also started looking for other roles. As I searched, I noticed that most roles I got excited about all mentioned a preference towards a higher degree. I thought this was interesting as I had always it didn't mean that much.

I started doing some more research. I took a look at the people around me who had the roles I was wanting to grow into. I realized that many of these people did have some form of a graduate degree, after all. Not enough reason to go back to school on its own, but there seemed to be a correlation between the roles I wanted and an advanced degree.

During this time, I also learned another thing about myself. I had signed up to take all of these online classes, but I never took them. I might start watching a lecture or two but never finish.

Why?

I've come to learn that for me, I need rigorous structure. I need some skin in the game. I need something to keep me pushing through when the content got hard or I got distracted by some other new shiny course to take.

Putting the pieces together, I recognized that I hadn't really fulfilled my desire to learn as much as I wanted. I wasn't growing in the way I wanted to grow in my work. And I recognized that the roles I wanted to move into were employing people with advanced degrees. It made sense.

It was time to go back.

The Preparation

Photo by Green Chameleon on Unsplash

Once I decided I did, in fact, want to go back to school, I had a lot of other factors to figure out. Where would I go? How would I pay for it? Would I work at the same time? Would my girlfriend break up with me? Spoiler alert - we didn't break up; we have been married for almost a year now :)

The first thing was to figure out where I would go. After a lot of research, I settled on three different programs:

NC State University (local to me).
Carnegie Mellon (a long shot).
Portland State University (where my girlfriend was at the time).

They each had different cost structures too. NC State was the cheapest because I was local while Carnegie was the highest due to out of state tuition, and it being one of the best programs in the country. Portland was in the middle.

I then needed to prepare and take the Graduate Record Examinations or GRE. Man - that was a rough test. I would prepare nearly every morning from around 7:30 to 8:30 before work, and then usually a three to four-hour stretch on Saturdays. I would also usually do a two-hour session on Sundays. I wound up having to take the test twice but got scores I was happy with.

Once I got the scores I liked, I worked on an application essay, got letters of recommendation from my manager, the director of software at my company, and an old professor - a BIG thank you to them!

I had everything I needed. It was time to apply.

The Decision Point

Before going further into this story, I need to back up and provide a little more insight into the other complexities going on during this time. The first being that I had decided early on that I wouldn't sacrifice work experience for a degree unless the program was exceptional (schools like Carnegie Mellon). I had decided that studying part-time while working would be the best situation for me to get my degree.

This is the part I think most people struggle with my story on. Why would you want to do that? More work!?

Put simply - money. I needed a job. I had also just finished paying back my undergraduate student loans - I didn't want to get new ones.

Additionally, I was gearing up to get married (my girlfriend had moved back to Raleigh shortly after I took the GRE). I would need something more than a minimum wage job or a student job.

My plan was simple: apply to the local program, and if I got in, I would talk to my workplace about how to make it work. If it became clear that my employer was not interested in working it out, I would apply to my dream program at some other time. GRE scores are valid for five years, so I would just have that plan in my back pocket.

Getting Accepted and Setting Expectations

Thankfully, I got accepted to the local program - hooray! But this started the most complex part of this process: talking with my employer.

While it is a bit of a stereotype, many software engineers are not good with people. Myself included. I am either way to intense and technical, or would rather not speak at all. How was I going to discuss the idea of going to school part-time and reducing my hours on the job? And were my co-workers going to hate me?

This is where I was glad I had practiced honesty throughout the whole process. As I mentioned at the beginning of this story, I was discussing the idea of going back to school with people already. My manager, my immediate team, and even a People Services team member, knew it was something I was working towards. This meant that the news of me getting accepted wasn't a blind spot or a surprise. It just meant that I was serious. It was time to shake out the details.

What I did was lay out some possible options with my employer of how I could work and study simultaneously. I outlined the program's length, provided links to the curriculum, set expectations on current and future costs, etc. I discussed specific classes I hoped to take directly correlated with the work I was already doing as a software engineer.

After a few rounds of negotiation, we reached an agreement! I was going back to school.

So... Why Did I Get My Masters Again?

Yes, I know that quickly became a story; a long one at that. But I think it was necessary to show that I had a mix of motivations and circumstances that went into my decision to get my master's degree.

To summarize it briefly, I'll put it in bulleted form.

I had made it a goal of mine to get my masters degree before I ever started undergraduate
As a career software engineer, I realized I hadn't scratched the itch to learn computers as deeply as I wanted
To learn at my best, I needed rigorous structure and deadlines
As I took inventory of who was employed in the roles I wanted to have, many of them had advanced degrees
I was able to land in a unique situation that allowed me to earn my degree without sacrificing industry experience

The next question, of course, is this: "Was it worth it?". I'll answer that in another post soon. If you don't want to miss it, follow me on Twitter or Medium or whatever platform you prefer (Dev.to for instance). I'll make sure you know when it's up :)

Happy coding!

Cover image by Charles DeLoye on Unsplash