Hands-Off Managers

In my last post, I included links from Cate’s blog on how to be a good “hands-on” manager.

For example, a good “hands-on” manager:

  • Actively tracks direct reports’ progress.
  • Holds regular one-on-ones.
  • Advises on career path.
  • Intervenes to help with personal conflicts and organizational changes.

That’s really hard, and I don’t think I’ve ever seen the full package in my long employment experience. (Sometimes that that’s just because the team is too large.)

What I have seen frequently is the “hands-off” manager.

For example, a “hands-off” manager:

  • Talks to you only if there’s an issue or problem.
  • Provides little to no oversight.
  • Delivers bare minimum of a performance review.

The negative side of this kind of manager is that you get no support when things go wrong: you’re on your own to find solutions to your problems.

But that’s also the positive side. When you do something right, it’s not because of someone else’s input. It’s all you.

And “leave everybody alone unless something goes really wrong” is a lot easier than the first set of bullet points above, so you’re a lot more likely to find bearable “hands-off” managers than bearable “hands-on” managers: if there are fewer interactions overall, there’s less chance of bad interactions.

If you can’t have good managers, would you rather have a career full of so-so “hands-on” managers, or full of of so-so “hands-off” managers?

Advice for New Managers

Cate in the blog “Accidentally in Code” has a 5-part series on “Things to Figure Out as a New Manager”:

Part 1: Your Schedule

Part 2: Social Support

Part 3: Communication

Part 4: Feedback

Part 5: Trust

I could have used this earlier in my career.

I don’t see a lot of advice about managing in the tech industry in the weblogs I read. I’d like to see more. This is a good start.

A taste:

Because people are less likely to give their boss feedback, it becomes all the more important for you to give yourself that feedback to them. To own when you screwed up, and apologise. To acknowledge what you learned and what you would do differently. To recognize implicit feedback, and make it explicit between you.

Not That Kind of Troll

Looks like my first Entertainment post will be a review of a kids’ show.

Not just any kids’ show, however: as far as I know, it’s Guillermo del Toro’s only TV show, and it’s on Netflix: Trollhunters.

The good:

  • Amazing, movie-quality animation. It has a gorgeous, colorful 3D look, used to good effect on the non-human characters.
  • A fantasy world that seemed like a nice blend of del Toro’s usual penchant for the grotesque and the safer world of children’s cartoons.
  • Great comic timing. Lots of throwaway pratfalls and one-liners that made me think of Pratchett (high praise from me).
  • Some really fun writing and voice acting. Kelsey Grammer stole every scene he was in (and he was in a lot), as did Jimmie Wood as “Not-Enrique”.
  • Some nice character growth and a few notable turns. Not Shakespeare, but fun to watch.

The bad:

  • I disliked that “the girl” was just “the girl,” i.e. the romantic target of “the boy,” for maybe half or two-third of the episodes. We didn’t see much of anything from her side for far too long — though to their credit they eventually changed that.
  • One very very bad episode that was trying to skewer tropes about the tropical island Natives but really just ended up repeating them. Ugh.
  • Some sexist jokes involving a Barbie doll. Also ugh.

So yeah, there was some racism and sexism. I can understand if that’s a deal-breaker. I would hope they do better next season, if there is a next season.

They want to (the last episode ends on a cliffhanger), but here’s possibly the most interesting thing about the show: its lead voice actor was Anton Yelchin, who died in an accident in June of 2016. del Toro chose specifically to keep him in the show because he fulfilled his vision of the part so well.

But now they’ll need someone new.

Living in the Future

Now that I’ve announced the return of the old blog posts, let’s talk about the rest of the changes around here!

You may have noticed the new URL: apontious.com. With any luck, this will be the “last URL you ever need” to get to my writing. Old links with the subjectiveobserver.wordpress.com will still work as well — I plan on supporting them indefinitely — but please use the new URL whenever possible.

The blog’s name has also changed. I’m pleased to announce that this blog is the top hit on Google for “Weaponized Fluff,” which means my branding’s on point, right? Even if the name didn’t originally come from me. And if you come to the website, there’s a new black and white design that I’m pretty happy with.

Be warned: this will be more than just a technology blog. I may talk entertainment, I may talk politics (with comments off), I don’t know yet. If you just want the tech stuff, subscribe to https://apontious.com/category/programming-tech/feed/ or bookmark https://apontious.com/category/programming-tech/.

Living in the Past

Oh, we won’t give in,
We’ll keep living in the past.

— Jethro Tull

Lots of other stuff going on in the world, but for a moment, let’s go living in the past, shall we?

Let’s go back to a time when I wrote a website with a godawful color scheme and a prescient name. When Subversion was new, Unix was still old (but new to the Mac), and I used terrible puns for post titles — well, that hasn’t changed, has it?

When I closed down helpfultiger.com, I removed its posts from the Internet entirely. Now, with the relaunch of my blog on apontious.com, I’ve brought ’em all back, under the tag “From Old Helpful Tiger Blog”.

The technical how-to posts are mostly out of date, but there are lots of philosophical posts I still agree with. Have a look!

Edit: forgot to mention that the comments came over, too!

Boom Boom Enum

To quote a fairly awful movie: “We were so, so wrong.” — me

Remember I said you couldn’t use Swift value types for a linked list? The real reason is because you can’t have references to other value instances, just copies (thus making bi-directional linked lists a recursion nightmare), but the compiler error was “a value type can’t refer to itself”.

Turns out, one Swift value type can refer to itself: enumerations. By adding the indirect keyword, you can use Swift enums to, for example, represent a binary tree structure:

indirect enum Tree {
	 case node(Int, left: Tree?, right: Tree?)

And it works! But is it a good idea? Hell, no!

Why not? Because accessing the “properties” of your data structure is a pain in the ass:

switch node {
case let .node (data, left, right):
	// Do something with data, left, and right

As far as I know, you need an otherwise extraneous switch statement, a case statement, and an extra set of local variables just to access the values. (Whereas for a class all you need is dot syntax.) And you need to do that everywhere you want to access them, every method.

And the compiler will complain if you don’t use all of the enumeration values, so you have to remember to use _ for those:

switch node {
case let .node (_, left, _):
	// Do something with left

I tried writing a full tree traversal implementation in Swift with enum-based trees and it was an unholy mess that I would not repeat.

Learn from me. Don’t use cool language features at the expense of maintainability.

Interview Hullabaloo

I have one major piece of advice, if you’re interviewing for a developer job, or really if you’re interviewing for any job.

If you get the sense that the interviewer is dissatisfied with how you did, don’t hesitate to ask what they’re dissatisfied about.

For example: “It feels like I didn’t completely answer your question. Is there anything I could expand on for you?”

Or: “Did my solution to the exercise cover everything you wanted me to cover?”

If they just say yes, but they still seem dissatisfied, well, then there’s nothing you can do.

But I’ve often found that this will bring forward whatever reservations they have, and give you a second crack at them.

Dictionary Fictionary

See update below: it’s more complicated than I thought.

Over the last, what, decade or so? maybe more? people have been using the word “literally” to mean…not literally.

“Literally a monster.”

“Literally the worst thing ever.”

They don’t mean literally literally. They’re using it because it feels right, regardless of its actual definition. It can lead to some amusing results.

I’ve seen something similar in Objective-C.1

When array, dictionary, and number literals and object subscripting were introduced in Objective-C in 2012, people really liked them. Me too! They were literally mostly just compiler syntactic sugar, but they derived their usefulness in part from being vastly more compact and readable.

Because the new syntax is so nifty, people want to use it everywhere.

NSMutableDictionary *foo = @{}.mutableCopy;

instead of

NSMutableDictionary *foo = [NSMutableDictionary new];

for example. Are they equivalent? Well, this is what the first sample is generating:

NSMutableDictionary *foo = [NSDictionary new].mutableCopy;

Making two dictionary instances, only to throw one away immediately, just because you want to use shiny syntax, doesn’t seem like the best idea to me.

Array and dictionary literals derive the rest of their useful from not having quite the same rules as the old syntax.

Unlike for the old creation APIs, now nil is no longer used as the ending sentinel for the list of input values. So because they could, the designers of the new syntax disallowed it completely.

The amusing part? Recently, I had a coworker who swore you couldn’t set a dictionary value to nil, like this:

foo[@"key"] = nil;

What he was doing was confusing the new literal syntax rules with plain old NSDictionary APIs. It’s an easy mistake to make. The only reason I didn’t is because I have years and years of experience with the old APIs, which didn’t have the same hangups about nil.

So I could compartmentalize the new nil rules to just the new literal syntax, where they belong.

I literally needed to run example code for him to convince him that the above line wouldn’t assert.

Update: Looks like I was right for the wrong reasons.

Instead of it always working the way I thought, the current behavior is a recent addition. See Foundation Release Notes for OS X v10.11 and iOS 9, specifically this part:

NSMutableDictionary subscript syntax change
In OS X 10.11 and iOS 9, NSMutableDictionary now allows you to use its subscript syntax to assign nil for a key. Like Swift’s Dictionary type, doing so will remove an existing object for that key from the dictionary. In effect, the following lines of code are now equivalent:

[dictionary removeObjectForKey:@"Key"];
dictionary[@"Key"] = nil;

These new semantics exist only when building with the OS X 10.11 or iOS 9 SDKs. If your application’s deployment target is earlier operating system, then runtime support will be implicitly linked into your binary by Xcode to ensure the behavior works on any targeted operation system.

My mistake was assuming the subscript setter syntax was an unmodified usage of NSMutableDictionary’s setObject:forKey:, which in my recollection always allowed nil, but of course there’s no reason it would have to be.

And now, with nullability annotations, setObject:forKey: no longer allows nil at all! (Plus, on reflection, I think I was wrong about it allowing nil in the past.)

Thanks to Jordan Rose and others for the correction.

1. Somebody get me a storyboard, cuz I just made a killer segue! ↩︎

Link or Swim

I learned today that you can’t make a linked list in Swift using value types. The reason why ties into the pointers issue I was recently discussing.

Here’s how a linked list struct might look in C:

struct LinkedList {
	struct LinkedList *next;
	int data;

And here’s how you would do it in Swift:

struct LinkedList {
	var next: LinkedList?
	var data: Int

The difference is, in C, you can have a reference to a struct without making a copy — without it being the thing itself. By adding an asterisk and making it a pointer.

In Swift, you can’t do that. So a reference to another struct might as well be that other struct, even if it isn’t always, under the hood.

If I try to compile that Swift, I get the error “value type ‘LinkedList’ cannot have a stored property that references itself”.

If I change the declaration from struct to class, then it compiles fine, because the property representing the “next” instance is now a reference to it.

I wasn’t expecting this issue to come up again so soon in my work.

Poll Position

I conducted a Twitter poll recently because I was curious: when I use Objective-C for my coding examples on this blog, does that still seem normal to my readers, or does it seem like some weird ancient relic of a bygone era?

Now, my Twitter followers and my blog readers might not be exactly the same, and there were < 40 responses so it’s not a huge sample, but I still think the results are illuminating:


There’s no clear majority. About the same number are using primarily Swift as primarily Objective-C.

That sounds about right to me.

And it means I don’t need to change my ways this second.

But I do plan on switching over to using Swift for my coding examples at some point during the year.