Random thoughts and writings.

It's All Just Software

I had a meeting with a customer (let's call her Kate) last week, and she wanted some changes to a web-based messaging application that my group owns and manages. That meeting didn't exactly go as planned.

Blame Tennis

Here's how the conversation between myself and Kate went:

Matthew: OK, so the request you submitted said you wanted the icon on the task bar to flash orange whenever a message comes in from the messaging application, right?

Kate: Right.

Matthew: Unfortunately, that kind of thing is basically impossible in a web app.

Kate: What? Why?

Matthew: Well, it's a completely different environment. The old app was a Windows application, where this kind of thing is trivial to do. But now, the app is a Web app, so it's a totally different environment.

Kate: I don't understand.

Matthew (exasperated): ...See, the web app only exists in the browser, and the browser exists in Windows. But the code can only call it's container. So the web app can call the browser, and the browser can call Windows. But the web app cannot call Windows.

Kate: You just said it could. The app can call the browser, and the browser can call Windows. So the app can call Windows and make the icon flash orange.

Matthew (confused): No. That's not how it works, because if it did work that way it would be a massive security risk. Imagine a malicious website being able to screw with Windows without you downloading something. That would be incredibly bad.

Kate (desperate): But the old app did that!

Matthew (resolute): Right, I know, but that was a Windows app, not a Web app. Making the taskbar icon flash in a web app is basically impossible.

Kate (angrily): It can't be impossible! They did it before.

And around and around we went. She wants something, I say we can't do that the way she wants, she says "but you did it before," ad infinitum. It's an endless game of blame tennis, where she serves with "we did it before!" and I return with "we can't do that now!" over and over until one of us collapses from exhaustion. It's maddening.

Throughout the game, it struck me as odd that she held steadfast to the idea of "well you did it before, why can't you do it again?" Because, to me, the very idea of a web app making Windows do something is preposterous, laughable. It's so far removed from "normal" web development as to be obvious to even the most junior web programmer.

But that wasn't at all obvious to Kate, and I should have known that would happen.

Basically Magicians

Developers, programmers, tech people in general (yes, including me) often forget that to all the people who don't work in the tech world, we are basically magicians. We take abstract ideas and turn them into concrete applications by using indecipherable texts and acronyms known only as "MVC" and "IDE" and "HTML". We are wizards using tools and laws that seemingly break the rules of physics and are seldom understood by persons who are not part of our "exclusive" club.

With that kind of power comes the responsibility to explain ourselves, clearly and thoughtfully, without resorting to name-calling or annoyance. Because, despite our myriad skills, varied experiences, and entirely different tech stacks which we work on daily, to the vast majority of people it's all just software. It's all the same.

This is the key thing that I failed to remember in my conversation with Kate. To her, to anyone who doesn't deal with these things on a regular basis, it's all just software. It's all 0s and 1s and true and false and math and colors and little buttons that won't do anything and links that don't open new windows unless you count to 6 and summon Beelzebub. It's all just crap that gets in the way of doing their job. If they didn't have to deal with it, they wouldn't.

Check Yourself

Kate and I eventually reached a point where we could solve some of her other issues with this system, and she felt pretty good about those agreements. We never got a resolution on the taskbar icon flash thing, and we never will. But eventually we got to a consensus where she understood why this was impossible, and can now go to her boss and try to find alternate solutions (like providing her teams with two monitors each instead of one). We got to a resolution, it just took a while.

We could have gotten there faster if I'd left my attitude at the door.

It is not the customer's job to know the ins and outs of our daily lives. It is our job to explain it to them, so they will know that we are not magicians but craftsmen, plying a trade and solving their problems with code. It is their job to explain to us what they want us to do, so that together we can work up a viable plan for getting their needs met. Both sides must do their part in order for anything to get done.

Nobody wants to play blame tennis; everybody just wants to find a solution. Leave your racket and your attitude at the door, and we can work it out together.

After all, it's all just software.

Happy Coding!

Why Aren't You Blogging Yet? Tips for Getting Started

I've been writing this blog for about a year and a half now, and I firmly believe that every software professional should write a blog. It's an invaluable tool for connecting with other professionals, for getting your ideas out there, for making bad jokes making good jokes.

I've told this to several other programmers, and I'm always met with the same responses. Wow, you're such a good writer! I can't possibly write as well as you do! Once I've told my ego to calm down and eat a bagel, I start hearing all kinds of excuses: I don't have time, I don't know any good topics, nobody cares about what I have to say. Which is bull, but there you have it.

Writing a blog is not some ancient magic that I studied for years to master! It's a process, one which is becoming a part of me just as much as working or eating is. You can do it too!

Still don't believe me? OK then, let me first dispel some common myths about blogging. All of these are things I have heard from others about why they can't or won't write a blog.

Myths About Blogging

Nobody cares about what I have to say. You're telling me that in a world of 7 billion people, where almost everybody can have someone that looks like them, that no one will ever care about your ideas? I don't believe this for an instant. Someone, somewhere, will have the same problem you have, the same ideas you thought of, and will want to know that someone else out there is thinking the same thing.

I don't have time. Neither do I. I have a family, a career, a house to maintain. But I make time. Writing this blog is now just something I do, rather than something I have to do. My blog is my outlet, my window into new tech and new stories, and my way to communicate with other members of my profession. You can always watch less TV, or play less video games, or find other ways to make time.

I can't write. It's not a requirement to be a writer in order to be a blogger. Half the bloggers out there couldn't write their way out of a contrived plot coincidence wet paper bag! That doesn't stop them, it doesn't stop me, and it shouldn't stop you. Besides, how do you expect to get better if you don't practice? Nobody's asking you to write the next great novel.

I'm scared of what my coworkers/friends/peers will think. Ignore them! If they're gonna change their mind about you because you put yourself out there, do you want to care about their opinion? Nobody gets to influence you more than you.

I don't have any good topics to blog about. Everything you know, someone else doesn't know. Don't assume that because you know something, everyone else does too.

Everything I want to write about has already been written. This doesn't matter at all. Half the topics I blog about have already been blogged about by other people. The trick is to find a way to make it interesting for your readers, make it unique in some way that doesn't In my case, I use humor (to varying effect), simple sentences, and general topics to reach as many people as I can.

Why Should I Blog Anyway?

Glad you asked!

It helps your communication skills. Sitting down and thinking about a problem for long enough allows you to concisely and accurately describe that problem to others. Communication is one of the most (if not the most) important soft skill for developers, and writing blog posts will make you a better communicator.

It gets your name out there. Especially if you have a super common name like I do. Writing a blog gets your ideas out into the world for your friends, coworkers, even prospective employers to see.

It teaches humility. There's been quite a few times where I've screwed something up and some kind soul out there on the interwebs has pointed it out (always with respect, of course).

It teaches you to be thorough. If you're taking the time to write something, you'd better be pretty darn sure it's accurate; or else you'll have a hoard of annoyed internet dwellers ready to explain, in excruciating detail, why and how and where you are wrong. Repeatedly.

Hopefully by now I've got you convinced to try blogging out (or, at least not actively hostile to the idea). Here's a couple of tips for getting started with your very own blog.

Tips For Getting Started

Get your own domain name. Your own, custom domain name makes it much easier for people to find and refer back to your blog, plus it looks professional. I personally think the top-level domain (TLD, e.g. .net, .com, .whatever) doesn't matter at all, but I'd still get something people recognize.

Start small. Pick a small topic, write a clear, concise post about it, and post it.

Don't write novels. I've seen other bloggers recommend writing everything about a topic on one page, but for me (probably because I'm a distracted individual) seeing a huge wall of text on a page is cause for me to run screaming in terror (aka hitting the back button). If the topic is large, break it up into multiple posts.

Post often. I personally write at least one post per week. They don't have to be big, involved works; hell they don't even have to be good, just write something. The post you've published is better than the post you've written.

Use whitespace. Huge multi-sentence paragraphs are a big turn off to many readers; they look impenetrable, dense, scary. Use whitespace by making lots of small paragraphs, and cut out any words or sentences that don't clearly and concisely support the point you are making.

Allow comments. It boggles my mind that bloggers can write some huge, insightful post and not allow other people to leave comments on it. Comments are where much of the value in writing a blog lies! After all, the whole of humanity is generally going to be smarter than you.

Manage the comments. Of course, allowing comments means some extra work on your part. You have to make sure you don't allow spam, or ads, or abusive posters. But in my opinion the extra work involved in maintaining a comments section is heavily outweighed by the value it provides.

Make it something you just do. If you want your blog to be successful, make it something you do, rather than something you have to do. This is the truly difficult part of writing a blog, but that kind of commitment tends to shine through your writing, making it obvious that blogging is something you enjoy rather than tolerate.

Don't expect to make money, because you probably won't. Blogging is not something people do to make a living. Sure, some super-famous bloggers can do this, but for the vast majority of us we're lucky if we make enough money to pay our hosting costs. Don't blog if all you're after is money, because you'll be sorely disappointed.

I love writing. It's why I write stories, why I write tutorials, why I write at all. But you don't have to love to write to be a good blogger, and you certainly don't need to be a good writer to be an effective blogger (proof). To me, the benefits of blogging significantly outweigh the downsides, and the skills writing teaches (communication, humility, confidence) are useful in almost every facet of our lives, not just our professional one.

So go get started! Nothing's stopping you except you!

Happy Coding Writing!

Programming Is Awesome, But Programmers Suck

I was re-reading the fantastic piece by Peter Welch called Programming Sucks, which is a classic despite it being only two years old. In the piece, Mr. Welch repeatedly demonstrates why programming (and the atmosphere surrounding it), well, sucks, which results in simultaneously hilarious and sobering paragraphs such as this one:

"You discover that one day [while debugging a program], some idiot decided that since another idiot decided that 1/0 should equal infinity, they could just use that as a shorthand for "Infinity" when simplifying their code. Then a non-idiot rightly decided that this was idiotic, which is what the original idiot should have decided, but since he didn't, the non-idiot decided to be a dick and make this a failing error in his new compiler. Then he decided he wasn't going to tell anyone that this was an error, because he's a dick, and now all your snowflakes are urine and you can't even find the cat."

You'll have to read the whole piece to have that last sentence make sense. Go on, I'll wait.

That post got me thinking: why exactly does programming suck? Most of the piece details that the work itself actually doesn't suck; rather, the people involved in it do. It got me thinking: exactly why can programming be so frustrating, so annoying, so terrible? And I've come up with a theory.

In short: programming doesn't suck, programmers suck. Yes, including me. Here's why:

We think "I can do better than that." Every damn time. It doesn't matter if we've spent five seconds perusing a new codebase or a couple minutes watching a senior developer explain what his application does, we can always do better than that idiot. Until we actually try to do it better, and after a few hours of "this can't be that hard" and "why won't you work, stupid code" and "I know I'm better than this" we're more likely to silently give up than concede that we got Dunning-Krugered once again. Why admit defeat when you can just delete?

But while we will do better than that, nobody else can. Everyone else's applications are steaming piles of dog crap next to our own beautifully-crafted, complete, artful pieces of shit code. And we don't even have enough sense to realize that what we've written is crap, as it always has been and always will be; since it's our crap we assume that it must be good. After all, we're good at programming, therefore what we write must be good. I mean, obviously.

A programmer, sitting on a couch with a computer on his lap, captioned

In our own little insular world, we are gods, and we get treated as such. Have you ever fixed a family member's computer after they did something to it? You'd think they just saw water turned into wine. What was a few minutes of googling and an hour of random button-pressing while trying to get a different error becomes a work of utter genius in the eyes of the non-techie. To them, we are not so much technicians as magicians, and we can't even deny it because "oh, you're just being modest." To the non-programmer, we are miracle-workers. And, if we're being really honest with ourselves, we love it. We crave that praise, that acknowledgement; it's something we don't often get in the real world because code, on the whole, is supposed to be invisible. It's a truly addictive feeling, that of doing something no one else can do.

We believe that management hates us because we "tell it like it is" (which invariably means "how we want it to be"), but in reality they hate us because we don't bother explaining ourselves clearly. We say "there's a problem" and then launch into some long and indecipherable technobabble rant about why the proposed solution won't work, when in reality we're just stalling, saying it won't work because we don't have the time or energy to research and understand the proposed solution.

Worse, if we do bother to attempt to explain why it won't work, we'll probably only do that once, because when we invariably fail to make them understand how smart we are and how dumb they must be, we just won't bother explaining anything to them because it's a waste of time. They didn't understand before, so they won't understand now. It's an endless loop, one we perpetuate because it makes us feel smart, feel needed, when in reality it just pisses off our managers.

In short, we are whiny, selfish, dense little buggers who just want to feel smart.

Programming, to be clear, is awesome. We programmers are fortunate. We get to solve problems using code that only a few people understand, that are difficult to conceptualize, that, if we're lucky, can actually make a difference in someone's day-to-day life. The feeling of doing good work is up there with good sex and good food: it feels amazing. Even better, we get paid to do this, and in many cases paid quite well compared to other professions. Yet we can't seem to remember any of that because we're too busy puffing our chests and destroying code.

Programming doesn't suck, programmers suck. All of us, including me. This is one of the reasons I believe that a core part of being a programmer is being a good communicator. Maybe the time we spend perfecting our code would be better spent explaining it, understanding others' code, or just chilling out. We're not gods, we can't always do better, and most of all we are people just like everyone else. Spend your time learning how to communicate, analyze, and teach; what you'll find is that these are all more important skills than knowing how to code.

Code Is Never "Perfect", Code Is Only Ever "Good Enough"

I am a perfectionist. I know this, I accept it, and it still bites me in the ass. I want my code to be The Perfect Code, unbreakable, like a flawless diamond in a sea of cubic zirconium. I spend entirely too much time trying to cut that diamond from the rock it's buried in. But is The Perfect Code even attainable, or should we just settle for "good enough?" That's the question I've been wrestling with this week.

The Return of Dick and Bob

I've mentioned before that I often imagine having two awful sports announcers in my mind whose only goal in life is to subtly trash whatever I think or do or say. They're pretty much my impostor syndrome given a voice, and lately they've decided to make an unwelcome resurgence into my daily life.

Dick: Well now, what do we have here, Bob? Looks like Matthew's writing that same function all over again! He must be trying for the Perfect Code!

Bob: Sure does, Dick. This is his most recent attempt at it; the wily veteran giving one last go at the big win he's desired for so long.

Dick: We've seen this kind of thing before from him, especially during that last match against the file uploader. You can tell he's trying to make The Perfect Code by the never ending stream of invective he lets fly. Let's listen in:

Matthew: Piece of [bleep]! I know you [bleeping] work! WHY WON'T YOU [BLEEPING] WORK, MOTHER[BLEEPER]?!

Bob: Wow. He really wants this one, doesn't he?

Dick: He certainly does, Bob. He's reaching for perfection, and here, on his third attempt, he seems to be no closer than he was during the first two! Why is that?

Bob: Well, Dick, seems to me that he just can't write perfect code. It's a good effort, to be sure, but it looks like he just doesn't have it in him today.

Dick: After the break, we'll find out if this angry little programmer can achieve the greatest feat in software development: the Perfect Code! Hey, you never know. Stay tuned!

I want The Perfect CodeTM. There, I said it. The Perfect Code doesn't break, needs little maintenance, and is so easy to read you might mistake it for a novel. I am constantly in search of this mythical creature, and evermore disappointed when I can't summon it despite my best efforts. Sometimes I get so close I can almost make it out through the fog of controllers and repositories, only for it to slink further back into the overgrown jungle of code that I'm currently attempting to tame.

The trophy yet eludes me, and I fear it shall do so forever. I've been working this hard to make The Perfect Code, and yet I always fall short of my goal. Am I doomed to write imperfect, buggy code every working day for the rest of my career?

Short answer? Yep.

Myths and Legends

The Perfect Code is a myth; a unattainable legend which we devs nevertheless strive to achieve. The Perfect Code exists only in one's mind, a product of their own tendencies and biases, incompatible with any other developer's vision of it. You cannot hope to obtain it, you can only hope to approach it, and even that's a mighty difficult feat.

Code cannot be "perfect." What is perfect to you is a steaming pile of crap to your neighbor. Once you have more than one person looking at any given piece of code, it can never again be considered "perfect" (and woe be unto the person who only ever has one person reviewing his code). There is no "Perfect Code" because no two programmers can agree on what that means. But they very often can agree on what might be "good enough."

There is no such thing as "perfect," there is only "good enough." But that leads to a more difficult question: when is our code good enough?

Aiming For "Good Enough"

If perfection is unattainable, at what point do we think our work is "good enough?" Is it when our code is readable, when our fellow developers can easily understand what it is doing? Is it when the code does what it is expected to do? Is it when it passes the tests we've defined? Is it when it fulfills what the customer wanted? There's no clear definition for "good enough."

Funny thing about code being "good enough" is that, if you're like me, you often can't see it for yourself. You're too busy being absorbed into its world that you can't see the forest for the trees and miss the point at which the code becomes "good enough." To truly understand when your app has reached that point, you need an outside opinion. You need a coworker.

IMO striving for perfection is failing before you even start. I'm not omniscient, I'm not superhuman, I cannot possibly plan for all possibilities. Hell, I can't even plan my breakfast; I just take things out of the pantry until some combination of them sounds good enough to eat. I might end up with bacon, apples, and peanut butter sometimes, but its food and I can eat it, so it's "good enough."

And that's the goal, isn't it? Just make it good enough, whatever that means to you.

Every day, I will write buggy, imperfect code. Every day, I will make mistakes. Every day, I will be less than perfect. And every day, I attempt to be OK with that, even if Dick and Bob are not.