Posts
-
Leading vs Managing
What is Leadership? Too often people talk about managing and leading without being clear about what they mean. This can be particularly problematic when trying to mentor a developing manager. Managers have many responsibilities requiring a variety of skills and lack of clarity in our language can make it harder for managers to learn and improve. In this post, I want to discuss “leading” and “managing” as behaviors (or skills) rather than a particular job (eg “engineering manager”).
Read more...
-
Bumper Cars or Go Karts?
Which is your company playing? Does it feel like your company is playing bumper cars? In bumper cars, there’s typically an open area to drive with no particular direction or order to things. In go karts, there’s generally a track with a well defined direction. In the organizational analogy of bumper cars each person or team may have a goal in mind but they keep getting bumped off course by another team (or person) heading in a different direction.
Read more...
-
More on tech debt
In response to a discussion at work, i wrote some further thoughts on tech debt captured here. (See my earlier post Tech Debt Tradeoffs) Timeline/Context I want to help people explicitly consider the timeline for the return on investment. So, for example, if you are going to release your big project in 3 weeks, certain options will be off the table. But, if you have 3 months they might be clearly superior to what you’d do in the 3-week situation.
Read more...
-
Tech debt tradeoffs
NOTE: please also see my followup post [More on tech debt]({{ relref . “more_on_tech_debt.md” }}). Tech Debt and the Race against Time: As I often say, we should all understand that there is good technical debt and bad technical debt. In real life, I have a house with a mortgage but don’t consider my mortgage bad. Sure, all else being equal, i’d rather not have a mortgage to pay. But, not all else IS equal.
Read more...
-
A code review checklist
Goals I’d like to do two things in this post: describe how i typically approach code reviews, and provide a basic checklist of what I think code reviews should take into consideration. My approach to code reviews If the pull request (PR) is small enough, i’ll generally review the complete diff at once (rather than by individual commit). Without a hard and fast rule, i find that something like ~200 lines affected is generally my cutoff.
Read more...