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.