Tighten Your Feedback Loops

Image for post
Image for post
Photo by Jason Corey on Unsplash

Not that long ago shipping software was a physical act. Software was put onto disks and shipped to customers and retail outlets across the globe. Upgrades were generally not possible. Customers would wait until it made financial sense to buy the next version. Bug fixes didn’t happen. The cost of a bad release was high. Millions of dollars in labor and physical products wasted. Headlines about the incident would damage your company’s reputation. Customers would be hesitant to buy again from you.

The internet changed this. Rather than pushing bytes to a disk, we could push bytes over a wire at the speed of light. This change in the deployment of software enabled Software as a Service companies. These companies changed customer expectations. Customers didn’t want to wait for years for a new version of their software, they wanted it now. They came to expect this as the norm. …


Image for post
Image for post
Photo by Giammarco Boscaro on Unsplash

Anyone who has worked in software long enough has learned or developed maxims that inform how they approach their work. These are distilled experience. They encapsulate what has worked and what hasn’t worked. These are the maxims I follow when writing software. I won’t pretend that any of these are new or original. I learned them from others more experienced than myself. All have helped me be a better engineer and deliver higher quality software, faster.

Don’t start until you know what done looks like

The first thing you should always create when building something new is a way of objectively measuring how close to done you are. It might be metrics, it might be tests, but it has to be something that isn’t subject to interpretation. Without those in place at the beginning you’ll always be playing catch up. …


As you progress in your career as a software engineer you gradually are tasked with solving larger and more complex problems. Eventually you are tasked with designing systems or modifications to systems that require multiple developers to work on and may take weeks or months to build. These problems, generally referred to as system design problems, are not the type that are taught in school. …


Image for post
Image for post
Photo by Ferdinand Stöhr on Unsplash

This month it will have been ten years since I started my first full-time software development position. I thought it might be good to take a break and reflect on some of the main lessons I’ve learned in that time that continue to benefit me today.

Lessons

Assume nothing, Prove everything

Most of the biggest mistakes I’ve made have come from making and acting on bad assumptions. Sometimes it’s as small as “there is no way this line of code will fail” or “I know exactly how this function works.” Other times its bigger, like expecting another team is going to fix a specific problem or thinking an entire system works a certain way. In all cases it’s the same pattern. …

Corey Sunwold

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store