melreams.com

Nerrrrd

Terrible ironies of programming: people

In my last post about the terrible ironies of programming, I foreshadowed the next terrible irony:

Plus being at a computer and away from people is pretty attractive for weird little nerds who aren’t good with people

So many people go into programming thinking they’ll be left alone to code then find out programming is fundamentally a team sport. Even I used to joke that I didn’t decide to work with computers because I like people so damn much (I’ve since knocked that shit off because it’s obnoxious). I’ve come a long way, but I was an extremely shy child. One of the things I love about computers is that they make sense to me in a way that people just don’t. While I eventually came around to the idea that getting people to work together is a really interesting problem, it took over a decade.

But that’s a separate blog post! Let’s talk about one of the reasons software is a team sport: software these days is just too big for one person to build the whole thing and hold it all in their head. I say “these days” like have things have changed since software engineering first became a thing, but the top performers have always been the people who can get their questions answered faster* – it’s just more of an issue now as systems become larger and larger.

You might think that the answer to systems being too large for one person to hold the whole thing in their head is to split them up into microservices, but that just makes the people problem worse. It’s incredibly common for two people (or teams) to have slightly different understandings of what they’re building, and the more interfaces you have with other systems the more likely you are to slam face-first into that problem. Oh and if your microservice only interfaces with one other system, you should be thinking about whether it really needs to be a separate service.

Anyway, the fun thing about people having slightly different understandings of what they’re building is that you think everything is fine until everything is merged and you try to use it and surprise! It’s broken! Wheee! Building to a spec is not that hard. Making sure everybody on both sides of the spec interpreted it in exactly the same way is that hard.

Also like I said in my last terrible irony post, humans just kinda suck at programming. We need each other’s help constantly. Even if you never speak to anyone outside of your dev team and manager, you’ll still have to talk with them constantly. The lone programmer in a basement office may have been a thing in, like, the 80s, but the 80s are over, man (in case that link stops working, it’s the scene from Formula 51 where the state trooper tells Samuel L Jackson’s character that “the 60s are over, man”).

Even then, programs were getting too big for one person to know everything and even then the top performing programmers were the ones who a) knew who to ask when they had a question and b) were nice/known enough that the person they needed an answer from would get back to them in a timely manner instead of whenever they damned well felt like it.

I’m not convinced there has ever been a time where programmers didn’t need to talk with other people, we just wish there was because a lot of us nerds fantasize about being left the hell alone to code. I’m not even saying I’m not one of them, one of my favourite coding days in recent memory was when I got to put my headphones on and spend a day banging out a Python script to parse a particularly uncooperative set of log files and not talking to anyone. The thing is, that’s the exception, not the rule. As uncooperative as those log files were, they were based on an extremely detailed spec and once my tech lead told me which characters should be parsed into which field, I was good to go. Normally software isn’t nearly so well defined.

And anyway, that’s just between devs. If you have a separate QA team you need to talk with them too, both to make sure they understand how to test any given ticket and to make sure you understand what’s wrong when a ticket fails QA and comes back to you. If you have a product owner or product manager you’ll need to talk with them a lot to make sure you’re actually on the same page.

One of my big fuckups at a previous job was getting together with another dev and our manager and deciding without the PO that integrating our project with a certain existing feature we knew a big client wanted the new feature to work with was just not going to happen. Yeah it turns out that feature was a massive part of that company’s business and there was no point building the new thing if it could never work with that particular existing thing. Our poor PO sure loved that surprise when she looked at my edits to the internal wiki page for that project. There’s plenty of blame to go around on that one but as the acting team lead on that project I should’ve known better than to make a decision that far-reaching without the PO.

If you’re doing any frontend work talk with your UI/UX/designer too! I haven’t done much UI lately but even I know it’s important to be on the same page as the designer. You need to make sure you understand what the design is meant to accomplish, not just what elements you see on the wireframes or mockups. And show your designer your progress as you work through the ticket, that can uncover misunderstandings you didn’t think to ask about.

Don’t forget showing your work to actual users too. Nothing you build matters if nobody can figure out how to use it if they even wanted to in the first place. Coast Capital’s old useless activity log, I’m looking at you. I promise you it’s okay to display table data in a fucking table, you don’t have to show me almost nothing and make me click on things over and over to get any details. Also if you’re going to display a small and largely useless subset of data that appears in another report, just add another filter option that report. Between design and implementation that activity log burned at least a week of time that neither the designer or developer is ever getting back.

