Category Archives: Career Stuff

A Tough Call

This other day I’m like coding and stuff when a co-worker walks by and asks to have a word. It turns out he needed some advice after he got himself in a pickle by checking in slightly more code than was supposed to. Something about refactoring a bunch of code instead of just fixing the dozen or so bugs he was assigned, which resulted in some frowns.

At this point you’re probably wondering why he came to me, given that I have nothing to do with his project. To that I would say I sometimes play the role of the bartender among developers with the exception that I don’t serve drinks and expect no tips. Hopefully that make sense.

So it turns out this guy set out to fix those bugs when he realized he’s dealing with a bunch of spaghetti with a full can of past-expiration-date bolognese sauce ton top. Being a fearless engineer, he took matters in his own hands and decided to refactor the offending code. But there’s trouble in paradise – the refactorings didn’t go too well with the management.

As we talk about this, I can’t help remembering so many past instances when we had some prototypical loose cannon make frivolous changes all over the place and breaking a bunch of stuff. The worst part was when I got stuck cleaning up after them. But there were also times when that was the right thing to do and it brought about a lot of good. The question is – which is it this time?

I put on my metaphorical referee uniform and tried to reason through this. Refactoring can definitely be risky and its benefit must be weighed against the risk. However, after deliberating for about 10 minutes I called the move – legal. The deciding factors were:

  1. This engineer stands behind his work. He expressed the willingness to “work all night” to rectify any issues that may arise as a result of this.
  2. He knows his s*%t. He made a convincing case why that old code was no good (monolithic methods, incorrect abstractions, etc), and why his code is likely to be more maintainable.
  3. He has a history of good coding practices.

In addition I decided to give his superiors yellow cards for taking the short-sighted approach of “if it aint broke don’t fix it” because they don’t know enough about the code in question (or code in general IMO) to make that call. Surely there are cases when it’s better not to fool around with messy code when it’s fully contained and debugged, but this was not one of them.

As a result of my decision, nothing happened. This was in part because we didn’t tell anyone so in the end it was just two dudes talking about some work stuff. For what it’s worth, I remain very pleased with my decision.


Being Dufus

A former junior colleague of mine asked me for some career advice, which I confidently promised to offer. I’m fully entitled to offer such advice because I’m an experienced and wise engineer-turned-project-lead-who-also-architects-and-likes-to-talk-a-lot. I’m surprisingly good at keeping track of the big picture and never suffer from any bouts of complacency or tunnel-visionitis, unlike everyone else around me. Really, I’m pretty amazing that way.

The same colleague mentioned this book in an unrelated conversation. Even though I’m way past needing any career advice, I decided to give it a try because I had an open slot on my Safari books online and some time to kill.

Having read the first part of the book I realized I could easily spare the world of my career advice because there’s more useful information expressed more eloquently in there than I could ever muster. So, I guess that part’s done (check).

On to Part II: Deconstructing Management, there’s a pretty rare glimpse of the management from the point of view of the managed . Usually it’s the reverse, especially in those serious-looking MBA textbooks. It’s a vivid and slightly whimsical classification of different types of managers out there with all their insecurities, arrogance, indifference, and just plain old incompetence. Pretty entertaining read, especially if you vaguely recall having a few of those…

And then it struck me. Good God, I am a manager! Great, now I’m dying to know which type my team figures I am. Is it the Doof? The Leaper? The Interrogator? The Prioritizer? The Enemy? Come to think of it, I have no way of knowing that because I haven’t been giving them much attention lately what with all the messy code I’ve been digging through and intense correspondence I’ve had evangelizing my previous project…

So, dear former junior colleague, sorry it turned out I don’t have any advice for you. Also, thanks a lot for recommending that book – it’s great! Going forward, I will take it a step further and attempt to actively network with my guys, as defined in the book:

Networking is the art of finding those who are willing to listen to and critique your stories…

It’s funny how this actually summarizes all my complaints I’ve ever had about my managers. They clearly failed to network with their team. A little networking could have spared us a lot of morale damage…

Note to self: gotta network.