While coming up with a task list, it’s a great exercise to initially break them into 3 categories: Must, Should, and Could. This will help you prioritize when you inevitably run out of time to complete the project.

Having a simple mental that can be used to solve different problems is quintessential to speed and quality in software engineering.

We’re going to talk about a little bit of math and why it’s important for designing and debugging code. y = f(x) is commonly referred to as a “functional notation”. It is a mathematical equation that represents a relationship between two variables, x and y.

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: