Great companies maintain their insurgent mindset, for fear of becoming complacent and irrelevant over time.

Push decision making down to single-threaded DRIs

Single-threaded is tech jargon that simply means solely focused on a single area. The single threaded DRI is the most senior person whose only job is to run a given product or initiative, this will typically be a product management or engineering leader.

Leverage shared services to minimize duplication

If you’re in tech and have been thinking about your work and role in your company, I highly encourage you to watch this talk by Tanya Reilly ¹

Setting myself a reminder to rewatch this again 6 months from now.

If you’re a software engineer trying to be snarky, it’s important to get these terms right for maximum effect.

What is Yak-Shaving?

“Shaving a Yak” means performing a seemingly endless series of small tasks that must be completed before the next step in the project can move forward.

Is this a good thing or a bad thing?

It depends. Yak Shaving is sometimes very much necessary. It’s “bad” only when done unnecessarily. It’s unfortunate when necessary but might not be a bad thing at all under certain circumstances.

Sometime back I ran across a thread where folks talked about this programming style called “Space Shuttle style” that the Kubernetes codebase followed.

// ==================================================================
// PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE.
// KEEP THE SPACE SHUTTLE FLYING.
// ==================================================================
//
// This controller is intentionally written in a very verbose style.  You will
// notice:
//
// 1.  Every 'if' statement has a matching 'else' (exception: simple error
//     checks for a client API call)
// 2.  Things that may seem obvious are commented explicitly
//
// We call this style 'space shuttle style'.  Space shuttle style is meant to
// ensure that every branch and condition is considered and accounted for -
// the same way code is written at NASA for applications like the space
// shuttle.
//
// Originally, the work of this controller was split amongst three
// controllers.  This controller is the result a large effort to simplify the
// PV subsystem.  During that effort, it became clear that we needed to ensure
// that every single condition was handled and accounted for in the code, even
// if it resulted in no-op code branches.
//
// As a result, the controller code may seem overly verbose, commented, and
// 'branchy'.  However, a large amount of business knowledge and context is
// recorded here in order to ensure that future maintainers can correctly
// reason through the complexities of the binding behavior.  For that reason,
// changes to this file should preserve and add to the space shuttle style.
//
// ==================================================================
// PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE.
// KEEP THE SPACE SHUTTLE FLYING.
// ==================================================================

To be clear: I don’t follow the Space Shuttle style programming with my own code. However, I’ve noticed now that when I do comment my code, I’m a little more liberal with my explanations. It’s made me realize that commenting your code doesn’t necessarily always mean bastardizing it.

… You should mention what technologies you are using (because listing WCF or Java will save me the hassle of applying, and you the hassle of rejecting me), but don’t list specific tools, languages and frameworks as requirements.

Good developers who know Rails can learn Django or Node.

Going between Oracle, SQL Server, MySQL and Postgres is all pretty trivial.

… I remember being asked quite eagerly, during a pre-interview, if I knew a specific view engine (like erb, or haml…). Seriously, a view engine!?!? A shitty programmer can learn a new view engine in 10 minutes. Or a more common one that always gets to me is listing some specific version control software. Or a specific library that solves a trivial problem (I see this all the time from the .NET world with DI and mocking frameworks)

You’d be surprised how valuable the skill of eloquent communication is even in the field of IT. Keeping users apprised with your progress is perhaps the most important thing to do when working with clients. But keeping them apprised is tricky business and the ability to clearly put down in words,what to expect, is a basic necessity today.

Even if you have nothing to do with CS or computers, you should read the linked article. Fantastic advice.