Murph Programming

Learning This Wasn't Easy

Written on July 15, 2019
Updated on August 19, 2019

I wasn’t really planning to write out another Crossfit Programming post for quite some time, but a giant overflow of rich thoughts came to me today when I was suffering through what is the annual Memorial Day Workout no matter what Crossfit gym you’re a part of: [The Murph].

Odds are, if there’s one workout you’ve heard about from Crossfit folk its probably The Murph. Reason being: Its really hard and pretty much everyone gives it a shot at some point. The workout is as follows:

  • 1 Mile Run
  • 100 Pull Ups
  • 200 Push Ups
  • 300 Air Squats
  • 1 Mile Run

Often times in under 45 min or an hour. The time cap depends from gym to gym. The point of this workout being: Its really hard. Even folks who have been doing Crossfit for quite some time have a hard time with this because there’s a a second level to it: With up to a 20 lb. weighted vest.

Why Talk About a Workout That Dominated You?

What’s interesting is that most really fit folks can knock out The Murph in 45 min to an hour and take a really long nap afterwards. However, present the element of the vest in there and its like a reset button on their ability to tackle the workout. To me, this is why the Murph has a really long replay value. Its like trying to summit a mountain. Every year, you’ve got another chance to get closer to actually completing the workout given the time cap or another shot to shave off your previous record.

In my mind, The Murph is like a skill aptitude test for how in shape you are. You can look good or feel like you’ve got muscle, but how do you fare when you have to put your body to the test? Its one of those challenges that pushes you in a good way and is totally normal to not finish. The key is pushing yourself and improving from your last attempt.

This got me thinking about programming. We often design programming interviews and challenges like The Murph. We say vague things like: “We’re trying to see how you would solve the problem even though is designed to not be able to be finished. “

Those interviews can sometimes be really good or really bad depending on how they’re run. But I want to dig into how we can start shattering a culture of “I have to dominate and completely solve this problem or I’m a failure mindset” that we often see in programming.

Growth is A Process

Suffering through The Murph reminds me that growth is a process. I want to continue to grow each and every year, but its often not a pass / fail kind of grade. Some problems or tests deserve to be of the pass / fail nature, but I believe that the real struggles are ones that don’t necessarily have a result. They just have a time and quality factor assigned to them.

Here’s another thing about The Murph, you can scale it as needed. I found a pretty interesting way of breaking that work down today. It’s as follows:

Start with an 1 mile or 800 meter run depending on your aptitude

Then proceed to do 25 rounds of the following:

  • 4 Pull Ups
  • 6 Push Ups
  • 12 Air Squats

Around the 45 min cap, if you’re not on the verge of passing out, stop where you are and attempt another 800m or 1 mile run. Your time will be whenever you finish that run.

Approaching the problem like that today, it took me 48 minutes to get through 10 / 25 rounds capped with 800m runs. Reading this now, I feel like there’s room for improvement. Looking back in my memory of it today, I have no idea how I even made it through 10 rounds. It was intense to say the least.

While effort put towards the problem is hard to measure, I now have a baseline to look at next year or next time I attempt the Murph. I want to take a spot to start pushing forward with my development and not just to stay put in.

The cool part of this is I can’t say I “failed” at the Murph. I showed up on a holiday and took a shot at one of the most intense workouts out there. I’m not quitting working out after doing the Murph either. I’m showing up to the gym again this week. This is because something deep in my bones believes that growth is a process. There will never be a point where I completely dominate all of working out. They’ll always be a new level or thing to conquer. However, I want to rest easy at night knowing I’m moving forward and going after that next milestone.

Ok. So, What’s That Got to Do With Programming?

I used to have a hard time with leaving work. Maybe you have too. My instinct wasn’t as much to hustle for x hours more than your peers and then profit. It was that I had a hard time leaving problems unfinished at the end of the day. I had to get to a “good” stopping point. While its one thing to run this kind of life as a single person, having this habit in a family causes a bit of strain on your relationships. I never felt like a perfectionist but rather someone who was a bit over-eager to complete work. I valued resolution and shipping things over having a “perfect” feature.

So, how do you start breaking this kind of behavior? I didn’t realize it until recently but going through workouts like The Murph were breaking my perseveration on having “complete” solutions or work.

We have to approach work every day knowing that we’re striving to get better at what we do. You’ll often see - especially developing software - that the bigger a feature gets the more vague the state of being “finished” becomes. I actually am currently on the verge of finishing a slew of features that have taken up the past 6-8 months of my time. Bigger units or work are more abstract and that’s ok. However, we’ve got to come into work with a mindset of getting better and doing good work and sweating less about how we compare to others or when something will be “done”.

