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 – link to that thing about how top performers are the ones who can get their questions answered the fastest from o’reilly, uh somewhere – 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.
