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.
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.
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.
I’ve been talking about code smells for a while, but code is far from the only thing that can go wrong. What about process smells? There are things in your development process that may not necessarily be wrong in every situation, but are a signal that something could be wrong. Some of these are more definitely stinky than code smells, but not all of them. As always, if you’re happy and productive with the way your process works, stick with it!
Here’s an example of a process smell: Friday prouction deploys (in case that tweet ever gets deleted or something, it’s a picture of a jack o’lantern with the words “Friday deploy to prod” carved into it and the caption “Scariest Pumpkin”). Friday deploys are almost universally a terrible idea, which makes them an especially nasty process smell, but once in a while they are actually a reasonable choice. Usually when they’re the least terrible of a set of bad options, but sometimes bad options are all you have.
If you’re fixing a severe bug that prevents a lot people from using the system at all, then it makes sense to deploy whenever you have a fix, even if that’s a Friday, even if it’s late in the day on a Friday. And if you have the unusual luck to have a dev team with staggered schedules who are all familiar with the code being deployed, then no day is really any riskier than any other (is this actually a thing? I included it because it’s technically possible but I’m not sure it actually happens anywhere).
If you work in a very rigid environment where nobody uses the system over the weekend at all ever, then knock yourself out! If no one touches the system over the weekend, then you’re not going to hurt anything by deploying on a Friday.
Most of the time Friday deploys are just a bad idea. Why?
Because no matter how great your QA department is, even they can’t test every single possible combination of weird commands and bad data and dodgy wifi that your actual users or customers can, which means things may break in wildly bizarre ways when no one is around to fix them. That sucks for your customers and sucks for your support team and sucks for your revenue and sucks for your reputation and sucks for your stress levels when you come back and discover that everything has been on fire all weekend. Oh and it sucks if you get called in to fix it when you thought you were going to have a nice relaxing weekend. Spare yourself and the rest of your team a lot of hassle and don’t deploy on a Friday (or late afternoon any day) if you can avoid it.
This process smell is really interesting if you keep in mind this definition of a code smell, by Martin Fowler:
A code smell is a surface indication that usually corresponds to a deeper problem in the system.
If you’re deploying to production on Fridays, there’s definitely a deeper problem. Who is even letting you do Friday deploys when they’re so widely acknowledged to be a bad idea? Or who is pressuring you to do them when you know they’re a bad idea? And why is that person getting away with it? Who is pressuring them? Why is it more important to say something went out than to be sure that somebody is around to fix it if anything breaks? Or, and this is really scary, is management assuming that developers can be called in any time night or day to fix things?
Unfortunately, there isn’t a neat set of fixes for process smells the way there is for code smells. If I could give you a few quick and easy steps to convincing your company that deploying to production on a Friday is a bad idea, I’d be a millionaire :) What I can tell you is that you need to understand why your team lead / manager / upper management thinks it’s a good idea to deploy anything on a Friday before you can convince them to change. If the problem is that upper management believes it’s lazy to wait until Monday when the deploy could be done on Friday, then explaining that deploying on Fridays hurts team morale by making people worry their weekend plans will be wrecked by a surprise issue isn’t going to convince them anything needs to change. On the other hand, if you remind them how angry your customers were the last time production went down on a weekend and stayed down for hours because that particular release wasn’t possible to quickly roll back and the developer who knew the most about that change was away on a long-awaited hiking trip, and tell them there’s a way to prevent that from happening again that costs zero dollars, you’ve got a much stronger case.