There’s a cadence or guidance that we accomplish our work by - just like The Murph has a round system or a limited time cap. However, I’ve been leaving work a lot happier these days because I know that I’m shipping small pieces of code that are making things better and closer to completion each day. Even the frustrating days are now a bit lighter because I’m able to realize and appreciate the slow march of growth. Its so much more of an intention rather than a resolution.

Leaving in a good state of mind from work can be life changing. You engage people and situations much more fully because of this. It helps take the load off of your body and soul. Its hard to explain, but living in a more clarified state of mind like this has helped me make some really great strides towards where I want to go in my life and career.

Investing In Your Development Time

Written on July 15, 2019
Updated on August 19, 2019

A week or so ago, I [tweeted] some thoughts I’ve been having recently about work. I want to take some time to explain and expand upon those thoughts.

Your Daily Work Time is Finite

To refresh everyone on what exactly I wrote about, I talked about how I often spend my development-specific time at work. This means time that I’m actually sitting down at a computer and coding. Never mind the expanding role of more business-oriented needs. Those deserve writings of their own.

So, let’s say the average developer at your company is spending 20% of their time dealing with more “business-like” things - meeting with folks; getting feedback from users; following up on all the emails. The rest of that time, ideally, is going to probably go towards development of actual features and products.

Assuming you work around 40 hours each week, we’re looking at 32 or so hours that you have available to do development things with. How do we best spend them? I’ve found that so many companies have an endless amount of work to tackle, so the decision to work around 40 hours a week is purely a choice. Yet, there’s never enough hours we can work. It’d be safe to assume that no matter how much or how long or how hard we work, we’ve got to figure out how to best maximize creating things on a 40-ish hour work week.

I’ve found that I often split that development time up around a few themes:

  1. Writing features
  2. Fixing existing Bugs
  3. Building better confidence in my features
  4. Communicating the work I’ve done
  5. Designing Work I plan to do

So, what do these things actually mean and how does understand them help me better make use of my time?

In short, we often have to shuffle around prioritizing them based on our current work situations and needs. Sometimes you need to spend a lot of time writing a feature. Other times, you need to really invest some time better communicating what you’ve done and why you’ve done it.

I’ll break each one of these down and try to attach some practical value and instructions for each.

Writing Features

Products don’t get written without features. They’re the main vehicle of pushing things forward with your development team. They’re often what your team is judged by as well. So, why not just write features all the time?

Well, in short, the more forward progress you have the more stability you need to support it. If we push too forward with the development of our product, we often might find ourselves at the helm of something that’s really feature-rich but it isn’t incredibly usable. Even if you’re developing with a high level of precision and skill, there’s often times a need to invest in other things.

You should prioritize features when you feel like the product you’re adding onto is stable enough to support the feature you want to add. Think of a tree branch. You want to grow something that can be supported by the source that its growing from.

Fixing Existing Bugs

Every piece of code your write is going to have bugs. Some are more obvious than others - a syntax error vs a usability complaint. We’re always going to have bugs sitting at our doorstep waiting to be resolved. However, we can’t ignore them either.

The more bugs you have, the less stable your application in considered. The opposite applies for less bugs. While different engineering cultures prioritize the elimination of bugs in different ways, consider what I wrote about features above. We want to have a stable application to write features off of and eliminating bugs is a really practical way to get there.

Building Better Confidence in My Features

Sometimes work doesn’t fall into developing features or fixing bugs. Its often this weird combination of the two, where we’re building confidence in the things we’ve built or are building.

Here’s what I mean by this.

When we’re developing a feature, we or a small group of people are likely the only folks interacting with it. While we may all be really bright and good at discovering things, we eventually have to think about scaling out the feature to others. If its a developer-based tool, we need to think about getting it to work on other folks machine’s. If its a customer-facing feature, we need to think about how we can better improve their experience when we roll it out.

Recently, I remember I had been working on this Serverless Application project. I knew how to develop and deploy it in one environment. But I needed to collaborate with others and figure out a way to implement and scale it in multiple environments (development, staging, and production). I would classify this kind of work as building confidence in my features. We often think of that work as more DevOps-like. However, I’d argue that every developer will find themselves having to grapple with similar issues every once in awhile.

Communicating the Work I’ve Done

The obvious question that arise from this is: “Isn’t this business-related?”

While the answer can be yes, I’d argue that its very much a development-oriented thing as well. While there are channels we communicate through that tend to be more business facing (email, messaging, JIRA), there are just as many sources that are development facing (documentation, code comments, pull requests).