Your application doing the wrong thing very quickly and accurately isn’t actually useful at all. It’s not useful either if everyone hates it so much they just won’t use it. Coast Capital’s old  nearly content-free activity log, I’m looking at you again. You really do have to talk to people to build anything meaningful! Even if you build a small app all on your own and can hold the code in your head, you still need to talk to your users.

The extra fun part is that even if you personally accept that you have to talk to people to get shit done, you’re probably working with people who haven’t accepted that yet and you’ll have to pull teeth to get them to tell you wtf they’re up to, wtf their problem is with your code (ask me how much of a disaster code review can be, I dare you), and why the hell they did it that way when you told them already what you were planning and now nothing works because their part doesn’t integrate with your part correctly.

And that’s assuming everyone you work directly with shares your goal of producing realiable software that makes users’ lives a little bit easier. I have another blog post coming about coworkers who couldn’t give less of a shit about users, the company, their coworkers, or anything except getting their way.

* The Psychology of Computer Programming, Gerald M Weinberg. I’m entirely too lazy to look up the page number but I swear it’s in there.

Management tip of the day

Decorative photo of slightly golden sunlight shining through a confirous forest.
Unrelated photo by Lorenzo Hamers on Unsplash to make this post look nicer in social media shares.

When you ask your team for an estimate for a project, don’t give them an estimate to start from. If you do, you’ll likely cause anchoring bias. If you’re right, no harm done, but what if you’re not? I mean, the point of asking your team for an estimate is to get another, likely better informed opinion on how long the project is likely to take. If you accidentally bias their estimate you’re kind of defeating the purpose of asking them in the first place.

The context here is that I’ve been slowly reading Dr. Jorge Aranda’s Master’s Thesis Anchoring and Adjustment in Software Estimation while I’ve been on vacation because a) I kinda suck at estimation so the title looked very relevant to my interests and b) I have issues and it’s easier to for me to relax if I “earn” it by doing something useful.

Anyway, what Jorge Aranda’s experiment proved is that anchoring bias does affect software estimations. I haven’t finished reading it yet so the actual conclusion may differ from what I’m saying here, but I’m pretty confident about saying that if you want an accurate estimate you should avoid doing things that will obviously hit your team’s natural cognitive biases, like giving them an anchor. I’ve done that tons of times myself, I thought I was being helpful by giving my team my best guess and asking for a quick yes or no. It turns out that’s a bad idea, especially for large projects. For small tasks the harm you can cause is pretty limited, if you guess two days and the change actually takes three, meh. But for larger projects, if you guess three months and it actually takes four or five, now your boss is probably going to ask you a bunch of uncomfortable questions. Spare yourself and your team some stress by trying not to bias their estimates.

PS: Happy new year!

Link of the day: Decision-making matrix

One of the problems that really interests me lately is decision-making. Specifically, how teams can make decisions without wasting a ton of time going back and forth about what they’re going to do, and how they can prevent time-thieves from re-opening decisions they weren’t happy with.

The simple matrix described in This Matrix Helps Growing Teams Make Great Decisions at First Round Review seems like a fantastic alternative to endless circular discussions. Granted, I’d also prefer a swift kick in the shins so that’s a low bar, but the matrix is probably more effective :)

If you just want to see the matrix, search for this paragraph

It starts with a basic chart, with the two (or more) options you’re deciding between at the top. Down the left-hand column, you have benefits, costs, and — uniquely — mitigations.

That’s the core of the idea, but seriously, go read the article, especially the examples. They do a great job of showing how that matrix can help with extremely contentious decisions like whether or not to have descriptive titles for developers or just have everyone have the same title, or whether to refactor a large application. Those are the exact kind of things that waste enormous amounts of time and end with everyone unhappy if they’re handled poorly.

Another handy thing about a matrix like that is it really lends itself to documentation, whether that’s a page on your internal wiki or just a text document in a shared drive. With documentation like that, you can point a wannabe time-thief to it and go on with your day, and it’s super helpful for new employees to be able to see the reasons decisions were made. If you’re extremely motivated, you could even collect a bunch of those matrixes from past decisions and do a retro on your team’s decision-making skills.

Terrible ironies of programming: feeling stupid

There are a bunch of bitterly ironic things about the software industry. Let’s talk about one of them!

Programmers love to feel smart and chose a profession that makes us feel stupid all the freaking time. I don’t know anyone who doesn’t like feeling smart but let’s be honest, programmers really like feeling smart.

