Forem: eheiberg

"One hand down, one hand up" - the ideal work environment

eheiberg — Tue, 24 May 2022 21:07:51 +0000

In the last 20+ years, I've seen plenty of success and plenty of dysfunction across companies, teams, and projects. But the teams I wanted to be on - the companies that performed the best and had the most fun doing it - always had one very distinct similarity: from the top down, every person would have "one hand down and one hand up".

This can be a personal mantra, or a company-wide philosophy, but in then end, the people and teams I want to work with are explicitly asserting value to these concepts.

One hand down

tldr; Be the kind of person that gives the next person a leg up.

A person who extends a hand down ensures that a portion of their workload is making sure the next person can follow. This can manifest as clean code that tells the story of the code as well as the implementation. It could mean adding documentation when you hit a snag and don't want someone else to hit the same one. It could mean deliberately carving out time out of your work schedule to ensure that other people have resources and guidance that you might not have had. Whatever it is, you have "one hand down" to lift someone else up. It's ready and available, and most importantly you advertise it.

One hand up

tldr; Be the kind of person that looks for advice and direction.

Not looking for advice or direction is a sure-fire way to lock everyone on a path that only you know how to navigate.

It makes no difference what your position is within a team or a company - there is always something to learn for the truly curious. Even getting advice from someone who is not at your skill-level can be incredibly illuminating. It can show you better ways to have a "hand down" as well - and in ways that will always surprise you.

Most of all, a person with a hand up shows that they are listening and are willing to be changed by what is said. This isn't just something that benefits you, but is a model that extends to anyone who is inspired by you.

Why we need both

Below are my personal observations of what I've found to happen when both conditions are not met. These are not at all uncommon, and you've likely encountered at least one of these before, if not all of them.

The "arms crossed" effect

Many of the bureaucratic companies and organizations I've worked at or had adjacent experiences with wind up ensnared in this model. Everyone is waiting for their pension, and everyone's top priority is simply to keep their job, so they keep their head down and only concentrate on the work that was assigned to them. This is the "arms crossed" effect.

Nobody is looking for advice or direction because this will make them look stupid and incompetent.

Nobody is trying to help anyone else up because, what if someone else learns how to do what you do?

The "one hand down only" effect

One very over-taxed person or team is handling everything. This one over-taxed person quickly becomes a single point of failure, and when they leave or retire, the whole company enters into...

The "one hand up only" effect

At this point, everyone is looking for direction, but everyone is too busy getting their work done to help anyone else. This is where you have "write-only" code that nobody wants to wrangle. There is no attempt at documentation or training.

Ultimately, a re-write of the entire code-base is going to be suggested, because the archaeology of trying to figure out what the heck is going on would just take longer, and likely just perpetuate the cycle. Needless to say, this is costly.

In a perfect world...

From the get-go, apportion time in every person's workload for "putting a hand down" and "putting a hand up". It's never too late to stabilize the cycle.

This is a much better model than just getting into trouble and hiring as many 10X developers you can to help you row the boat faster toward the rocks.

Final note: nomenclature persists

Hopefully you find this concept and phrasing useful. For me, an easily grokable concept that can be boiled down into simple phrasing gives me the most movement toward that idea. This idiom happens to represent my personal approach. I hope it has some merit for you as well.

Thanks for reading!

The 10 Times Rule - Be kind to yourself [and others]

eheiberg — Mon, 10 Feb 2020 21:01:59 +0000

In 2000, I was a small business IT contractor. I would rove from small business to small business putting out fires and setting up networks.

If I'm to set the stage for what a layperson's idea of "computers" was at that time, I could probably sum it up in the following bullet-points:

People's resumes would commonly contain a "Computing Skills" section, which more frequently than not, contained every app they had ever used: "Microsoft Word 98, Microsoft Excel 95, Microsoft Word 2000...", as well as broad concepts like "Ethernet and Internet"
Most people were still talking about the Internet as something that a computer had or didn't have.
I would frequently get calls to replace the toner in the printer, because "the printer isn't working, and I don't want to mess it up".

Much of the small business computing world was in a churn that they never signed up for, but were now suddenly obligated to participate in.

That being said, a sizable portion of my job was convincing people that "computers" was not something they could work around, and that they were going to have to fit some basic computer-operation fundamentals into their brain-space just to be competent.

