https://rich.liebling.us/posts/Recent content in Posts on Rich LieblingHugo -- gohugo.ioSun, 26 May 2019 10:00:37 -0700https://rich.liebling.us/posts/aligned_autonomy/Sun, 26 May 2019 10:00:37 -0700https://rich.liebling.us/posts/aligned_autonomy/A friend shared this image with me that wonderfully captures the essence of the “Loosely coupled; tightly aligned” mantra. For more on alignment, please see my posts on Bumper Cars or Go Karts and Leading vs. Managinghttps://rich.liebling.us/posts/would_you_rehire/Mon, 06 May 2019 13:26:36 -0700https://rich.liebling.us/posts/would_you_rehire/In the investment world, some advise people to consider their holdings with the question: Would you buy this again at the current price? The point is that if the answer is “no” then you ought to sell it. In effect, each day you hold the security you are choosing to repurchase it at the current price. Similarly, some apply this advice to managers in the form of asking: Would you rehire this employee today?https://rich.liebling.us/posts/the_three_questions_and_followup/Wed, 24 Apr 2019 16:58:50 -0700https://rich.liebling.us/posts/the_three_questions_and_followup/With agile processes and Scrum, in particular, being so prevalent, most people are familiar with the famous “3 questions” for daily standup: 1. What did I accomplish since last standup? 2. What do I intend to accomplish today? 3. What blockers do I face? However, I find that many people fail to appreciate a certain subtlety of the questions. I’m talking about the significance of the word accomplish in the first two questions.https://rich.liebling.us/posts/adopting_new_technologies_a_lesson/Sat, 13 Apr 2019 15:52:14 -0700https://rich.liebling.us/posts/adopting_new_technologies_a_lesson/At dinner the other night with a former colleague of mine, he shared some war stories from the trenches with Kubernetes. Don’t get me wrong: I think Kubernetes is incredibly powerful and useful. But, it brings a lot of complexity and with complexity comes trouble. So, what did he share? He’s working at a very cool startup that has not yet launched their product/platform. But, they are up and running with a few folks using the platform.https://rich.liebling.us/posts/programming_and_abstraction/Fri, 12 Apr 2019 08:27:40 -0700https://rich.liebling.us/posts/programming_and_abstraction/I want to share a few good articles I read in the last week on programming. The first two use Elixir and Erlang for their examples, but the concepts apply to programming in any language. In Don’t Repeat Your Domain Knowledge, Yiming’s main point is that the well known DRY (“Don’t Repeat Yourself”) principle applies most importantly to domain knowledge. More and more the community seems to recognize that taking DRY too far can be quite harmful.https://rich.liebling.us/posts/leading_vs_managing/Thu, 11 Apr 2019 14:39:51 -0700https://rich.liebling.us/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”).https://rich.liebling.us/posts/bumper_cars_or_gokarts/Sat, 16 Mar 2019 13:13:56 -0700https://rich.liebling.us/posts/bumper_cars_or_gokarts/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.https://rich.liebling.us/posts/more_on_tech_debt/Sat, 27 Oct 2018 21:01:27 -0800https://rich.liebling.us/posts/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.https://rich.liebling.us/posts/tech_debt_tradeoffs/Mon, 22 Oct 2018 20:47:21 -0800https://rich.liebling.us/posts/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.https://rich.liebling.us/posts/code_review_checklist/Tue, 20 Mar 2018 20:29:00 -0800https://rich.liebling.us/posts/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.