So many of us were weird nerds as kids and being smart was the one thing we got praised for, so we tend to build our entire identities around being smart. And thanks to rampant gate-keeping and teaching methods that only work for a minority of students, it’s really hard to learn to code so people assume that anyone who can get a computer to do what they tell it must be extraordinarily smart. I maintain that learning to code is more of a matter of stubbornness than cleverness but that’s a different blog post :)

Plus being at a computer and away from people is pretty attractive for weird little nerds who aren’t good with people (why yes, I am foreshadowing another terrible irony post), so we end up working as programmers. Where… we end up feeling like complete idiots at least twice a day. Yay.

For example, I freaked myself out the other day by missing a step while I was testing a complicated bit of code before I committed it. Turns out it works better when you actually do all the steps 🤦‍♀️. I can’t even tell you how many hours I’ve wasted trying on silly mistakes from deploying to the wrong server to messing up my application config to querying the wrong table to outright forgetting to test part of my ticket before committing it and handing it off.

Humans and computers are good at such different things that it’s kind of no wonder programming makes us feel stupid all the time. The human brain can only keep track of so many tiny details at once, so we constantly trip over things like semi-colons and getting conditions the right way around. I swear 90% of best practices in development are just ways to compensate for how bad our brains are at programming. Small methods? Fewer paths through the code for our squishy animal brains to keep track of. Functional programming? Fewer side effects for our squishy animal brains to keep track of. Simple interfaces? Fewer details for our squishy animal brains to keep track of!

But seriously, it sucks to pin everything on how smart you are and feel stupid all the goddamn time. I don’t have a magic wand to fix that, but I can tell you that if programming sometimes makes you feel like you made a terrible mistake and should pack it in and go raise goats or something, you’re not alone. Sometimes it feels like our industry was designed to make us nuts.

Talk of the day: seriously excellent career advice

Read the slides and speaker notes for Tanya Reilly’s excellent talk Being Glue right now! Seriously, this talk is so great.

If you do glue work (that is, extremely important technical work that keeps teams and projects on track, like reviewing designs and seeing what’s missing, noticing that another team is working on something similar to your team and coordinating the two teams so they don’t duplicate each other’s work, but isn’t code) and you want to get promoted, you need to read these slides.

If you don’t do glue work, you should still read these slides and then either start doing some glue work or at the very least advocate for the people who do and insist that their contributions to the project/team/company’s success be recognized.

And if you’re a manager, you should definitely read these slides and think about whether you are doing a good job of giving your team incentives to do essential work like this or whether you’re punishing people for doing essential work by refusing to promote them.

Read the slides, go check out Tanya’s twitter @whereistanya, and check out her blog noidea.dog Side note: isn’t that a great url?

Link of the day

We all know we have personal biases, but have you ever thought about your software design biases? I certainly didn’t until I read this article about Software Design Bias by Sandro Mancuso. If you’re having trouble with the design of a piece of software, it’s worth taking a look at Sandro’s handy list of biases and thinking about whether the way you prefer to design software is actually the best one for the particular thing you’re trying to build.

Link of the day

Persistence is enormously valuable, I even believe it’s more important than intelligence if you want to a programmer, but knowing when to quit is valuable too. That’s why I like I successfully chased my Big Life Dream, and I hated it by Rowen, so much.

Their dream was to travel the world in a sailboat, yours might be to become a freelancer, to start your own business, to switch to game development, or something else entirely. If you try something and it turns out to make you miserable, it’s okay to stop and do something you actually like. I’ve read a lot of sad stories about people who made themselves miserable, put themselves under so much stress it wrecked their health, or financially ruined themselves pursuing a dream that just wasn’t working, and I really don’t want that for any of my readers.

On a lighter note, if you do New Year’s Resolutions, consider quitting something you don’t actually like instead of trying to squeeze more and more activities into your life. If that feels selfish to you, think of it as setting a good example for others :)

Link of the day

Learning Fluency, by Sara Simon is a really interesting article and you should definitely read it. It’s kind of hard to summarize, what I got from it was that there are a lot of parallels between learning natural languages and learning to program, one of which is that rote memorization is both really useful and really underrated. Variables and loops are really boring for experienced programmers (which I’m suspicious is why most programming tutorials zip past them pretty quickly), but just like it’s really hard to tell someone how to get to the grocery store in a new language until you’ve memorized enough words, it’s really hard to build a program before you’ve memorized enough programming constructs.

Another good point Sara makes is that not everyone learns the same way. Some people are happy to jump into a project and learn as they go, and other people need more structure to get started. That doesn’t make anyone wrong, but it does mean we need resources for more than just one kind of learner.

Learning Fluency is a bit of a long read but it won’t take your whole lunch break either.