Practices to rapidly ship new software products as an engineer

Throughout my tenure as an engineer, people always seem surprised at how quickly my teams have been able to ship new products. I’ve noticed a number of consistent patterns that work.

I’ve broken them into 4 categories: engineering practices, working with partners and stakeholders, engineering team skills, and individual skills. Many may seem self evident, but I’ve seen all of them ignored and forgotten at various point, so reiterating does not hurt.

Disclaimer: this guide is geared towards new products and features. Many of these points are still valid when working on legacy products, but some not hold as much value.

Engineering practices

• Don’t over-engineer — there’s something beautiful about well architected software, and a lot of engineers desire. Books and blogs may present plenty of fantastic concepts. But the real question is: do you need a complex architecture for what you’re building? Do basic or existing patterns and designs do the job just as well? They’ll be quicker to implement, easier to change as the product evolves, and easier for other engineers to contribute to. Keep it as simple as possible.
• Use technologies and frameworks that you know — something shiny, new, and exciting always exists. But ask yourself a few questions before signing up. What’s the learning curve? Is this well supported; i.e. will you have to re-invent the wheel and write libraries for what should be basic functionality? Does this give an incomparable advantage to tools you already know really well? New technologies can be great, but should most likely be left for playing around with side projects and hackathons first.
• Don’t be too DRY — “don’t repeat yourself” and re-usability is a concept that makes programming magical. However, building in an excessively DRY manner is an easy trap to fall into and risks obfuscating logic, resulting in code that’s more difficult to read. How much time and complexity will you save by making something DRY? Is it complicated and nuanced logic, or is it something super simple and easily repeatable? The Rule of 3 is also a good reference point.
• Don’t over optimize at the start— it’s easy to think about efficiency, queries, and edge cases at the start and just overwhelm yourself. Decision paralysis is real. Build something inefficient to start with and then improve it incrementally before launching.
• Ship in small increments — breaking larger problems & features down into smaller bits is a crucial skill for any engineer. Shipping in small increments is a tangible reflection of this breakdown. It has the added benefit of making PR reviews much easier for your team and will help avoid major bugs or breakages that large might result from large changes. Strive to make each pull request change only one thing.
• Use feature flags when applicable — when building a feature for an existing product, merging changes can be daunting, especially if the feature is not ready to release yet. Feature flags let you keep your changes away from the user and ship frequently without worry.
• Write the right tests — tests bring immense value, but can also be time consuming to write. When you’re building a new product, code logic and structure are likely to change over iterations. You’ll get a lot of value out of integration and functional testing early on. Unit tests are best saved for when the dust has settled. Note: some things are much easier to write and assert with TDD, so don’t hold back when it’s actually going to speed you up.
• Treat code as a living/evolving creature— don’t hesitate to jump in and change it frequently. It’s ok for the initial code to not be perfect. Always be iterating and improving on it. Having the right tests will make refactoring and editing very easy.

Working with partners & stakeholders

• Build trust with your stakeholders — the more your stakeholders trust you, the quicker you’ll be able to build. You’ll have fewer unnecessary checkins and can focus on building things in the order that allow you to work quicker rather than an artificial timeline presented by somebody else.
• Build a tangible happy path first— this is the easiest way to build trust with stakeholders. Stakeholders need to see progress, especially if they don’t see all the engineering intricacies beneath the surface. Focus on building the happy path first, while leaving some of the edge cases and polish for the later part of development. Remember the The last 10% of the work takes 90% of the time.
• Push (and pull) back against product and design on the right things — product and design don’t always have the best sense of what can be costly to build. That’s why your expertise is important. Polish or ‘features’ that look small can actually be expensive to implement. Push back against those. Alternatively, sometimes P&D has removed features for a later iteration that will actually save time in the long run to just build now. Pull those back in and save yourself the time later.
• Ask clarifying questions — when uncertain of something don’t hesitate to ask P&D. You’ll save time having to rebuild later. There are often cases and gotchas that P&D had not considered, so it’s good to get all get on the same page early on.
• Keep the number of people involved in decision to a minimum— the more people involved in a decision, the more disagreement there’s going to be and the longer you’re going to spend discussing minor or irrelevant things. Ideas are good, but too many ideas past the idea phase can be deconstructive and only slow everybody down.
• Learn about the user and product yourself — you need to understand who you’re building for, what problem you’re solving, and how you’re solving it. It’s easy to rely on product and design, but you’ll be able to make better decisions yourself if you actually understand the bigger picture.