I made a passing effort to be gentle, but, to my shame, I frequently fell into the "Brilliant Jerk" role more than once.

One day...

One day, a sales manager at one of these businesses, Preston, called me in for a computer issue.

This was a computer issue that:

Was a user error.
I had fixed before.
I had shown him, in detail, with written instructions, how to not perpetuate.
I had shown him, in detail, with written instructions, how to fix if he did mess it up.

Frustrated, I snapped at him, "How many times do I have to tell you not to do this?!"

Without blinking an eye, or with any hesitation he replied, "Ten".

"What?"

"Ten. Ten times", he was calm about it. He was calm about things in general.

"Look, I've got a million things I'm doing and having to remember at any given moment - things that have nothing to do with computers. I know I'm asking you something you've already explained to me before - I get that. I understand that frustration - anyone would. So I'm making a deal with you - if, after 10 times, I don't get it, you can yell a blue-streak at me. Ok?"

That moment did a couple things for me. I put some pretty obvious things back in perspective that I had woefully overlooked:

Your priorities can't be everyone else's, and rarely are.
Repetition is not just a valid path to learning, it's a useful one - particularly when the thing to be learned is not someone else's priority or is something they feel is even their problem to solve.

Introducing The 10 Times Rule

I tried it out, of course, and not just internally; I was explicit when I used it.

What I mean is, whenever someone made a mistake they had made before, they would apologize to me profusely, and begin either the process of (a) self-flagellation or (b) become defensive and despondent.

Before any of that could happen, I would tell them about the 10 Times Rule. I would tell them that they're fine, they've got at least [7] more shots at this. This is simply part of the process.

