I haven’t written anything here for a while, though did hint about it in an earlier post. Now seems like a good time to talk about what I’ve been doing all this time.

From March 2014 – August 2017, I was the ON Technical Lead for the Solaris Marketing release, and so the “#partylikeatechlead” Twitter posts began.

We rotate the tech lead role through the Solaris engineering organisation, ideally every 18 months, in order to bring in fresh ideas and avoid burn-out, as the job can be a little grueling at times.

Initially I took on the role for what was to be the second half of Solaris 12 development, but over time, as release plans changed, the codebase I was working on became part of the plans for the continuous delivery model being adopted for Solaris and I stayed on to ease the transition.

Solaris itself is produced by multiple development teams, which we call “consolidations”, each roughly covering an area of the operating system. ON, or “OS/Net” – operating system and networking is one of the main consolidations, and comprises the core kernel, drivers and userspace libraries and commands. Many of the technologies you traditionally associate with Solaris are delivered by ON (ZFS, DTrace, SMF, etc.)

So what does the ON tech lead actually do? Well, each engineer that’s appointed to the job brings their own focus to it, but generally, the tech lead is supposed to:

  • ensure the quality of the ON deliverables
  • maintain and improve developer productivity
  • arbitrate technical disputes
  • review projects and bugfixes for integration readiness

Those are fairly broad goals and exactly how each of those are implemented is left to each technical lead to decide, but I hope to write a post about each one to explain my approach.

However, there’s a higher level here – apart from the specific deliverables of the job, the ON Tech Lead acts as an example for other engineers in the organisation. They set a high-bar for quality, are patient and understanding with new engineers, and strict with those who should know better.

Ultimately, the aim is to produce an excellent operating system, but while doing so, attempt to improve the the world for all Solaris engineers and users, so that we can all be more efficient in our development work and indirectly help our customers. Indeed, the ON core team, comprising the Tech Lead, the Lead Gatekeeper and the C-team lead collectively own the ON build environment and tools, and are strongly encouraged to make improvements to them.

There’s a few mantras in Solaris engineering that have existed since long before Oracle acquired Sun Microsystems – “FCS (first customer ship) quality all the time“, and “Find the bugs before customers do” are two of my favourites, and almost everything I’ve done over the last three and a quarter years was guided by those words.

In the next post, I’m going to talk a little more about how I got appointed to the role, via my work on “Project Lullaby“, and in subsequent posts, hope to talk more about exactly what I did during my tenure to advance Solaris.