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.
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.
I like this link because even though I rely on computers to remember things for me a lot, I never thought of adding a test with an expiry date to force me to remember to remove code, or at least check if it’s still needed.
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.
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.
The more I work with deep inheritance hierarchies, the more I wonder if inheritance is actually a good idea. If you’re looking to avoid the trouble overusing inheritance can get you into, this article has some handy tips: Inheritance is evil. Stop using it.
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.
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 :)
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.
Unrelated image from pexels.com to make this post look nicer in social media shares and because I just like lilacs.
You might have guessed from my extremely wordy blogposts that I like writing as well as programming :) Aside from having a personal interest in writing, I think there are some really useful parallels between writing and programming.
Let’s talk about one of them: separating writing and editing. This is a pretty common piece of writing advice, I’ve seen it all over the internet.
More specifically, what separating writing and editing means is that when you start a piece of writing, you don’t edit, you just get your ideas out onto the page. Only after you have a complete first draft, whether that’s a blog post or a novel, do you edit it. Editing can be as simple as fixing typos or as in-depth as moving whole chapters around.
Why is editing while you write such a bad idea? We’ve all written essays for school and edited while we wrote and we survived, right? Well, we did, but we also put in way more effort than we had to. It is totally possible to edit while you write and turn out a perfectly good school assignment, or even a professional article or book, it’s just way more work than it has to be to do it that way. It takes for-freaking-ever too and we’ve all got other things to do :)
Separating writing and editing makes you way faster. Yes it works better if you have a little space between the writing (drafting/outlining) and editing steps, but you’ll spend less time altogether on a piece of writing if you put a day or two between those steps.
But why is that? Writing isn’t that hard, and editing isn’t that hard (to be fair, I’m saying that as someone who has always had an easy time with writing), so what’s the problem?
Part of it is that people just suck at multitasking. Fiddling with your words is a very different task from getting them down in the first place, but I think is the real issue is that editing and writing at the same time is mixing two steps that need to be done one after the other.
It doesn’t actually make sense to worry about how you’re saying it before you’re done sorting out what you want to say in the first place. That’s just going to make a mess.
Okay great, how does this relate to programming?
Programming is in many ways a very similar process to writing. You need to know what you want to do before you can figure out how exactly to do it. Programming is certainly more rigid, with writing you can still make yourself understood with a misspelled grammatical trainwreck, but it’s not so very different either. You can start a piece of writing and know just what you want to say and then discover it just sucks and you have to scrap it and start over.
What you want to do with a program can be more tightly constrained by what’s feasible given the existing system/libraries available/limitations of the language you’re using, but in some ways that makes it easier because there’s no debate over whether your program works or not, you can just run it and find out.
When you’re writing code it’s very simple to separate writing from editing: write pseudocode first. Figure out what you want to accomplish (yes that’s a big enough problem for many books on its own, but that’s another blog post) first, then break it down into simple steps, then start implementing it after you know what you want to do. It may turn out that there’s a technical reason your original plan won’t work, but you can still iterate on that and make a new plan before trying to implement that one.
If you find yourself stuck on a problem, you might be trying to do too many things at once. Try separating what you want to accomplish from how you want to do it.
