Skip to main content

Posts

Platform Teams' Economics

After being involved in the Kubernetes project for about a year I have had some interesting reflections about the configuration and infrastructure space.  I have talked to a few Platform engineers and have gained some interesting insights into how these organizations operate at scale.  My observation is that in most organizations have a tough time measuring or financing their Platform Teams. A lot of the Platform teams are not sure how to evaluate whether or not their effectiveness.  This situation paired with the fact that the investment in Platform is generally removed from the business KPIs leads to underfunding in Platform resources. Most of the Platform projects are evaluated based on activity instead of impact.  In the conversations and allocation of resources the head of Platform Engineering generally can come up with only a backlog of outstanding projects without a clear indicator of why speeding up delivery of those projects will improve the company bottom line.  The usual nar
Recent posts

What to do about being tracked online?

Advertisers have been talking about the improvement in ad targeting and how it benefits everyone, yet consumers ask not to be tracked.  In real life we appreciate it when someone pays attention and tailors their messaging to us, why not online?  Can something be done to fix it? We get profiled in real life all the time.  Some of that is welcome, some of it is not and some of it is illegal.  A lot of the profiling is due to our conscious choice.  Those who drive a Ferrari know that people perceive them differently than those who drive a Prius.   What is broken in online tracking is that the user has no clue and no control over how they are being tracked.  A few years ago a friend of mine sent me a link to check out a dress from one of the new fashion designers. The designer had a very edgy name.  Later in the week I was doing a demo to a customer in the same browser and outlook.com had a big banner on the side of a young woman in a revealing dress with a raunchy tagline.  I felt out of

Long Form Communication in Software Development

After spending a better part of the decade with Slack, HipChat and Microsoft Teams I joined a team that chooses to work a different way and the depth of work is evident.  The engineers on the team contribute a lot to the Kubernetes codebase and it seems like hours and days of uninterrupted time are critical to the way they work.  This made me think about the necessity of “always on” culture.  Is getting someone unblocked worth everyone keeping an eye on Slack throughout the day? For those who have read the timeless classic Deep Work by Cal Newport this is a well explored subject.  I have read this book a few years ago and it immediately resonated with my experience.  I think about some of the key ways that I worked early in my life and I realize that my mentors were preaching and practicing deep work. Growing up I went to a boarding school where at night homework was done behind a desk, in the classroom with the entire class sitting there quietly.  There was a teacher present who could

Lukashenko takes Minsk off High Tech Map

A few years ago I have created a company in Belarussian High Tech Park.  I found the city’s technology scene vibrant and the favorable tax structure created for the High Tech Park a nice pro business reform.  I have recommended Minsk as a viable location for an Eastern European software team.  Since August 9th 2020 my recommendation is changing: Mr. Lukashenko’s regime has kidnapped people off the streets, turned off the internet for several days and started putting people in jail for political reasons.  It is now risky to create or keep your R&D office in Minsk and I would not recommend it.  AP Photo - Belarus Arrests In my blog I try to keep focus on technology and keep politics out of it.  Regardless of my beliefs on Mr. Lukashenko’s government, I am going to keep this post strictly to risks that the current regime has posed to anyone doing business with Belarus since the troublesome election on August 9th.  I sincerely hope that companies which are affected by the police brutal

Intuitive Programming - Comments

Comments are a topic of vibrant discussion.  Ever since programmers could leave some text in the program that was ignored by the machine the debate started: “what’s a good comment, what’s a bad comment, why comment?” There are endless instructions to programmers that say many of the following things: 1) Describe your function! 2) Don’t write in the comment what you wrote in the code. 3) Tell people why you are doing what you are doing. What I think has been missing from this discourse is the audience for comments and through those audiences there is intent.  The code is being read, skimmed or analyzed by people and tools.  So what are the audiences and reading modes? 1) Maintaining and enhancing the code 2) Skimming through the entire module or file to figure out what the overall structure is 3) Reviewing the test files to check out the test coverage and edge cases 4) Seeing the docstrings of functions while being in a separate file altogether 5) Reviewi

The Last Dance of People Management

The Last Dance on ESPN is a huge hit.  I was a teenager during the Bulls’ era in the 90s and it was a wonderful way to relive the magic of that time.  For those of us who are in leadership roles, there were a lot of great lessons from players, coaches and managers of a  basketball dynasty.  However if you are looking to use some of Michael Jordan’s leadership tactics to your organization - I think it’s critical to know what applies and what doesn’t. There is a myth around in Silicon Valley about a hard charging leader, who is pushing his team to get them to operate at the “next level.”  There are stories about how Steve Jobs and Bill Gates were mean to their employees, this is lauded as a key ingredient to success.  People who buy into that saw Michael Jordan pushing his teammates as a proof point that it’s the way to get it done.  The truth is that your company is not an NBA franchise. Tech workers today do not put up with people pushing them and definitely won’t take a punch l

Intuitive Programming - Fragile Constructors

There is nothing that says that a constructor of a class can’t perform complex transactions, but most of the people do not expect them to be long running or fragile.  When someone is writing a constructor that connects to a database, makes a network call, parses files on disk or something that can error out, that is not intuitive.  In the words of Big Lebowski “you are not wrong, you are just an a-hole” My overall mantra of intuitive programming and design is that you should create systems with the principle of least surprise to the caller and maintainer.  Most of the programmers assume that object constructors rarely fail and rarely take a long time. Constructors are generally used to create object and assign default or provided values to the fields in the object.  The trouble with overloading the constructor with something super heavy is that while you can remember that this is a “special constructor” others won’t intuitively get that.  Often times when you do something