Phil Busch's Blog RSS Feed

Solve Business Problems with Tracer Bullets

Sun, 22 May 2022 00:00:00 GMT

I've recently found myself discussing a technique at work called the Tracer Bullet Technique. This technique is something I first learned in a book called The Pragmatic Programmer by Andrew Hunt and David Thomas.

The tracer bullet technique enables learning about a system by making small, interconnected, iterative changes to that system. The Pragmatic Programmer describes it best as "code that glows in the dark." Code written using the tracer bullet technique reveals the all the locations you need to change to solve a problem.

How to use the Tracer Bullet Technique

Let's say you onboard to a new team, and the first user story you pick up is to build a dashboard that allows a user to view and edit their account information on a website.

How do you discover how to implement this change? Ideally, you have great documentation and a team member to pair with, but potentially you don't. In that case, you've got to start writing code somewhere.

Find the place to start

There is no magic formula for finding the first place to affect change. If you have prior experience with the technology you're using, or you believe you understand the solution design by reading the code, you can lean on that to identify a place for change.

If you're unsure where to start, take an educated guess of what code files you will be editing. Set some breakpoints, and execute your application. Breakpoints that you hit are places you can begin coding safely. If you can't run the application, get that working first.

Make a small change

The next step is to change some code. Potentially the previous step led you to discover an API controller in use on one of the pages in the application. Change the response body to include a hardcoded property set to a dummy string ("test"), and verify you see that property when you execute the code.

By making this small change, you're building your knowledge of the software's architecture. Your mental model now looks like this:

At this point, you might want to flush out and finish that API response body. Don't. Instead, it is time to identify a tangential change to make.

Make a Tangential Change

Now you'll want to make a change to a piece of code that interacts with your first change.

In our API/UI example, the second change you might make is to learn how to utilize the hardcoded test property from the API response and display it in the markup on the page. This change would confirm that you know how to get API response data onto the UI.

As you make this change, take a look around and discover other potential areas of impact. Once you have the word "test" showing up in the markup, you'll may see that the markup is unstyled. Look around for some style sheets, SASS, or LESS files. Your mental model might look like this now:

You may be thinking it is time to style that markup. Fight that urge. It's time to make a change in a different spot.

Make a Tangential Change in a different piece of the code near your first change

You now want to repeat the same process in a different direction in the stack. Our previous changes went "up" to the UI. Now, you'll want to go "down" towards the data. Perhaps the next change moves your hardcoded test property to be populated by a piece of code in a data access layer you discover, and mapped to an API response body.

Now this might be the solution you see:

Get to the Edges

At this point the architecture has become clear. Make small changes to round out your data to come from your data store, and style your dummy text. This can get you to a full understanding of the architecture:

Build the smallest feature possible

Now that you can affect change everywhere that matters, you can make a pivot to delivering value. Pick the smallest requirement you can identify from your user story and implement it. That may be as simple as displaying the user's first and last name on the profile screen you are building.

As you now understand the architecture, implementing this will fall into place.

Get feedback

Once you have the feature working, you need to find out if the other requirements on your user story are still valuable at this time. Show a decision-maker what you have created. Ask them questions like these:

What do you think of this change?
Can we go live with just this functionality as-is?
Do we still want the other requirements on this user story as originally planned?

Iterate

You'll likely be asked to tweak what you've created or add more functionality. Now that you have knowledge of how to change the whole solution, that won't be a problem. It should be easy for you to start making tweaks, get feedback, and eventually go live.

Mermaid.js Diagrams in Azure DevOps Wikis

Sat, 30 Apr 2022 00:00:00 GMT

As I've been reading books this year, I've found that I've wanted to start capturing notes and thoughts about the reading I'm doing somewhere. I've begun to use Azure DevOps' Wiki functionality to write down the takeaways from my reading.

Azure DevOps has been a good tool for this purpose. There is a lot that I like about it. It is free, and I feel it has the right UX for a technical user such as myself. Wiki pages are defined as Markdown, which I'm very comfortable using. Additionally, each wiki is a git repository, which makes it very easy to track changes as time passes.

One feature I've recently discovered is flow charts powered by Mermaid. Mermaid is a markdown-style syntax to create diagrams and visualizations. A Mermaid diagram can be inserted on a wiki page simply by pressing this button in the ribbon:

This inserts the following syntax onto the wiki page:

::: mermaid
 graph LR;
 A[Wiki supports Mermaid] --> B[Visit https://mermaidjs.github.io/ for Mermaid syntax];
:::

That syntax creates the following diagram:

I find that forming a visualization is a way for me to cement my learning on a topic. I often best understand multi-step processes graphically. For example, here's the diagram I've created to help me capture my understanding of a thought process around waste elimination in a production process I read about in Taiichi Ohno's Toyota Production System:

::: mermaid
graph LR;
 A[Look at the efficiency of each operator] 
 B[Look at the efficiency of each line] 
 C[Look at the efficiency of operators as a group] 
 D[Look at the efficiency of the entire plant/all lines]
A --> B
A --> D
B --> C
C --> D
D --> A;
:::

I have found that Azure DevOps doesn't seem to support all of the available syntax from the Mermaid.js documentation. However, what it does support is very useful. I'm going to be looking for more opportunities to explore Mermaid in the near future.

If you want to play around with the technology yourself, feel free to use the Mermaid Live Editor by clicking on the diagram below:

Keeping my focus with Gitlab Workflow for Visual Studio Code

Sun, 20 Feb 2022 00:00:00 GMT

Last week, I wrote a post about Gitlab CI/CD and how I'm using it to deploy Azure Functions for a personal project. While writing that article, I discovered a fantastic extension for Visual Studio Code that I think is worth sharing. That extension is called the Gitlab Workflow for Visual Studio Code.

Visual Studio Code is often my IDE of choice on personal projects. Many of my personal projects use very lightweight technologies, such as Gatsby and Azure Functions, that are easy to develop without a full IDE. I don't want to spend a lot of money on something that I'm using to learn, so VS Code fits the bill. One of the benefits of using Visual Studio Code is that it has a rich extension ecosystem. This makes it easy to tailor my local development experience to the technologies I'm using.

Installation and Setup

Installing the extension was very easy. I found the extension using the Extensions Marketplace in VS Code:

I then created a Personal Access Token in Gitlab, which I could do on this page. I had to configure the extension to use the newly created PAT. That was easy - there is a command built included with extension to do that. I could find it in the Command Palette:

Using the Extension

I can use the extension on any Gitlab repository open in Visual Studio Code. The extension is smart enough to know when its features are available. I've explored two of the features so far.

Pipeline Status

My favorite feature of the extension is its integration with Gitlab CI/CD Pipelines. My projects initiate a CI pipeline on every commit to the main branch. Prior to using this extension, I would manually go to Gitlab in a web browser to check the status and make sure my pipeline was passing. With the Gitlab Workflow extension, I can now see a pipeline's execution progress and status in the VS Code Status bar. I value this feature as it allows me to keep writing code and not break focus. It is also great when I am working with one screen.

Validating `.gitlab-ci.yml`

Something that is always tricky with YAML-based DevOps pipelines is ensuring the syntax in the YAML file is correct. From incorrect usage of tabs, to the wrong syntax, there is some learning curve to this powerful paradigm. I have spent many hours of my life checking in YAML files for Gitlab and other DevOps tools only to find out that I did not write that file correctly when the pipeline executes. This feedback loop is slow and cumbersome.

The Gitlab Workflow Extension has a useful feature that allows .gitlab-ci.yml to be validated without pushing changes to the remote repository. Using it is simple. With .gitlab-ci.yml open in my active editor, there is a command available in the Command Palette:

This command parses the file, and will provide toast messages of any problems found:

Just scratching the surface

I'm just beginning to scratch the surface on the Gitlab Workflow Extension. As I learn more, I'll share my findings. I hope that this post introduced you to something new!

If you're interested in learning more, you can find the docs for the extension here. You can also find the extension's source code here.

Building and Deploying a .NET 6 Azure Function with Gitlab CI/CD

Sun, 13 Feb 2022 00:00:00 GMT

I use Gitlab for my source code for most of my personal projects. There is a lot that I like about Gitlab. There are unlimited repositories, and I can choose to make any of them private if I'd like. One of the features that I like most about Gitlab is Gitlab CI/CD.

Gitlab CI/CD is a DevOps tool that allows me to create pipelines that automatically build and deploy the code in the git repository. Pipelines are defined as YAML files with the name .gitlab-ci.yml, and saved in the root of the repository. There is a defined syntax to build these pipelines, and they get versioned in the same way that the rest of the codebase in the git repository does.

I'm working on a .NET 6 Azure Function for a side project right now. My git repository for this is hosted in Gitlab, and I'm looking for easy ways to deploy the code out to Azure. Visual Studio Code has an Azure plugin that allows for deployment to Azure. While this works, I must remember to deploy every time I commit a change to the master branch of my git repository, and I want to eliminate mistakes. I've created a Gitlab CI/CD pipeline that allows me to build, test, and deploy on every commit.

Just show me the code!

Here's the code for my .gitlab-ci.yml file for my project:

image: mcr.microsoft.com/dotnet/sdk:6.0

stages:
    - build
    - test
    - deploy

build:
    stage: build
    script:
        - "dotnet build"
    artifacts:
      paths:
        - bin/

test:
    stage: test
    script: 
        - "dotnet test"

deploy:
  stage: deploy
  script:
    - curl -sL https://aka.ms/InstallAzureCLIDeb | bash
    - apt-get install curl && curl -sL https://deb.nodesource.com/setup_12.x | bash -
    - apt-get install nodejs
    - npm install -g azure-functions-core-tools@4 --unsafe-perm true
    - az login --service-principal -u $APPLICATION_ID -p $APPLICATION_SECRET --tenant $TENANT_ID
    - func azure functionapp publish $FUNCTION_APP --csharp
  only:
    - master

You may be asking yourself: What does this all mean? Let's break it down, section by section.

The `image` property

Gitlab CI/CD pipelines execute in a Docker container. This helps enable repeatability of the pipeline execution. image: mcr.microsoft.com/dotnet/sdk:6.0 defines that this pipeline will run in the official .NET 6 Docker Image. This image is needed as my project is a .NET 6 project.

The `stages` property

Gitlab CI/CD has a feature called stages. Stages contain groups of jobs that execute. My pipeline defines three stages that will run in sequence - build, test, and deploy.

`build` and `test` stages

These stages use the .NET CLI to build and test the code for my Azure Function. I can use the .NET CLI in this pipeline because it is included with the official .NET 6 Docker Image. The features of the .NET CLI could be a completely different series of blog posts. It's an essential tool for modern .NET development, with many powerful features.

Other than the .NET CLI commands, the artifacts portion of the build stage is key to allowing us to deploy the Azure Function. The artifacts section states that the bin folder, which is where the built code resides, will be consumable in future stages of the Gitlab CI/CD pipeline.

The `deploy` stage

This is where the real fun begins! The official .NET 6 Docker Container defined in the image property is executing using Gitlab CI/CD's shared runners on Linux. Due to this, all of the commands in this stage are compatible with a Linux-based host. All of the magic in this stage is defined under script.

This script does the following:

Uses curl to download a Microsoft script to install the Azure CLI.
Install Node.js, which is a prerequisite for the next step
Instal Azure Functions Core Tools using the Node Package manager. I'm using v4 of the Azure Functions Core Tools as my function uses the version 4.x runtime.
Login to Azure using the Azure CLI (az) with a Service Principal. I created a Service Principal independent of my DevOps pipeline, and I'm using Gitlab CI/CD variables to pass in sensitive values.
Use the Azure Function Core Tools that was installed in the previous step to publish my function to Azure.

Wrapping up

This solution has allowed me to make the development of my Azure Functions faster and less error prone. There's a lot of cool technology to dig into further here. I hope this post gives you some inspiration on what you're working on.

P.S.: Credit goes to this post on dev.to and this post on Stack Overflow for providing me with information to learn how to set up my pipeline.

Things I Learned by Reading 21 Books in 2021

Sat, 22 Jan 2022 00:00:00 GMT

For a good portion of my career, I've enjoyed investing in my learning by reading books. What started as a membership in a developer book club at a previous job eventually turned into a yearly habit of reading two or three books about developing software.

Like most people on this planet, 2020 provided me with a lot of free time at home. Most years prior to the pandemic, I'd find myself traveling somewhere new. With travel not being much of an option in 2020, I started "traveling" mentally through books. I discovered the work of author Peter Hessler, who has written about his experiences living and traveling in Egypt and China, and I found that I could not put his books down.

In late 2020, I became hooked on the idea that I could use books to travel everywhere, even if the pandemic was preventing me from traveling almost anywhere. I started using an app called Goodreads to discover new books, and to keep track of books that I was reading.

As 2021 began, I found that my reading habits only grew. At the beginning of the year, I set a goal in Goodreads to read seven books in 2021. By the time the year was over, I had read 21 books! I've learned a few things about myself as I read throughout the year.

I'm not reading just about software development anymore

When I started reading more, I wasn't thinking just about my career. I used to think about reading as something that I had to do in order to pick up new technical skills. I quickly learned in my first handful of books read in 2021 that reading could serve so many more purposes.

I loved being exposed to the stories that some of these authors had to tell. Learning about Billy Baker's journey of making friends in his adult life in We Need to Hang Out: A Memoir of Making Friends brought a lot of relatable laughs in a time of staying at home. Kal Penn's autobiography, You Can't Be Serious, exposed me to the challenges he faced trying to break into Hollywood and avoid stereotypes. Braver Than You Think brought me on a journey of an eye-opening trip around the world with Maggie Downs.

I was also exposed to meaty content with lots of detailed information to consume. Working Effectively with Legacy Code by Michael Feathers is a book I should have read ten years ago. I was able to expand my technical skill set and reinforce many of my existing software development skills with that read. Reading Capital by Thomas Piketty taught me that I have the ability to make it through a 650+ page academic economics book.

Reading books unrelated to my career made it easier to expand my career

While I was expanding the type of books that I was reading, I found myself expanding the topics of professional books that I read about as well. The professional books I read in 2021 were mostly not about delivering software, but rather they were about topics that were tangentially related to the industry and startups. Expanding my mind to read about so many people and places for enjoyment also allowed me to read about many different professional topics for enjoyment, too.

Last year, I started to take a broader interest in some of the business aspects of marketing and growing software companies. There has been a feedback loop between learning and application of my newly acquired knowledge in my professional life with this pivot.

Last year, Zero to One by Peter Thiel crashed Startup Thinking into my brain, and the ideas will not be leaving anytime soon. I can no longer look at my career without thinking about opportunities to be the last mover into a given market, different styles of pessimistic and optimistic thinking, and the key question in the book: "What important truth do very few people agree with you on?".

80/20 Sales and Marketing by Perry Marshall got me thinking a lot about who my customers are in the work that I do, and how to effectively reach them using the Pareto principle. Drive by Daniel Pink, a book I wrote about on this blog, really got me noodling on what motivates me in my career.

From a professional perspective, the books I read in 2021 opened the door to a whole world that I wasn't living in until very recently. The topics I discovered last year by reading are helping me grow new skills professionally at a rapid pace.

I'm a sucker for gamification

The final thing I learned last year is that I am an absolute sucker for gamification tactics. Gamification, a recent trend in software to add video game style mechanics into non game software, is very present in Goodreads. Goodreads has features to track books read towards a yearly goal, as well as a progress bar that shows you percent completion of each book you're reading:

These techniques worked with me. I found myself enjoying seeing the number of books read increase, and the percent done metrics go up. I also found that having both the Goodreads app, as well as the Milwaukee Public Library app on my phone created a feedback loop that allowed me to go straight from book discovery in Goodreads to putting the book on hold at my local library. This allowed me to read more as I never learned about a book and then forgot to get it from the library and read it.

2022

In 2022, I plan to build on this habit that I formed last year. I've got more books I want to read this year than I could have ever imagined. I hope to build off what I learned in 2021 to learn much more this year. My reading goal for 2022 is 22 books.

Here's the full list of books I read in 2021:

Country Driving by Peter Hessler
Eric by Shaun Tan
Tightrope: Americans Reaching for Hope by Nicholas Kristof and Sheryl WuDunn
Here in Berlin by Crisitina Garcia
Zero to One by Peter Thiel
The Story of a Goat by Perumal Murugan
Fake Accounts by Lauren Oyler
We Need to Hang Out: A Memoir of Making Friends by Billy Baker
The Lost Continent by Bill Bryson
On the House by John Boehner
Giannis: The Improbable Rise of an NBA MVP by Mirin Fader
Drive by Daniel Pink
Working Effectively with Legacy Code by Michael Feathers
The Kite Runner by Khaled Hosseini
Behold the Dreamers by Imbolo Mbue
Capital in the Twenty-First Century by Thomas Piketty
80/20 Sales and Marketing by Perry Marshall
Behind the Beautiful Forevers: Life, Death, and Hope in a Mumbai Undercity by Katherine Boo
Braver Than You Think by Maggie Downs
You Can't Be Serious by Kal Penn
State of Terror by Hillary Rodham Clinton and Louise Penny

Don't Skip the Hard Parts

Sat, 16 Oct 2021 00:00:00 GMT

How do you grow in your career? You have likley asked yourself this question. You probably want to get to the next rank or job title. You may want to obtain a higher salary. Usually obtaining this requires learning some new skills and taking on more responsibilities. I've asked this question myself a few times in my career.

You have options with regards to how you go about growing. You can ask your employer for a job description for the next rank up. You can shop around on the job market to see if maybe another company is interested in paying a little more for the skills you already have. These are valid options, and they might get you some of what you're looking for. But, how do you ensure that you actually grow?

You grow by confronting the hard parts of the job - head on.

Often when we're looking around on the job market, we're looking for something a little cushier. We want to avoid that crappy waterfall process/annoying technology/problem du jour that is bugging us at the current gig. Maybe find a place with free lunches or standing desks. It's good to look for those things in a job. But in order to truly grow, we need to have hard problems to solve when we get there.

If we get to a place that already has perfect tech, no problems delivering, great communication between stakeholders, and amazing sales, there probably won't be much to stretch you when you get there. There won't be any hard parts to the job. Clock in, write some code, clock out. Where is that going to get you in the next five years when you're looking for something new again? What kind of story will you have to tell? Everyone who is a software developer for more than a week is going to deliver some code. How will you stand out?

Sometimes the hard parts come to you, and sometimes you have to go find them. Before I knew I needed to find the hard parts, they seemed to come to me. When I was a junior engineer, the hard parts were a daily part of the job. Getting the code to work? Hard part. Understanding the task at hand? Hard part. Deploying to production by myself?!? Really hard part.

Over time, many of the things that were hard have become easier. With practice, I've been able to build the muscles of delivering working software. I've found that as I've gotten better delivering software, I've had to look around for new hard problems. At first, switching to a new tech stack was a hard problem to tackle. Then I switched technologies a few times and that stopped being so difficult. Code problems are code problems, dependencies are important to manage, how to deploy is something to understand early. All of those problems started to look the same, no matter what the language or stack.

You may have reached this point yourself. If you're at this stage, you have to be extra intentional about growing yourself. Many developers are shielded from the bigger problems to solve within a company. You may be viewed as someone who just codes what is needed for the business. In my experience, to grow beyond that point, you have to find the unsolved problems in your company that you can fix.

You can go about this many different ways. It may involve looking outside your current team, department, or even employer. You need to start talking to others and listening to their problems. Book lunches or catch a coffee with people you wouldn't normally overlap with. Catch a beer with a sales guy. Talk to the Product Manager you see once a quarter. There is not a formula for finding these problems - you just have to take initiative to look around for them. Once you find these problems, you may be doing them alongside your day job. An hour here, a Saturday morning there. Over time, if you deliver value, you'll find a way to make them part of your day to day.

If you're not finding these problems in your current employer, it is probably time to look around. But don't just look for that cushy office or pretty tech - look for the interesting problems. For senior engineers, they are often the key to real personal growth.

Book Report - Drive by Daniel Pink

Sun, 26 Sep 2021 00:00:00 GMT

I recently finished reading Drive by Daniel Pink. This has been on my list of books to read for a long time. Drive has come up a couple of times over the last few years of my career in conversations with coworkers. After having a hallway conversation recently at work about the book, I decided to pick it up and give it a read.

The book is split into two different parts. The first part of the book is called "A New Operating System." Pink writes about three different types of motivation in part one. He calles them Motivation 1.0, Motiviation 2.0, and Motiviation 3.0. Motiviation 1.0 is about our human biological needs for survival. Motiviation 2.0 is how we can be motivated by external rewards and punishments. Motiviation 3.0 is a recently discovered style of motivation, called intrinsic motivation. Intrinsic motiviation is where we can be motivated by the work we are doing and the enjoyment of it.

Part two of the book is called "The Three Elements." In this part of the book, Pink describes three elements that are needed in order to be intrinsticly motivated by the work that we do. Those elements are autonomy, mastery, and purpose. As he introduces the reader to these three elements, he explains why they are needed in order to enable a Motivation 3.0 mindset. As I was reading, I felt that the first part of the book felt like Pink was describing the theory behind intrinsic motivation, and the second part felt like he was describing the application of it.

I feel that there was a lot of very relevant topics in this book, and that many professionals could benefit from reading it. Many professionals find ourselves working in environments that have a "carrot and stick" reward scheme. Finish the task before the deadline, receive a pat on the back. Finish it late, and be told you need to be faster. While that kind of motiviational scheme can work for some routine work, the work of many professionals is increasingly more dynamic and requires different, self driven motiviational approaches. Pink is advocating for more adoption of those approaches in Drive.

Drive makes a great psychological pair to the concept of owning your career that is often found in the Software Craftsmanship space. I think it is a great read for someone in a technical profession that is looking to better understand what makes them want to get to work in the morning. I recommend reading this book.

A Recap of Summerfest Tech 2021

Thu, 09 Sep 2021 00:00:00 GMT

Yesterday I had the chance to checkout Summerfest Tech, a local event held here in Milwaukee focused on the tech ecosystem in our region. I've heard this was a good event in previous years, and I was excited to attend this year's sessions.

Summerfest Tech took a hybrid format approach to their event this year. All of the sessions in the morning were available on an online platform, and the afternoon's sessions were held on the Johnson Controls World Sound Stage at the Summerfest grounds.

This marked my first time attending an online conference. I have missed in person conferences and meetups during the pandemic. While the online format didn't completely reproduce the same level of interactivity as an in person setting, it did a good job of enabling connections between attendees. There was a virtual event hall, sponsor booths, and a chat feature that I was able to use to meet and talk to some of the other attendees.

The three sessions I attended in the virtual format covered a broad range of topics, including characteristics of a great tech town, how to increase diversity in our tech workforce, and strategies to help start up companies. Many of the speakers touched on the quantity of great talent we have today in Milwaukee, and that the market for tech jobs is only going to grow. One takeaway I have is a fact that Kathy Henrich of the Milwaukee Tech Hub shared: there are going to be 31,000 tech jobs open in our city by 2024. There will be no shortage of opportunity here.

In the afternoon, I made my way over to the grounds to meet others in person and take in the afternoon programming. The afternoon had more of a startup focus. A lot of the afternoon was centered around a startup pitch competition. Six startups gave a pitch to a panel of judges, who then asked them questions about their business plans and the potential growth opportunities in front of them.

My favorite pitch came from the startup Debtle. Debtle seeks to solve the problem that paying off debt in collections is high friction for all parties involved. They have developed a software solution that allows those collecting debt to work with those who owe debt to negotiate an agreement and pay through their platform. While they were my favorite of the group, I also enjoyed hearing about Investii as well. Investii has developed a software product that helps individuals save money and budget effectively.

I rounded out the day by talking to some of the individuals at the event, learning about their organizations and the problems they are solving. I also happened to run into a former co-worker, and it was great to catch up with him as well. It was nice to get out and talk with like minded individuals in our tech community. I hope there are more in person events opportunities to do that soon.

A First Look at Hot Reload in Visual Studio 2022

Tue, 31 Aug 2021 00:00:00 GMT

One of the recent episodes of .NET Rocks was very interesting. Carl Franklin and Richard Campbell interviewed Dimitry Layalin from Microsoft. He is a Program Manager working on multiple products, including Hot Reload, a new feature in .NET that allows for code to be changed at runtime while it is being debugged.

It was very interesting to hear him talk about the journey they have gone on at Microsoft about how they developed the feature, leveraging existing features of Visual Studio's Edit and Continue functionality, and how C++ development in Visual Studio lent itself well to the functionality. This episode has made me eager to check hot reload out for myself, so this week I downloaded Visual Studio 2022 Preview 3 to give it a try.

The Happy Path

After I finished installing Visual Studio, I decided to spin up a new .NET 6 Console Application using the built in template. .NET 6 is also in preview, and I figured this was a good chance to try it out as well. Using the new, simplified console app template, I created an application that accepts user input infinitely. I started up the debugger by pressing the familiar play button in the ribbon, and set a breakpoint.

Applying changes to the running code was a breeze. I changed a line of code in the application, and I went ahead and pressed a new button in the ribbon that allows for changes to be applied to the running application:

Within a second, I saw the following message appear on the bottom of my screen:

Finding the Limits

As I have sometimes found myself working in a legacy solutions, it is important to me to test out the limits of a new technology. I wanted to see how hot reload responded when it was used in a remote debugging scenario. I find that the remote debugger is a very valuable tool when the solution has many build errors that are due to knotty external dependencies, or when the running application is not entirely recreated from the code base in the Visual Studio solution. I was interested to see how the folks at Microsoft handled the hot reload functionality when interacting with a remote application.

I knew that this test was almost certainly going to end in some form of failure. Being able to change a remotely executing application from an IDE would be impossible magic. The running application is not guaranteed to be in a place where it can be modified, and even if it was, changing it would be a deployment of the newly compiled code to the server, which would not be desired in a development scenario.

I built my new application in debug mode, and started the executable locally by finding it in the bin folder and double clicking on it. I clicked on Attach to Process under the Debug menu in Visual Studio as usual to attach to the running process. Debugging worked as it normally does.

I made a code change, and went ahead and pressed the Apply Code Changes button on the ribbon. As expected, Visual Studio couldn't apply the changes. I was presented with the following dialog:

I decided to press edit, which put the following error in the Error List:

At this point, I'd need to rebuild my application to be able to remote debug any newly coded changes.

Final thoughts

I think Hot Reload is a very valuable feature. For a correctly architected application that can be run locally, it is a game changer. Being able to nearly eliminate the feedback loop between writing a line of code and knowing whether or not it worked will allow for dramatic productivity gains for those stopping and restarting applications between changes today.

P.S.: If you're interested in the console app, you can find it on my GitHub page: https://github.com/philbo87/HotReloadTestApp

Look at the Lightbulb

Sat, 21 Aug 2021 00:00:00 GMT

I've been reading Working Effectively with Legacy Code by Michael Feathers recently. I'm currently about half way through the book, and there has been a lot of good information so far.

The chapters I've read so far have largely been about changing legacy software via refactoring. There have been many times in my career that I've had to find ways to maintain and extend legacy code. I find that working with legacy code is a lot like taking care of a garden - the key is to do a little bit of work each day to nurture it and make it a little bit better. Overtime, this "tending to the garden" results in software that is easier to maintain and test.

Chapter five of the book focuses on tools that can be used to help enable changing of a code base. It introduces concepts like unit tests, mocking objects, and automated refactoring tools. While I find lots of value in creating unit tests and following techniques that help make code easier to test, I personally find a little bit of refactoring can have a great ROI when attempting to understand a newly acquired code base.

Many IDEs contain lots of automated refactoring tools. I strongly recommend taking a look at them. Both Visual Studio and Visual Studio Code will hide suggestions behind a lightbulb that shows up to the left of the line of code that is currently being edited. You can see the suggestions by clicking on the lightbulb, or via a keyboard shortcut (Alt + Enter on my machine). There are many suggestions behind that lightbulb worth following.

Two of my most used automated refactoring tools are Extract Method and Extract Interface. Extract Method in Visual Studio allows for a few lines of code to be extracted into its own private method in the class that is currently under edit. This helps me ensure that my methods follow the Single Responsibility Principle, and that the code is easier to read. Extract Interface allows for an interface to be created from a class that does not currently have one, and that often is the first step to breaking a dependency and putting a piece of code under test.

There's a lot on this topic that I will continue to share here on my blog. In the meanwhile, I'll leave you with a talk that I saw once by Sandro Mancuso that I think demonstrates the value of using automated refactoring tools. In this video, he refactors an old piece of Java code and puts it under test. He fully embraces the tools his IDE offers the entire way.

The Proof is in Production

Wed, 18 Aug 2021 00:00:00 GMT

How do you know that the work you do has created value?

You have a customer for the software you deliver. Ideally, someone is attempting to use the solution you work on.

You may have product owners, product managers, project managers, business analysts, sales teams, and more between you and the customer using your product. Or, maybe you are consulting and you work directly with your client.

No matter what the working arrangements look like between you and the end users you serve, there is a good chance that all folks involved want to be sure that a great solution is being delivered. There is almost certainly great care between all parties involved to make sure things are just right, that they are done correctly, and that the customer is being served well.

This amount of care can naturally create disagreements and tension. Chances are, if you've been delivering software for more than a few months, you've started to hear questions like these:

What is the right thing to build?
How should page look?
When is it going to be done?
Do we need to architect this solution differently?

There is a simple solution to these disagreements: Deploy to Production. Deploy early. Deploy often. Deploy as much as possible.

Deploying code to production solves nearly all disagreements. By surfacing the solution to users, customers can get value immediately. The sooner users click the buttons on your web app, the sooner you and your peers at your company can find out if people can use the solution to solve their problems. Or, the sooner you find out that choosing hot pink was not a great color choice for that button! 😀

Of course, none of this matters if you don't apply the learnings gained from the deploy to production to a future effort. You have to be intentional about using the knowledge gained. You may learn that the customers love the solution and that you don't need to add more to it - and that is great! Or, you may learn that it is time to go back to the drawing board and start over. That's OK too. Likely, it will be somewhere in between. No matter what you learn, the key is to make the decision actively about what to work on next based on that feedback, and not passively based on a long list of old backlog items.

If you don't deploy to production often, ask yourself why that is. Is it something you can change with a conversation with your team? Is it something that was decided outside your team? Can you talk to that person?

There may be lots of reasons that you don't deploy frequently - fear of change, infrastructure limitations, cross-company communication issues are just a few that I have experienced. Don't let that stop you - keep looking for the opportunity to try frequent, iterative production deployments. Products with lower stakes, or off hours deployments may be good places to start in your organization.

Do not let one roadblock keep you from finding a path to an iterative approach. Ultimately, deploying frequently on one application is better than infrequent deployments. And if you can deploy frequently on one application, eventually the learning gained from that will be contagious in your organization and solve the disagreements on going to production often.

That Conference to This Moment

Sat, 07 Aug 2021 00:00:00 GMT

In 2015, I found my career in a transitional moment. I had just taken a job in the .NET space for the first time after spending a few years working in Enterprise Java Beans. I was being exposed to modern tech and practices at a pace I had not encountered before. By time early 2016 rolled around, I found myself leading a development team for the first time. In a twelve month time span, I went from valued individual contributor working on legacy applications to leading a team working on solutions for the modern web.

In the middle of 2015, these changes in my career crystallized for me with a trip to That Conference, in Wisconsin Dells. When I look back at that time in my career, my trip to That Conference was probably the moment that I had realized things were changing. My trip to That Conference that year was the first time I had been exposed to ideas outside of what my employer had to offer.

These ideas shaped my approach to work in a big way. I started to become more invested in the work that I was doing, I began to develop opinions about what the right way to approach a problem. I began to care about finding ways to get the team that I was working with to gel together, instead of worrying about me just getting my work done.

That feels like a lifetime ago now. I've continued leading teams. I have switched to a different employer along the way, and focused more on organizational growth. The tech I'm using is different than it was then. The problems are different as well. I've gotten the opportunity to work with a lot of great people over the years, and they have continued to shape my approach.

I've found myself in a retrospective moment as of late. I had the opportunity to go back to That Conference this year with some of my colleagues from Layer One. This trip has made me think about how much I've changed as a leader. I find myself in a moment again where I feel that much is currently crystallizing for me in what I do for a living, and the things that I think are important.

I've been sharing a lot of the things that I think are important in delivering software lately on LinkedIn. It has been a great experience. I feel I have a lot of value I can bring to my network with the ideas I have to share, and I've had some good conversations on the platform. However, I can only share so much in one post - a few sentences, or maybe a couple of paragraphs.

My recent trip to That Conference has made me realize that it is time to start writing in a longer format. The ideas I want to share - both technical and team related - are too many to fit into a series of posts. For the longer ideas, I'll start sharing them here on my website.

This is going to be an experiment for me. I'm taking an iterative approach as I develop my website. Expect change along the way as I learn more about the problems I want to solve by writing. I'll be inspecting and adapting as I go. If you are reading my posts and have thoughts about what is working, and what isn't, reach out! I'm interested in hearing from others about what content is most valuable.