This is the second last post in my series about my 3.25 years as Solaris ON tech lead at Oracle.

Originally, this post was titled “arbitrate technical disputes”, but honestly, looking back, I actually didn’t have to do this terribly often. So, I’m just renaming it to “dealing with people”, and will offer some thoughts on my approaches.

For the most part, I was lucky to be dealing with an organisation of terribly smart engineers who were well-capable of resolving technical disputes without any help from me.

On the rare occasions I was asked to weigh in, I tended to find an easy path through the maze just by reframing the statement:

“If I was a Solaris user with a substantial investment in the operating system, and ran into this problem (or something related to us choosing one approach over another) in production, what could the impact be, and how much would this ruin my day?”

When you address problems that way, the solution often becomes clear – it may not be the path that everyone wants, but ultimately our users trust that we have developed the best OS possible, and expect us to have made the right call.

Of course, not everything comes down to a technical decision. There were times when I disagreed with the readiness of code which was to be integrated, with teams either promising they’ll fix all the bugs after they putback or citing schedule reasons for wanting to integrate before the project was ready. On those occasions when my advice was overridden, sadly, I was often proved right.

More frequently, the reasons I most frequently needed to interact with people tended to fall into two distinct categories:

  • code and project reviews
  • dealing with gate breakage

and it’s worth talking about them both

Code and project reviews

Apart from the technical aspect of performing code reviews, which I’m not going to talk about, I feel there’s a social skill needed to review changes. Realising that the engineer who has asked you for a code review believes you to be a peer or senior engineer already implies an amount of respect should be given to the request from the start.

At the same time, it’s also good to remember that reviewing people’s code really does make you a better programmer – it’s easy to fall into the trap of thinking you’re “getting nothing done” simply by reviewing other engineer’s code, that’s just not true: you’re advancing the state of the operating system by helping your colleagues succeed.

The other thing I try to bear in mind, is that the engineer who has asked for a review likely feels like this is their best work – coming across as especially disparaging or severe in your review comments is not usually a good way to get people to improve. Don’t be an asshole.

If you’re continually getting poorly thought out code sent to you for review, it might be time for a chat with the submitter. I’ve always tried to be sensitive in my comments during code reviews, offering suggestions when they’re needed, while at the same time not spoon-feeding all of the answers.

[ In the dim and distant past, one code review I sought as a junior engineer from a very senior engineer was met with this response: “This section is wrong, but I’m not going to tell you which part. Read this book, then tell me what the right answer is, and why.”  That response still sticks with me today, and I’m a better engineer for it. ]

Project reviews are slightly different from code reviews – at this point in the Solaris development process, the code has already been reviewed by subject-matter experts, test plans have been written, testing performed and results have been produced and reviewed. All of the bug database book-keeping and potential legal review has already occurred – we’re on final-approach.

At this point, as a technical lead, you’re being called in to offer your opinions and experience at a high level on all of that work. Are there other projects which recently integrated which ought to be tested with this change? Did the original reviewers consider that subsystem when looking at the changes? Are the build logs absolutely squeaky clean, and did the project team recently sync with the gate?

Reviewing projects is really just something that takes experience, and if you have the opportunity, sitting in on a project review, or reading ARC cases as they are discussed is an incredible way to learn more about engineering.

Dealing with gate breakage

From time to time, someone integrates a change which breaks the build. Despite all the tools and processes we have in place, humans can still be humans, and as tech lead I often had to get in touch to break the bad news.

From a technical perspective, the fix was usually simple: revert the change from the gate, or pester the responsible engineer for a fix.

From a personal interaction perspective, there were a few ways of dealing with this.

My approach was always to be as reasonable and professional as possible – the chances are, the engineer didn’t mean to break the gate, and they’re likely already hugely embarrassed that they’ve done so because their integration has likely been pulled into workspaces right across the company by the time we discover it.

Putting extreme pressure on them at that point would be unlikely to help matters, so I’d usually give them time and space to work out the problem, or make the call to revert the change. This is a different approach than others have used in the Solaris OS/Net consolidation in the past (oh, the stories!), but is very much the one we’ve been trying to encourage in the gate.

In my opinion, the most important thing, is not whether an engineer makes a mistake, but it’s how they recover, their attitude towards owning up to the problem, what they do to prevent themselves from making the same mistake again, and how we can make the build more likely to flag those problems.

 

To sum up – being a tech lead isn’t all about the code – you need interpersonal skills, and dealing with people in a kind and respectful way will make your job immeasurably easier. Don’t be an asshole.

Advertisements