[IMPORTANT: This isn't holding someone to "10 Mistakes" - this is 10 times making the same mistake. Thus, every mistake has a queue of 10.]

The results

The results were probably what you'd expect if you've read this far:

People usually need the repetition 2-4 times; nobody ever gets close to 10.
The issue becomes part of their habits and rules, as opposed to an obligation to adhere to "someone else's" rules.
I actually feel better, knowing that this is simply part of the process as opposed to a failure in the process.

Note: This isn't just blanket forgiveness

This is better than blanket forgiveness - it's an easily achievable shot at accountability. After doing this for well over a decade, I found that when you give people a chance to make the problem their own, they begin to care about it in a way that is, again, their own. And when they feel it's their own, they truly become your ally in solving that problem, or even keeping it solved.

"Not my problem!"

Conversely, if you berate someone, or treat them unkindly for ruining something that they they feel is largely your problem to begin with, you perpetuate the idea that it is, indeed, your problem.

They're problem, by extension is simply finding ways to avoid having to deal with you.

And remember, blanket forgiveness doesn't work either. If you apply blanket forgiveness to everything, it will also never garner the result of the problem being their problem too, as you will always be their own personal airbag for their reckless driving.

By giving them an easily achievable goal, they can claim mastery, and as it turns out, humans really seem to dig being good at stuff.

Wait a minute, isn't this just building in room for failure?

Good eye! It is! And it turns out, people much more well-versed than I have written extensively on this. This was simply my own personal path to get there. Maybe it will help you too.

But wait! What about...

This next paragraph is mostly for the Edge-Casers out there (I count myself as one of them, so I get you).

Yes, if you're a doctor who keeps amputating the wrong leg, or a firefighter who sprays the wrong house, or a zookeeper who keeps leaving the lion cage door open - if the mistake is something that we cannot allow to happen more than once, then yes, you probably shouldn't try to apply the 10 Times Rule.

What I am asking of you is to evaluate if the 10 Times Rule is even possible, and if it is, try it, and let the results speak for themselves.

As with anything, let the Practice prove itself to you.

And as always, thanks for listening.

Better lessons from [No] semicolons in Javascript

eheiberg — Thu, 06 Feb 2020 23:41:14 +0000

Full disclosure: I don't like semicolons in Javascript

I started like most people, using semicolons, and when I switched to no semicolons, it did feel a little strange. In time, I found I really enjoyed not having them, despite some potential pitfalls¹ that I rarely [if ever] run across.

Wait! Don't go!

Believe it or not, this is NOT just another article about semicolons in Javascript. This is really about a tool you can use when trying to make decisions with your team.

Actually, this is actually an article about something far more ambitious:

I want to propose a tool to help you make decisions in things outside code as well.

Ok, this is likely a promise I can't deliver on, but bear with me for a bit; for now let's just take that statement as a clear LIE, and maybe by the end of the article we'll see just how true [or false] it is. Thank you for reading! You're the best!

How this started

I'm not a great Javascript programmer. If I had to describe myself, I would say I'm just someone who hangs in there.

One day, my brilliant devops manager dropped in some code to standardize and set up the codebase properly. One of his changes was to take out all my custom linter rules [like semi: never'] in favor of the standard, out-of-the-box rules.

Not being a great Javascripter, I thought maybe he knew something I didn't, but it turns out that wasn't the case, and so the discussion began:

Our individual points, boiled down

ME: "WAAH! I don't want to use semicolons!"

DEVOPS: "Uh, Javascript uses semicolons, my dude."

And thus, the research began! To the Internet!

The resulting research

I'll spare you the headache of having to look all this stuff up on your own with a nice, easy, bulleted list of what we found:

There's no clear winner, one way or another². (sorry!)
USE A FORMATTER, YOU FOOLS!
People who write about this claim they don't really care, but their words usually betray a clear preference - one that if they had to go against, they would very much grit their teeth through.

So which should we use? I don't know the answer for you or your team, but this was a good opportunity for me to apply a tool I've been using for the past 6 years to police my thinking somewhat.

The Tool

You made it this far. Thank you. Here's the tool I was talking about earlier:

When given an option to switch to something else, flip the history and see if your opinion changes.

This tool has been invaluable to me in making decisions, and in policing myself when I find myself resisting change. "We've always done it this way!" isn't useful in life, let alone in the ever-changing world of computing.

Putting it to the test

Let's take this thing out for a spin, shall we?

Let's flip the history of Javascript semicolon policy. Let's say that Javascript always had the policy of "no semicolons"¹.

One day, maybe a decade ago, someone pitches the NEW idea: "Explicit semicolons!". Now, we can finally start adding them, not just to the edge-case lines in our code, but to every line that we feel should have explicit termination. And obviously, we're not dummies, so we'll get our formatter to do it for us as well, just as we do now. Better, right?

Yes? No? Maybe?

Regardless of what you choose, we've removed the condition of which came first as a criteria for which version to implement. Because primacy is a real thing that we're all going to struggle with, so it's great to have tools to address it when we can.

I've struggled with this before

When I moved from PHP to Ruby years ago, Ruby introduced me to the world of implicit return.

The dirty summary of implicit return is this: Ruby will automatically return the last line automatically.

Now, if you were like me, you would probably have thought "This is crazy. I'm gonna be making mistakes all over the place". In a small way, you're right. After programming in Ruby for ~15 years, I can tell you there are plenty of times where I've accidentally screwed myself by putting a logging statement at the end of a method, and then wondered why the method was returning the wrong value.

def allow_mega_super_access?
  @user.admin?
  Logger.info("Only super-privileged users should get through! WE ARE SOOO SECURE!")
end

And yeah, I have fun dreaming up the worst example I can think of, but you know what? I make mistakes constantly, and when weighing all the mistakes I've made from my improper use/reading of implicit return VS all the benefits I've garnered from implicit return, the tally isn't even close. Implicit return is the bees knees, y'all.

And when I apply the tool and flip history - either way I flip it, implicit return is the reigning champ in my mind, hands down. I wish all languages had this. Of course, your results may vary.

But let's take a look at this tool outside of the realm of programing, as promised.

I seriously just applied this technique as I was writing this article

Ok, in some kind of cosmic lesson, I self-applied this rule to this very article as I was writing it.

In my original draft, I was using title-case For All My Headings and Titles. In the middle of writing one of the headings, I asked myself, "Is title-case better?" Even if it is considered grammatically correct, should I use it?

So, once again, I flipped history to see if my opinion changed:

What if we had always used "Sentence-casing" for our titles, and someone, very recently introduced the idea of using title-case. Would we see that as a better alternative?

Now there might be really great reasons to title-case your headings that I'm woefully ignorant of³; if that's the case, I hope those really great reasons will inform my future self when I re-evaluate based on that new information.

For now though, my only reason to use title-case for headings is "It's always been done that way".

And if that's true, then it might be time to re-think that idea.

PLEASE UNDERSTAND: This is not a silver-bullet for decision making!

What this is is a tool to minimize primacy/recency from your decision making. That's it.

You don't have to defend against it or for it, because, as of now, it is your own thought-experiment. Yours. Use it as you see fit.

Promise kept?

That's it. Hopefully you found/find value in the tool I mentioned, and my ambitious statement at the top wasn't too much of a lie. The only way to know is to try it.

Thanks for listening.

"no semicolons" is a misnomer, as you still have to use semicolons on certain cases ↩
Hey look, the AirBnB styleguide makes a really great point about how you should use semicolons here. The dirty summary being javascript changes a lot; semicolons keep us safe[r] during these changes. Which is weird, because the ready-acceptance of all the constant javascript changes is actually a big part of why I think I should not use semicolons. ↩
I bet Chicago and AP style-guides have reasons - reasons I would probably look up if I was a diligent writer... Which kind of makes this "footnote" completely worthless when you think about it. ↩

Code-Signing a Windows app on a Mac using electron-builder

eheiberg — Thu, 30 May 2019 18:06:01 +0000

tldr; skip to the end for the step-by-step instructions.

I made my first desktop app, using Electron (and Vue).

If you don't know what Electron is, the high-level description is that it's a lovely wrapper around a chromium browser. This means you can turn a nice single-page web app into a desktop application, using web tech you already know - javascript, css, html. It's pretty great.

[And if you don't want to start from scratch, you can use Vue, and the amazing electron vue-cli builder plugin (https://nklayman.github.io/vue-cli-plugin-electron-builder/), which is what I did because I am lazy]

App Created! We're done! Right?

Well, no. You've made the electron app and now you have to code-sign it, unless you don't mind that your users are getting security warnings.

I'm on a mac. The actual code-signing was a pretty easy process once I managed to find the relevant links. With adequate google-fu, you'll find out how to do it without too much fuss. I'll skip past code-signing mac apps, because other folks can tell you how to do that ok.

Windows, on the other hand ...

Trying to code-sign the Windows build of your application from a Mac is dark magic, it turns out, or at least that's the way it seems to be described; lot's of "brew install" this and "source compile" that. You'll find plenty of articles on it. Do they work? Who knows? None of them seem to be saying the same thing, and if they are, I'm certainly not proficient enough to figure out what they're trying to get me to do. And when I do follow those old instructions, it turns out something else breaks or doesn't work. This is rough going. There has to be an easier way, right?

electron-builder

It turns out there are different plugins you can use to compile your source into a nice build. The one that was chosen for me by the Vue Cli was electron-builder.

They have some decent documentation, but as of 2019, some of it gets really confusing really fast. I'm not going to link to the documentation in question, because I'm sure at one point, it was working great. Just like this will probably work great for you in 2019 and maybe not so much in 2023, etc etc.

Get to it already!

Here are the steps I took to code-sign a Windows app from a Mac in 2019

Make a CSR (certificate signing request) using Keychain Access (a program on your mac). Use "Certificate Assistant" from the menu.
Make sure to select "Save to Disk" for the CSR
Buy a code signing cert from a cert authority (https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate). Use the CSR you generated earlier when it asks you for it.
Download that cert. Install it in your keychain. (using Keychain Access)
In Keychain Access, find the cert, and export it as a .p12 cert.
On export, notice that you have an option to supply a password for the cert. You can if you want to, but you can also just hit 'enter' and provide NO password.
When you build your electron app for windows, specify the path to the .p12 cert. WIN_CSC_LINK=/path/to/your/cert.p12 yarn electron:build --win

Note: in Step 6, you do not need to add a password, but if you do, then in Step 7, you need to also add in the ENV variable of WIN_CSC_KEY_PASSWORD=YourPassword as well to that command line in order for it to be able to parse the certificate properly.

You should be able to see by looking at the build log that the certificate is signed.

Last Note - Microsoft SmartScreen

Microsoft Smartscreen doesn't just care that your app is code-signed properly; it's also looking at your reputation. And thus, if your app is new, then your users will likely get a warning screen from Microsoft SmartScreen until your app has proven itself to not be some kind of password-stealing ransomware sleeper agent. The cert is published though, and so this should be the only warning, if any, that you get.