Note the order. Red, then Green, then Refactor. Those of you who practice Test Driven Development will deeply understand the importance of this mantra for the three phases of development. I’d like to take it a step further and explain examples of not following the order or spending too much time in the wrong phase.

Engineers often say to me “I don’t get to learn [INSERT_CONCEPT_HERE] on the job. How do I get to practice it?” I say bologna! Ask for the opportunity, or better yet make it!

Every so often, I come across Merge Request that slowly grow in size. They start out as 100 lines of code change, then 20 commits later it’s 500 lines long! This is a symptom of poor planning and task break down.

I was talking to some teammates about leadership and I mentioned that most of my leadership strategies are directly influenced by Star Trek.

Those of you who’ve done freelancing will know if you say to the client “Feature X will take 3 weeks at $1,000 a week… that’ll be $3,000 plus tax” they’re going to have a fit. “We want it cheaper, faster, blah blah blah…”

I find myself not paying attention to epics and discussions unless I know the WHY. I literally zone out. Start checking emails and Slack. Half listening for my name or something critical. Before I work on anything that will take more than a day I want to know who’s “paying” for it (the sponsor) and what are the measurable benefits (metrics).

Since I started this blog, I’ve realized the importance of writing. Engineers more senior than me have noted that writing is:

Product Managers focus on the what and why. They care deeply about the who and when. Engineers focus on the how.

As a busy professional, I really appreciate breaking every task down into smaller subtasks. If a ticket has 2 or more things that can be done separately, I prefer to do them separately.

I reminded the team that it’s important to create and use your own Problem Solving Template. This should be based on your strengths and weaknesses as an engineer. I highly recommend reading chapter 1 and 8 in the book Think Like a Programmer.