When was the last time you really put at lot of effort into documenting your changes in pull request? I’m talking about stuff that’s beyond: “I changed these files and now it works.”

We often view this stuff as a waste of our time and I’ll often agree with that. Yet, there comes a time when Pull Requests, Code Comments, and Documentation are going to be the legacy by which other folks understand your features and code. I believe its incredibly important to not only communicate what you’ve done for the purpose of having others understand how significant your work is, but also to easily onboard them to help with it.

Most projects start off with just a few people and scale to numerous others after they’ve found success. We need to best communicate that internally as well as externally.

Designing Work I Plan to Do

I’ve often had a heart for graphic design and art. I used to think that programming was more of a cut and dry science that isn’t designed. However, I was easily proven wrong after some time professionally developing.

There’s an immense value in trying to design your ideas before you implement them. Whether that means sketching out something on a notepad or just writing down what you plan to do, there’s a lot of help in planning what you’re going to attack before charging at it.

Design helps me understand what I’m about to do, but it also offers me a break from the grind of staring at a programming screen.

The Trapese of Open Source

Don't Look Down

Written on July 15, 2019
Updated on August 19, 2019

The dominance of open-source software in modern software development is staggering. In my past two jobs, 90% of the tech stack used has open-source.

The concentration of open to closed source is a really stark contrast to about 10-15 years ago when propriety software development tools and frameworks came with thousands of dollars in licensing and training. Developers didn’t have much power to change the tools they used. They had to accept what the development team at /Company X/ thought was the best idea.

In those days, open-source software just considered dangerous and risky. Nobody would expect incredibly important web apps to be based off of code that’s available for free and to the public. Sure, the idea of ditching those expensive licensing agreements seemed attractive. However, it was always viewed as too risky.

Flash forward to today, and we see that developers and businesses have come to embrace the ideas of open-source together. As a result, the barriers to creating excellent work have been lowered. You don’t need a giant software licensing budget to create a great idea anymore. This has lead to some really great ideas and websites over the years.

As awesome as it is to see the shift to embracing open source, a lot of folks have assumed that not much has changed on the front of how software is developed. I want to explain how these folks are missing the big picture a bit.

Embracing Open-Source

I create a lot of software using Ruby on Rails. Its a great framework with an excellent community of people. Its stable, secure, and honestly a ton of fun to work with. Rails, atomically, is a framework made up of a bunch of Ruby libraries (called gems). The framework itself is also a gem. In short, Rails is a gem made of gems.


An interesting freedom of Ruby on Rails is that it provides the foundation for you to build stuff on top of it with. Every Rails project is going to have ton of more external dependencies. Who makes those dependencies, you ask? Literally anyone!

There’s a ton of freedom that comes with this. Rails says: “Power to the people! Build the ecosystem you want!” Its an interesting shift away from the olden days. With the freedom of being to develop anything for the platform, you also lose the consistency of tooling.

Here’s what I mean by consistency:

Let’s say you’re a die-hard Microsoft shop. You make really great software for Windows computers. When you’re using Microsoft’s robust suite of software products, you’re getting the real deal. Pretty much everything you’ll need to written and provided by them. Sure, you’ve got your third party tools out there, but you’re ready to ditch them the minute Microsoft comes out with something that fills that need.

The advantage companies like Microsoft provide is that you basically have everything you need to develop an app from them. However, you also have a quality standard from them that you can trust. You don’t have to ask the question: “Will this work properly?” Instead you get to ask: “Do I like this?”

With Open Source software, we have to ask both of these questions. I’ve used a lot of open-source projects that I love, but don’t really work properly. On the other hand, a lot of open-source projects that work properly aren’t a lot of fun to use. With open-source, you find yourself adding in projects and dependencies that haven’t even hit 1.0 yet. Its a weird feeling, but it ultimately makes you more aware of the things that you’re using.

Managing Open-Source

A lot of developers have grown to see this shift from closed-source to open-source. They can see the advantages and disadvantages of both. However, I think a lot of us often miss the implications of how we manage software teams under this new world order.

We can no longer trust the developer’s toolkit as gospel

We can’t be assured that our development toolkit is the best fit for our software approach. When using open source tools, anything can change. Things can be improved, but things can also become quickly outdated.

Frameworks tend to do a good job at keeping up to date. However, the libraries that exist on top of these frameworks often do not. This can be very problematic when a trusty worth library you use doesn’t update from a depreciated framework API change. Sometimes monkey patches can work, but they should be a temporary solution.

