Earn Trust – Page 4 – Making Of Things

Ketchup

By Jud | February 5, 2021 | Comments 1 comment

I’ve written a couple of posts in the past that provide an outline of my career progression. Today’s update is in that vein, as I’ve taken on a new role as a technical manager, getting back into people management after a few years off from it.

I was chatting yesterday with one of my new team members, and he asked me a pointed question. Paraphrased, “Given your technical background, why would you choose to be a manager?”

On my résumé, I describe myself as having

a keen interest in architecting systems that are secure, scaleable, and cost-effective, and then building the organizations best suited to implement them

And therein I think lies the reason. I’m a builder at heart, to which this blog’s domain name testifies. And building great solutions requires building great organizations, and it’s that latter team construction which is a manager’s primary responsibility. So I think it makes sense that the builder mentality can carry over to people, even if the technologies involved differ.

Here’s a great upcoming year!

Slacker Part Deux

By Jud | September 1, 2020 | Comments 0 Comment

The advice in Five Nonobvious Remote Work Techniques is broader than just Slack, but given my prior post on best practices, I thought I’d mention it for further reading.

Technique number three from that article made me think of an additional helpful hint for Slack conversation. If you initiate a conversation via at-mention, you should be prepared to dialogue in real-time. There’s a cost to causing an interruption to another person, and one should try to minimize the duration of said interruption by treating the interaction as if it was an in-person conversation.

Also, No Hello. Get to the point.

Be A Slacker

By Jud | August 11, 2020 | Comments 0 Comment

No online collaborative tool is perfect, but when used well, Slack is pretty close. Having participated in multiple Slack workspaces across several organizations over the past few years, I’ve become somewhat opinionated (and hopefully qualified) on what constitutes “used well”. Here’s my take on some best practices:

Set up your profile with your real name, and add a high-quality photo. This helps interactions feel more personal, and when communication is done primarily over the Internet, every little bit helps.
Set up notification rules and a do not disturb window in preferences.
Strongly consider disabling audio notifications, as they can be a distraction to those around you.
Conversation in public channels is always the preferred approach.
Single-user DMs are acceptable for private conversation, but consider if your discussion might be valuable for others to see and contribute to. When in doubt, go public.
Group DMs should almost never be used unless the topic is sensitive and needs immediate response. Otherwise consider using a public channel with @mentions.
Temporary channels are an acceptable alternative to group DMs. Prefix them with temp-, and /archive them when conversation is complete. Typically these should not need to exist more than a day or two.
Discussion in a public channel where response from a specific small group or individual is needed can be easily accomplished through use of @mentions. Brief side discussions can be done with threads vs. splitting off into a new channel or private DM.
@channel notifies all members of a channel, even if they are outside of working hours, and should be reserved for emergencies. @here is almost always more appropriate, as it only notifies members within working hours. Even better is a small list of specific @mentions.
Use /mute when you want to stay in a channel but not get notifications from it. @mentions will override mute, so you’re still reachable.
Use /dnd when you need to ignore all notifications for a period of time (e.g. to go heads-down on a task, you’re giving a presentation).
Consider turning off message preview in notifications, unless you want to run the risk of a sensitive (or embarrassing) message being viewable by others.

Happy Slacking friends!

On The Shoulders Of Giants

By Jud | August 10, 2020 | Comments 0 Comment

I took an entire class in compiler theory in college, and really enjoyed it. Can still picture the classroom in my head, in fact (3rd floor of the ENS, all the way in the back past the nursing lab). So how is it that I never learned of Frances Allen, who died last week at 88?

History is a thing that few understand in its entirety. It’s usually treated like a separate subject, but at minimum each of us should endeavor to understand the history of our own fields of study.

Descend Into The Particulars

By Jud | July 19, 2020 | Comments 0 Comment

When I’m asked about interview advice, one suggestion stands far above the rest: be specific.

I want to hear real stories about events that actually happened, not hypothetical situations you might come across in the future. Having a real story to tell that only partly addresses the question is better than a direct answer with no experience to back it up.

Tell me the actions you individually took in the situation, not what the team generally did. A job interview is not the time for false modesty. Be humble and honest about it, of course, but you’re the subject of the interview, not your colleagues.

Explain not just what you did, but how the situation turned out. What were the actual results? If you have metrics or other data you used to measure the outcome, even better, and if you can quote actual numbers, that’s the holy grail.

Finally, what did you learn from the experience, and how would you apply that to future situations? A discussion on learnings is never out of place, no matter the interview question.

Bonus tip: don’t be afraid of negative examples. No one is perfect, and most future successes are predicated on prior failures. As long as you can articulate how the situation changed you for the better, it’s a plus in your column.

Hitting The Links

By Jud | April 21, 2020 | Comments 0 Comment

And further, from these, my son, be warned; the making of many books hath no end – Ecclesiastes 12:12

One could spend the entirety of their waking hours reading articles on software engineering. While I try to keep up the headlines, I aim to limit myself to 10-15 minutes a day. Anything more proves a burden.

Over the past couple weeks there’s been a few discussions I’ve found particularly helpful. The first, On Being A Senior Engineer, echoed thoughts I’ve had for some time. I do believe the title of “Senior” is handed out too quickly in many parts of the software development world. This probably makes me sound like an angry old man, but no one should be called senior until they have at least ten years under their belt, if not fifteen. To quote Andy Jassy, “there’s no compression algorithm for experience.”

I also appreciated the article’s emphasis on sponsorship. Being a senior engineer in my view has little to do with your technical breadth or depth. The step up to senior means that you’re now looking to expand your influence beyond what your own two hands create, whether that be being a team lead, one-on-one mentorship, or participation in the larger development community. Senior engineers recognize that building great software is a human activity, and develop their soft skills.

Finally, a crucial aspect of being a senior engineer is humility. I view this as a complement to what Larry Wall famously said, and not in contradiction. It takes maturity to know what you don’t know.

JaPythoScriptML

By Jud | June 19, 2018 | Comments 0 Comment

More and more I’m discovering that I consume media on my laptop instead of traditional “living room TV”. To some degree it’s a resource contention issue with the family, but even when the TV is available I find watching on a personal device simpler.

An unexpected side effect of that is that I find myself taking screenshots and closely inspecting examples of “source code” that appear onscreen (my genre of choice is sci-fi, so there are plenty of opportunities). The following is from an episode of Westworld:

Looks like some odd mixture of HTML, JavaScript, and Python. Clearly some design work went into this display, even though it was only shown for about second. I can’t help but wonder whose job it is to build out these designs. Must be fun.

This Is A Post

By Jud | December 1, 2017 | Comments 0 Comment

A friend of mine suggested to me a few days ago that the recent Apple vulnerability might have been avoided if the (supposed) offending code had been commented. Perhaps, but perhaps not.

Code comments are a tricky business. Everyone knows they’re a “good thing” but that doesn’t mean every comment is a good one. Blindly them in quantity can actually make code legibility worse. I don’t go as far as Uncle Bob, however, who considers every comment “a failure to make the code self-explanatory.”

For me, a great rule of thumb is that code itself should be expressive enough to communicate the “what”, and comments should be used to explain the “why”. An example is instructive:

# If user is root and there is no root password, don't do the thing
if user == 'root' and password is None:
    dontDoTheThing()
else:
    doTheThing()

See how the comment doesn’t provide any information beyond what the code says? Pretty unhelpful. What a developer who’s asked to maintain this code needs is context, like the following:

# By default an installation of MacOS does not set a root password, thus root
# should never be used as a privileged account unless a password has been set
if user == 'root' and password is None:
    dontDoTheThing()
else:
    doTheThing()

Much better. A comment like that, and maybe Apple doesn’t end up in the headlines.

Trump Card

By Jud | May 19, 2017 | Comments 0 Comment

I’ve had the opportunity to perform a bunch of job interviews in the past couple of years. It’s been a tremendous learning experience, and I’ve enjoyed contemplating the various psychological factors that go into both interviewing and being interviewed.

My quip from a few days ago was mostly tongue-in-cheek (sorry, dear wife), but if you do want to impress me in an interview, take some time to tell me everything you don’t know. Yes, you read correctly. I want to hear about your ignorance.

You see, there’s a well-documented psychological phenomenon called the Dunning-Kruger effect. It’s a cognitive bias where the incompetent person, due to their incompetence, lacks the skill to evaluate their own shortcomings, and hence overestimates his own capabilities (the opposite effect is known as Imposter Syndrome). I’ve seen these play out time and time again as I’ve evaluated job candidates; in fact, I know of no quicker way to get a general sense of a person’s skill. Besides, describing shortcomings demonstrates humility and self-awareness, two valuable personality traits in any field.

The domain of software development is immense; no single person can possibly know even one-tenth of one percent of what can be known (we’re all only human). The best developers know this, and can describe the boundaries of their own knowledge. Those who cannot probably have no idea what they’re doing.

Developers Have Personalities

By Jud | April 26, 2017 | Comments 0 Comment

The first 12 years of my career I worked for a large defense contractor. One of the perks of a big company is opportunities for training, and in 2009 I had the privilege of taking a year-long “front-line” management class. Some of it was corporate drivel, but a surprising majority I found useful. One area of focus was on personality testing and analysis.

Why would that be of importance to managing a software team? Well, as I’ve said before, software is written by humans, and understanding how to get the best work out of said humans is a critical part of management. One way to do that is to learn the personalities of each member of the team.

During the training we used the Myers-Briggs Type Indicator, but the new hotness is the Enneagram. I’ve listened to a podcast and have also started a book on the topic, both of which were particularly focused on the spiritual aspects of self-understanding. But I think there’s plenty of cross-applicability to the world of management, and I look forward to exploring that in the coming days.

P.S. I walk the line between INTJ and INTP, and am either a Five or Nine (still figuring that one out).