Links - 16^th July 2023

yet another special interest topic infodump

rpc sucks, and it’s not because it’s not “restful” or whatever flavour of the month crap’s in fashion. be it corba or dcom, json-rpc or grpc, sunrpc or soap, the same problems always come up

don’t be afraid to write fragments of a post, as sometimes you can glue them together into something more cohesive later

edit 2: the one other tip i forgot? sometimes you just need to ramble until you sum up your point, and then delete the prose that got you there

In this article, we’ll discuss:

• Debugging the Engineering leadership team after stepping into a new role

• Gelling your leadership into an effective team

• What to expect from your direct reports in that leadership team

• Diagnosing conflict within your team

When it’s possible, it’s well worth your time to consider including one or two senior engineers to report to you, as opposed to only managing engineering managers. An engineering executive is responsible for blending the technical and managerial perspectives of engineering, and that’s most easily done when both perspectives are represented within your leadership team.

In some cases, this will be difficult to accomplish. You may have too many direct reports already, and feel it will be overwhelming to include more. In that case, work to establish a group of senior engineers that you interact with frequently to ensure you’re hearing their perspectives. This is frequently an architecture team or the senior-most engineer from each business unit.

The next common challenge is team members who’ve learned bad habits in bureaucratic or shrinking companies. Those environments often teach the implicit leadership lesson that it’s more effective to capture existing capacity within the company than to create new capacity for the company. Leaders immersed in that lesson often view success as a zero-sum game. Your goal is to convince them that today’s capacity represents a small fraction of the future capacity. By instead focusing on the capacity that can be collaboratively created in the future, they’ll have significantly more opportunity.

At an early job, I worked with a coworker whose philosophy was “If you don’t ask for it, you’ll never get it”, which culminated in continuous escalations to management for exceptional treatment. This approach was pretty far from my intuition of how a well run organization should work, and it grated on my belief that consistency is a precondition of fairness.

Since then I’ve come to believe that environments that tolerate frequent exceptions are not only susceptible to bias, they are also inefficient. Keeping an organization aligned is challenging in the best of times, and exceptions undermine one of the most powerful mechanisms for alignment: consistency.

Conversely, organizations survive by adapting to the dynamic circumstances they live in. An organization stubbornly insisting on its established routines is a company pacing a path whose grooves lead to failure.

How do you reconcile consistency and change?

Like most seemingly opposing goals, the more time I spent considering them, the less they were mutually exclusive, and the more a unified approach emerged that I call “work the policy, not the exceptions.”

If you find yourself writing constraints that don’t actually constrain choice, it’s useful to check if you’re dancing around an unstated goal that’s limiting your options.

When your application frequently updates counters, e.g. page views or comment likes, you will encounter performance problems and even deadlocks. Every time a row is updated, it is locked until the query or transaction finishes. Therefore, no parallel updates are possible and each query has to wait until all the prior ones are finished. But you can workaround this concurrency limitation by randomly spreading the counter to as many rows as you want to reduce the locking probability.