We have the power to solve our own problems.

The problem listed above can seem pretty defeating if we do nothing about it. However, the best part about open source is that we can contribute back! It would seem like a great rule of thumb to invest in the projects that you frequently use.

Not only does giving back help others, it can also be the means for better solidifying the community around those dependencies. When you put a new idea, patch, or feature out there, others get the chance to take an input.

Its important to realize that these things can and should happen during business hours. It shouldn’t be presented as: “Contribute to open source! Made your tech stack better by doing it on your own time!” If your company is paying developers to utilize open source technologies, it should also pay them to help improve it! After all, having the ability to improve the frameworks you use is pretty dang awesome.

Staying Up To Date Is Essential

With open-source, you have to stay up to date. This isn’t much different that using closed-source. However, the advantage that you used to have with closed-source software is that you’d often be provided a series of patches together in updates.

With open-source software, the initiative to stay updated and secure is up to you. Nobody is going to clean up your mess for you, you’ve got to stay on top of bugs, exploits, and depreciations.

Be Creative

With open-source, we’ve got the ability to control the software that we create with. We’ve got a unique chance to be creative with the solutions and methods that we create with! The best ideas that have appeared in open-source have been battle-tested ideas from companies, given freely to the public. Rails came from the initial development of Basecamp. Twitter gave designers Bootstrap to help them create amazing user interfaces.

We’ve got so many opportunities to share the exciting things that we create, I believe open-sourcing is something you should not only consider, but embrace! Here’s to the future to software by and for the people!

Small Team, Small Process

Written on July 15, 2019
Updated on August 19, 2019

There’s this notion within the software industry that a company’s process usually scales with its team size. While this certainly makes sense on a lot of levels (instances of managing 5 programmers vs managing 25), we tend to prescribe a need for a better process to companies who are going through some tough growing pains.

However, I believe ants lead to an interesting secret about how we should structure our teams. Ants can lift weights far exceeding their own personal weight (due to a strong exoskeleton). When multiple ants organize, small teams can lift a significant amount of weight. This law is certainly scalable in a realistic sense, but its beauty lies in how important small teams are.


You might roll your eyes at me while reading this section. Maybe you’d fire back: “We already have a testing framework, Taylor!”

Yet, the true question is: Do you leverage your testing framework in the best way possible?

Here are a few good questions to ask yourself (in the Rails space):

Do you separate your JSON and HTML controller tests? Do you separate tests by namespace?

Do you provide other developers means to replicate the data relationships in your local app?

Is your master branch “clean” in the sense that all tests are green?

How often do you write tests? Is there a pattern to when and how your write them?

In a perfect project, all of these (and more) would probably be covered. However, there’s a great enemy of testing: deadlines.

Many of us would rather have an untested “complete” app than a fully testing “incomplete” version. This mainly has to do with the viewpoint of the consumers and clients: their enjoyment and payment is initially based on a delivery date. Its not until later that they begin to notice the hidden grime within the product. So, theoretically, you could fix all the glaring mistakes before the client / consumer notices.

Sounds easy, right?

A lot of companies go along with this idea, even Apple. There’s a running joke about products saying that: “version 1 always sucks.” This certainly isn’t entirely false. Every product is always going to have problems and improve over time. But what about products that die an early death because of the overwhelming amount of flaws?

Milestones can certainly help!


In my opinion, milestones get lost within the Agile Development world. While discussing the effectiveness of Agile Development is a way bigger conversation, milestones often come off as one of many decent advantages of being “Agile”.

However, what milestones do effectively is offer up a global grocery list of items that need to be delivered in some form before a certain date. If you structure your milestones to be knock-out major features early on in the development cycle, it leaves room for developing auxiliary and vague features later.

Release Candidates

Release candidates are essentially milestones after they’ve happened. The reality is: not everything from your planned milestone is going to end up in a release candidate. However, release candidates can be a lifesaver of frozen code. Think if some sprint went horrible wrong, and you can’t release new features to a client. You could still deliver a release candidate that meets more quality QA standards.

Pushing features directly from a commit into the live server is a really dangerous thing. Sure, you can trust fellow contributors and commits. However, testing often can’t keep pace with rapid development close to a deadline. We need release candidates to give us a physical representation of what’s stable and what’s not!

I love what Github offers in terms of open-source versioning. If I wanted to be “cutting edge”, I could download the master branch of the project and venture into the great unknown. However, if I wanted to use an older version of a project, I could download a release file from the “Releases” section. Docker does this particularly well with Docker, Compose, and Machine.