Engineering Best Practices

As you can probably tell, I do a lot of reading around the web, Kindle e-books, and occasionally some podcasts. I mostly read about how to level-up people, create strong teams, and better ways to operate as it relates to Software Engineering.

This list here is meant to be a fairly raw capture of some Best Practices I’ve come to apply over the years that have served me well. Feel free to peruse, and apply them to your workflow. Let me know if it improves things for you!

Best Practices

Deliver something, anything, early. And do it often. The sooner you get early feedback on your framework, tool, website, product design–whatever you’re working on–the better. Even if it’s rough as hell, and all the data you return is completely synthetic and arbitrary, acquainting your customers with the expected User Interface / User Experience can pay dividends in allowing you to pivot earlier, before you’ve written a huge pile of code in the wrong direction. Even APIs have UX issues, trust me.

Prioritize and Focus. If you do less, what you do is typically done to a higher standard. Do not multitask. Be a “serial monogamist” when it comes to what you’re working on. Changing gears while you’re waiting for feedback is fine, but focus on one thing at a time, publish it for feedback (early), and change gears to something else while you wait for all the feedback to come in.

Design for the long term, build for now. I mentioned this in my “Working With Me” post, but the basic idea is this: design your API/framework/product/whatever with approximately the next 2 years worth of features/flexibility in mind. Give the future some thought, but don’t get hung up on making sure your design is 100% future proof. It never will be. Give some thought to the future scenarios, make sure your design takes them into account and plans for future iterations, then build the solution for right now with as much flexibility as is warranted. As you iterate, you’ll add what you need (and no more), and leave hard, future problems to your future self. You’ll be smarter in the future, trust me.

Grow your teammates’ capabilities. Utilize your teammates whenever possible. Have them CC:ed on expert code reviews so they learn by osmosis. As an IC, this means bouncing ideas of each other A LOT. It means explaining that extremely difficult problem you just debugged widely across your team (and driving to their understanding). It means trying out your interview questions on each other. As a manager, its meaning is most easily captured by the next point.

Delegate to the bottom. Let’s say you’ve got a team mix of junior, mid-level, and senior folks. Instead of delegating projects only to the senior folks and asking them to delegate down the to the junior folks, delegate straight to the junior folks, and give them access to your senior folks as resources to be used for design review, code review, etc. This prevents your senior folks from getting burnt out by constantly taking on basically the entire team’s workload, it empowers your senior folks to act more like leaders, and frees up their time to think and work on stuff that interests them (which is also where their biggest impact will be). It also allows your junior folks to grow faster by utilizing your senior folks more as teachers, and less as task-masters. As long as your junior folks pay attention to point 1 (deliver early), they’ll be fine.

Learn from failure. In fact, celebrate it! In my old team at Pearl, we used to pass around a ridiculously large Gold Star to whomever most recently broke the build. It became a celebrated, humorous ritual: Whomever currently “owned” the star would hear about a build breakage, jump up from their desk with glee, walk over to whomever broke the build, and deposit the star on their desk ceremoniously. Then other people would get curious, come over, and we’d all be regaled with a story of how one missed test case, or some random, unthought of integration problem broke things. In this way, everyone learned what they needed to watch out for, peoples egos learned to not take it personally, and we added a little bit of friendly humor to the organization.

Communicate Often. Your stakeholders will appreciate it. Let them know even when things are entirely on the rails. Let them know if you suspect you might get behind. Give people plenty of heads up, and magic can happen. Other teams can reduce the necessary scope to help you hit the deadline, or offer some of their resources to help.

Manager, CoreOS @ Apple