Engineering team skills

• Don’t spend too much time talking before spiking or building— although project specific, real problems reveal themself when you start to get your hands dirty. It’s easy to pinpoint and discuss complications up front, but the scariest things are those that are unknown. Discover those early on and you’ll be able to give good project estimates and allocate your time correctly.
• Use ticketing tools like JIRA appropriately — every project has a lifecycle. The usage of ticketing/issue tools should vary at different points of the lifecycle. Don’t try and break everything into tiny tickets to start with. Keep things broad to start. Smaller tickets will come later naturally. Think of the later part as the 90/10.
• Don’t waste time arguing about small things — it’s ok to disagree. Express your opinion, but don’t expect or require everybody to agree before moving forward. Some things maybe worth fighting for, but don’t waste time on things that aren’t.
• Don’t block other people on your team — tying into the point above, approve ready to go pull requests without major pending issues. Comment on any concerns and trust your teammate your make the correct judgement on addressing them. They’re working towards the same goal as you, so trust them. Create a culture of progress rather than stagnation and blockers.
• Find a partner in crime — find somebody who can review your PRs and bounce ideas off of. Trade reviews with them. Keep your PRs small and limited to one goal as mentioned above, and it shouldn’t be too time consuming. Keep the turnaround quick. Watching a PR sit around for 24 hours is demotivating.
• Create a culture of constant shipping — the energy will feed your teammates. This is a culmination of a number of points above. Keep blockers at a minimum and ship frequently. You want consistent momentum.

Individual skills

• Be a doer — lean towards action over waiting and discussion. Plenty of people have ideas. Far fewer can execute. Something tangible is always more impressive and productive than waiting for signoff or excessive conversation.
• Avoid getting blocked on the wrong things — curiosity is crucial as an engineer. However, it’s easy to go down the wrong rabbit hole in solving something that may have a workaround or may not be the right thing to solve. Be conscious of which holes you decide to go down and how deep you go. Always keep the end goal of shipping the product in mind.
• Feel empowered — if you’ve seen the code in some major open source libraries, you’ll realize that the contributors are normal people prone to making even simple mistakes. Don’t be afraid to step up and contribute or do things yourself.
• Ask educated questions — somebody else may know the answer off the top of their head. Don’t rob yourself of the opportunity to learn and become independent. A good rule of thumb is to spend up to 30–60 minutes digging into a problem. Then ask somebody else for help in order to unblock yourself. What you don’t want to do is become reliant on somebody else’s knowledge, as you’ll end up creating blockers for yourself.
• Create large time blocks to work — I frequently reference Maker’s schedule, Manager’s schedule. Find a solid block of 2.5–4 hours to immerse yourself in building during the day and you’ll be amazed how much you can accomplish within that period.
• Figure out what puts you in the zone — find what triggers your creative and concentrative juices and use that when you are about enter one of your time blocks (for me that’s turning on some Megadeth or Dream Theater).
• Don’t lose context unnecessarily — when you are at the peak of solving a problem or in the zone, losing context can be expensive and set you back. Push yourself to ignore non-urgent distractions and you’ll save yourself a lot of time.
• Don’t work more than you feel like — avoid burnout. If you’re not in the zone or unable to concentrate, it may take hours to solve a problem that might take 5 minutes the following morning. Use your energy and working hours wisely. “Work smarter, not harder.”
• Work on something you enjoy — there are always pain points in building products, but if you are building something you enjoy it those minor pains are worth it and the less it feels like work. Enjoyment can come from the process, your team, the people who you are building for, or even just the end product.

Photo by Rags Fehrenbach