How I Grew as an Engineer in 2018

This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

OK, I’m a little late this year… It’s time to reflect on what happened in the last year, and the most important lessons learned.

This year was actually quite a bit different from 2017. In January, I wrapped up work with my old team and moved on to an amazing new challenge by joining the product engineering team at First! I’ve been blessed to work with some amazing engineers, product managers, and many others. First has drastically challenged me to grow in ways that I am excited to share.

Incrementalization is difficult- but magical #

The biggest challenge I’ve seen with implementing Agile - all throughout my career - is properly breaking down stories from the backlog. Estimated hours turn into days, and occasionally days into weeks. Here’s what I’ve learned about story breakdown and incrementalization.

• Scrum masters have their purposes, but for true story breakdown, you need a senior engineer with Agile experience; an SM usually will not have the necessary experience to say “I think that will take longer,” but a seasoned engineer will
• Accountability is key: if your team isn’t willing to call out that a story initially estimated at one day has now taken three, then it will start happening every sprint
• Re-prioritize under-scoped work: after breakdown/elicitation, stories are prioritized by product, and there is a subtle assumption - the value of that work is based not only on customer benefit, but time to implement. If an estimated 2-day story turns into a 2-week nightmare, you need to re-evaluate if it actually is the most valuable thing right now

Data anomaly investigations are the best learning opportunities #

Investigating bugs is usually seen as the bane of a programmer’s existence. Here’s the thing: I’ve basically made a career off of it. And I’m not talking about QA engineering - this is proper data/backend engineering.

• Data issues force you to poke around many parts of the application code - you have to internalize information about timings, logic, conditions, and reverse-engineer that to the current state of the data
• By repeatedly digging into the same parts of code, parsing out similar anomalies, you learn where system flaws exist, and slowly gain a vision of the next “ideal state”
• There is never one ideal state of a data application - there are always more edge cases, more business uses, and bigger scalability issues. You’re never moving to the ideal state, only the next ideal state (the seaweed is always greener in somebody else’s pond)

Note: I frequently talk about “data anomalies" - this is not industry-standard terminology, and is usually lumped in to the general "bug” category, but I believe it’s an important distinction. Bugs are typically very self-isolated, but data issues can quickly compound, depending on how/when you touch the data, where the data is sourced from, and timing between multiple data systems. Anomalies can be very intimidating monsters!

Data is not important! #

OK, this one is cheating, because I already got on a soapbox about it. But it’s an important lesson, especially because I’ve already had to learn it multiple times.

But rather than re-hash the previous article, you can read it from others:

• Humans Don’t Trust AI
• At Netflix, Who Wins When It’s Hollywood vs. the Algorithm
• Why Executives Don’t Trust Their Own Data and Analytics Insights

Best reads of 2018 #

The majority of how we grow is not what we do, but what we read. These were the most influential sources for my thinking this year:

• John Cutler: Product development/agile/process guru
• Hooked: How to Build Habit-Forming Products: Very influential at First this year, and a solid first-step in answering the Data is not important problem
• The Site Reliability Workbook: Practical Ways to Implement SRE: Building on Google’s previous Site Reliability Engineering, this book moves theory and concept into practice

Feel free to connect with me!

• www.linkedin.com/in/jeremiah-coleman-product
• https://twitter.com/nerds_s
• jeremiah.coleman@daasnerds.com
• https://github.com/colemanja91