It’s normal for engineers to want to move fast, especially at a startup.
After all, if a company hopes to grow and improve their product, there will be a mountain of work that the technical team needs to get done. The faster they get through their to-do list, the better they make the product, right?
Well, yes and no.
“If you go 40 miles per hour over the speed limit while driving your car, you increase your chances of getting into a car accident,” said Todd Fisher, principal software engineer for online training company Pluralsight. “Similarly, with software engineering, if you are optimizing solely for speed then you can kiss the future success of your codebase goodbye.”
That process creates tech debt — and like its financial counterpart, the more it builds up, the harder it is to deal with and the more it impacts the team.
“Your code will become increasingly harder to maintain, have more bugs crawling around, poorer user experiences and stress out everyone that works on it, which will encourage them to leave,” said Fisher.
Engineering issue tracker platform Stepsize surveyed engineers on their relationship with technical debt, and the results revealed that it’s a major issue. Over 65 percent of engineers surveyed believed their tech debt was causing bugs, outages and other major issues, and over half thought it was significantly impacting team morale. In these situations, productivity also took a hit — Stepsize reported that developers spend an average of one day a week tending to tech debt.
To truly create net speed in their work, engineers need to be thoughtful with their shortcuts. Honing skills over time and creating thorough, polished scripts to automate processes might feel like a waste, but these steps save a staggering amount of time in the long run. When an engineer is careful setting the foundation for development, they are speeding along their work for the future.
Built In Austin sat down with employees from four companies that practice their own forms of thoughtful speed. These engineers from Whole Foods, Pluralsight, Favor and RealWork Labs have implemented processes and shortcuts to help them move fast — without overloading their team with technical debt.
Whole Foods is a grocer focused on organic and natural products.
How does moving fast as an engineer benefit you, your skill set and your overall career?
Almost every engineer that I’ve worked with wants to learn a new technology or solve a new problem. By moving fast, you create the opportunity to tackle those new challenges. This keeps your skills honed and enables you to work faster still — creating a positive feedback loop of delivering more value, but at the same time building out your resume and creating more opportunities for yourself.
During your career, what have you learned that helps you work faster?
Automation — or at the very least, scripting as many manual tasks as possible. I used to joke that I was lazy because I didn’t want to do anything three or more times, so I would build a script to take care of the task for me. This frees up the time to get the real work done.
Eliminate distractions and create focus time. Set expectations with your colleagues and your boss that for a certain number of hours per day, you shut off your chat channels, email and phone. Turn off notifications and get down to solving those complicated challenges without fear of being interrupted.
I used to joke that I was lazy because I didn’t want to do anything three or more times, so I would build a script to take care of the task for me.”
What are the potential drawbacks of working with speed, and how do you mitigate them?
Working with speed does not mean cutting corners on testing, documentation or making assumptions on a customer’s needs. Finishing your work fast and contributing to your teams’ tech debt is not working with speed. Transparency within the team can help the senior engineers coach and mentor newer and green team members — this helps with best practices as well as sharing tips, automation and faster ways of working.
Pluralsight is a company that makes online training content.
How does moving fast as an engineer benefit you, your skill set and your overall career?
Quickly sprinting during the last stretch of a marathon to cross the finish line can be an effective way to get a better time. However, if we are hoping to constantly sprint throughout the entire marathon, start to finish, then the chances of us being able to finish the race diminishes greatly — and we will probably pass out or have to completely stop the race. Pacing yourself is a key strategy in a race where speed is important.
With software engineering, there are many ways to get stuff done quickly — but if you are not considering how cutting corners to meet immediate needs will hamper your ability to move quickly in the future, then you will gradually end up with an unstable stack of band-aids that will eventually feed the flames of a dreaded dumpster fire, which will slow you down as you spend most of your time attempting to put out the fire. You will probably burn out before the fire does.
Maintaining your ability to deliver value long-term as a software engineer will not only help your company out — it will also help to build credibility with those you work with and result in feeling a lot less stressed for you and your team.
During your career, what have you learned that helps you work faster?
Just producing as many lines of code as possible is not my job. Companies ultimately pay us to build products that provide some sort of value to their customers. Reducing busywork enables us to deliver value faster.
The best metric around bugs is one you never have to measure. The earlier in your process you catch or avoid problems all together, the more time you can focus on things that matter.
Prioritize together as a team, reevaluate often and pivot as needed. Keep the MVP mindset and focus first on the most value-adding features — the less important ones will naturally fall out. Continual collaboration with other programmers and product people leads to better outcomes faster.
Limiting what work you have in progress allows you to deliver more often and pivot when needed.
Automate repetitive tasks. This is a huge time saver with some upfront cost. Write automated tests, work on your CI/CD deployment automation early on and keep it in good working order, automate database migrations, make it easy for other engineers to run the same code on their computer and identify other tasks you do often to decide if they are worth automating as well.
The best metric around bugs is one you never have to measure.”
What are the potential drawbacks of working with speed, and how do you mitigate them?
Speed of outputting code should not be the sole focus of a software engineer — delivering value frequently at a steady pace continually for the foreseeable future should be the main goal. By focusing on this goal, your speed will increase naturally, as you will have less things that slow you down moving forward.
Work doesn’t have to suck. It definitely takes some effort to make it not suck, but as you work your way towards optimizing for continual value delivery at a steady pace, you might find that your experience as an engineer will improve dramatically.
Favor is a delivery service focused on delivering in under an hour.
How does moving fast as an engineer benefit you, your skill set and your overall career?
Engineers naturally tend to be perfectionists — absent any outside pressure, we often find ourselves spending far too much time refactoring, refining or prematurely optimizing to achieve the “perfect” solution to a given problem.
Working with speed isn’t about creating an environment that is purely deadline-driven, where engineers continually cut corners and pile up technical debt for the sake of meeting unrealistic goals. For the past few years, I’ve been fortunate enough to work at Favor — where our entire leadership team genuinely values quality work while wrestling with market realities that require us to move fast.
The good news is that embracing both of these principles can be incredibly clarifying. It helps us more easily discern the tradeoff between patching or rewriting in any given situation and leads us to prioritize reusability, efficiency and iteration. We are encouraged to work on solutions that contribute to a long-term, sustainable, fast pace. As an engineer, it is incredibly rewarding to experience continuous, tangible, rapid results that we can easily iterate on in future releases.
During your career, what have you learned that helps you work faster?
Do the work up front to break down your development tasks into small chunks. It’s certainly not always possible, but I find one or two days of development time to be a fairly optimal ticket size to aim for. A continuous pace of completing tickets is motivating, and small tickets move through the pipeline faster.
Next, minimize context switching. If meeting invites consistently leave you with scattered 30-minute blocks of time to do actual development work, try blocking out chunks of focus time on your calendar and allow your meetings to get scheduled around them. One uninterrupted two-hour block of development time is far more productive than four separate 30-minute blocks of time.
I would also recommend investing time in improving your tools. A little time spent automating, creating hotkeys, simplifying recurring tasks or building tools to help with debugging will pay dividends as time goes on.
Finally, I would caution against relying too heavily on third party dependencies — especially frameworks that are merely syntactic sugar around native APIs. Long-term, those become liabilities if they are not well maintained.
There is a demonstrable point of diminishing returns if you don’t allocate time for rest and personal relationships.”
What are the potential drawbacks of working with speed, and how do you mitigate them?
When you are in a culture that prioritizes deadlines above all else, there are significant long-term impacts to the success of your product. Inevitably, corners are cut and quality will suffer — which eventually compounds problems for future work.
At Favor, we encourage engineers to allocate about 20 percent of a sprint toward managing tech debt. This is a healthy balance that allows us to primarily focus on new product work while still maintaining code quality.
It’s also important to personally invest in a healthy work-life balance in order to sustain a fast pace while at work. There is a demonstrable point of diminishing returns if you don’t allocate time for rest and personal relationships.
There will always be seasons where there are exceptions to these principles — an event may come up that requires you to work long hours and even implement some non-ideal solutions in order to hit a strategic deadline. The key is that these situations need to be finite and well-defined. If you are maintaining healthy balances as a general rule, you can sustain a reasonably fast working pace and even handle unexpected seasons of urgency.
RealWork Labs is a referral broadcasting platform for the home services industry.
How does moving fast as an engineer benefit you, your skill set and your overall career?
For me, moving with speed — or at least a sense of urgency — makes the job more engaging. You get feedback on the work you do quickly and are constantly learning as you’re trying new things.
At RealWork Labs, we are still proving our product out in the market. This provides us as engineers with plenty of opportunities for both learning and growth. I think working on innovative, fast-paced projects helps your career, as it gives you a lot of work to showcase on your resume. When your company builds a reputation for getting stuff done, it looks good to future employers.
During your career, what have you learned that helps you work faster?
When to not build something — or at the very least when something is “good enough” for the current situation. Once you get something out in the field you quickly find out where the best place to invest your time is.
One of the things I like best about working at RealWork Labs is our strong product team. With frequent collaboration, research and testing with customers, we’re able to quickly find out what does and doesn’t work. This means we focus our efforts on where we can get the most value.
Creating something that no one ends up using is not only frustrating for the entire organization, but adds to your technical debt — and can quickly make a product unbearable to work with.
We do our best to foster an environment where it is safe to fail.”
What are the potential drawbacks of working with speed, and how do you mitigate them?
The most obvious drawback of working with speed is quality — but I think it’s a false dichotomy to pit quality against speed, because with adequate automated testing you can really have both.
One of the first things we did at RealWork Labs was to create a suite of automated unit, functional and end to end tests that run against every build in our continuous deployment pipeline. This way, we can be confident in the changes that we make.
Another drawback is that sometimes you make the wrong decision. We do our best to foster an environment where it is safe to fail — this way engineers are safe to make decisions quickly versus spending time in analysis paralysis.
