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!

Learn or Die: Warding Off My Coding Career's Eventual Obsolescence

I often give technical demos at my work about various topics, and the most recent one was an introduction to ASP.NET Core 1.0 that spawned a lot of blog posts. Overall, this class was well-received (at least I believe so, given that people keep showing up) so hopefully I'll get to continue doing these kinds of presentations.

At the end of these sessions, I generally "open the floor" for comments, questions, concerns, extended discussion and the like. During one of these recent classes, a coworker of mine asked about MVC 6's View Components, which are similar to Partial Views except they include functionality with them by being bound to a server-side class. Honestly they look pretty darn awesome, and I'll need to be writing a post about them.

Anyway, this attendee (we'll call him Liam) pointed out something that was frustrating him:

Liam: I just wanted to ask about those View Component things you just showed us.

Matthew: Sure, man.

Liam: They look a lot like User Controls from WebForms, don't they?

Matthew: What, the .ascx file things? I suppose so, but these are more in line with how MVC, and by extension the Web in general, operate.

Liam: It just seems to me that we keep going in circles. I feel like we did this 15 years ago, and now it's being presented back to us as "oh, here's this new thing we came up with, hope you enjoy it" but we already had it. It's not new.

Matthew: I suppose it can feel that way sometimes. Like we're not really doing anything new, just improvements on existing ideas.

Liam: Exactly! I feel like I have to constantly keep learning new ways to accomplish the same things, solve the same problems. After a while, it's kinda like, "what's the point?" I already know how to do this, why should I have to learn it again?

Five years by Michael Ruiz, used under license

I know the feeling. I have this saying that I trot out every so often, though I forget who said it first: "Half of everything you know will be obsolete in five years or sooner." It's a good reminder to me to stay sharp, keep working at it, don't get caught up in thinking I know everything, don't care whether you suck or not. But it's not easy, having an expiration date for your skills.

"Can't I Just Do What I Know?"

Liam was annoyed that things keep changing, and he has to keep up. This is understandable, considering that technology changes at lightning speed and we're still reacting to it at a human pace. Yeah, it's frustrating (and, given enough time, demoralizing) to have everything you know and understand change every X years. Why can't things just stay the way they are so I will continue to understand them? That would be easier for me.

To make matters worse, in Liam's mind, the new technology that I was demoing (ASP.NET MVC 6 View Components) was something that we already had in the form of User Controls for WebForms. Now, my opinion on the matter of WebForms is that they suck, but I can kind of see where Liam is coming from. Dammit, I already know how to do this, why I can't I just do what I know?

The short answer to that being, "go ahead."

Seriously. If that's what you want, and your customer understands and is OK with the benefits and drawbacks of your preferred technology, then go ahead and do what you know. Strictly speaking, we don't need to be constantly learning new things to continue solving problems. In fact, most of the problems we'll be faced with on a day-to-day basis are issues that someone else has probably already encountered and fixed. Only the technology being used to solve them changes. There are no new problems under the sun.

Inevitable Obsolescence

But, and this is a big but here, there will come a time where what we know, what we can do, is simply... outdated. It's going to happen to you, to me, to everyone. At that point, we'll have less competition for our skills (since most of our coworkers will have moved on), but also less potential customers for our work (unless you're a COBOL programmer, since apparently we'll need those people forever). There will come a point where what we know and what we can build doesn't cut it anymore. It will happen.

When it does, when your acquired skills and knowledge become obsolete, what will you do?

Two obsolete televisions, sitting in a trash pile.

Will you double down on your knowledge, becoming a big fish in the shrinking pond of a dying tech stack? Or will you try to bring your skills up to date? Every piece of software ever written has an expiration date, and by extension, the skills necessary to create that exact piece of software again will also expire. When your skills expire, how will you react?

If we do nothing, if we learn nothing, there will come a day when our skills, our intimate knowledge of any given tech stack or pattern or language, will no longer be useful to us or anyone else. Will we cling to that knowledge, trying to restore the safe harbor it once held for us? Or will we set sail into the infinite abyss of the unknown, attempting to catch something, anything that will allow us to keep on keeping on for another five years?

C'mon. You already know what the answer is.

Go DO Stuff!

Go learn. Read books, read blog posts, try things. Teach others. Give a talk at a conference, or even just present something small to your coworkers. Go be an investigator. And while you are learning, fail at something. Might as well get used to that, as every single person you know will fail at one time or another.

Go do something. Even if it's just writing "Hello World!" in a new language. Anything we learn can help us stave off our career's eventual obsolescence. Future you will thank you for the effort you put in now.

What about you, readers? How do you prevent your career's obsolescence? Do you read, teach, write? Which of these has worked the best for you? Do you need some assistance getting started with learning a new stack, or pattern, or language? Share in the comments!

Happy Learning!

You Are Not Your Code

What gives code value? Does your code need to have meaning, a purpose, for you to have the necessary involvement to give your best effort? To what extent should we care about the usage for the code that we write? A lunch conversation with three of my coworkers prompted these sorts of questions.

Value, Purpose, and Programming

Let's call them Zach, Flora, and Jamie. They're my regular lunch group, inasmuch as whenever I'm eating lunch at the same time that they are we all sit at the same table. As happens in the real world, I don't remember exactly how we got on the topic of code "value", but the conversation went something like this:

Zach: I just feel like I need the code to be used in order for me to be able to do my best work on it. If I spend all this time writing a good, well-thought-out application, only for it to never actually get deployed, then what was the point of doing a good job?

Matt: I get that. I just don't feel quite the same way. I have to have a reason to build something, but just because it ultimately got tossed out doesn't mean I'm not gonna do good work on it. It might get used, it might not; that's not really for me to decide.

Jamie: If someone told me, "We need you to build these 7 sites over the next year, and when you're done, we're going to trash them all," I'd still do it.

Matt: But why? What would be the point?

Jamie: I feel like I'm not in a position to question why I'm supposed to be doing things. I'm just a software developer, not a senior or lead or anything, so who am I to question why something needs to be done? I just do it.

Flora: But isn't there a chance that the issue you found hasn't been considered before? It may not be likely, but it's possible, isn't it?

Jamie: ...I suppose it's possible, but it's just code. Why do I need to question all my tasks like that?

Matt: See, that's my issue: I can't help but question "why?".

I suppose that really is my issue, to the probable annoyance of my supervisors. I need to know what the code we're building will be used for, why it exists, in order for me to feel like I can do a good job working on it. I need to know that the applications that I'm writing will have value.

As shown above, Jamie disagrees. He stressed (later in the same conversation) that he still does his best regarding code structure and quality, but to him, the extrinsic value of the code is irrelevant; it's not for him to think about, as if it has reached his desk, clearly someone else (presumably someone who will actually use the program in question) has already determined that the code is relevant, useful. Why undermine their decisions?

We Are Not Our Code

I am of two minds on this. On the one hand, I certainly don't enjoy my code being casually tossed aside like garbage (unless it actually was garbage, in which case I'll throw it out myself), but on the other hand, the code that I write cannot be assumed to have value for the users. I'm obviously going to try to make it valuable, but ultimately it is the users who decide if what I wrote will have a use and a purpose.

I suppose that's the root of the problem, then. We are not the arbiters of value. We can't determine if our work is valuable, that must be done by outsiders, but without that value, why should we do a good job? If we don't do a good job, then are our applications valuable? Worse, what happens when (not if) some users decide that our work is not valuable, that it doesn't do what they want, and they throw it out? Should we be offended, hurt?

Of course not. I am not my code. The code I wrote is a reflection of me as I was at that moment, not as I am now. It is static, whilst I will (hopefully) forever be changing, improving, learning. Every second that ticks past is a second where I'm expanding my skills, consuming knowledge and applying it judiciously. I'll be better tomorrow than I am today.

What's amazing about making this mental separation is that if the code is not part of you anymore, you become much more willing to change it. Criticism suddenly seems useful rather than an ad-hoc attack on your abilities. It's no longer you who is stupid or wrong, it's the code, and you can just change it without taking an emotional beating. The code transforms into its own separate entity, wholly apart from you, and can be modified, re-configured, or thrown away without dragging you along.

Three people doing pair-programming, reviewing each other's code Pair programming by Damien Pollet, used under license.

The best advice I have is this: separate your sense of self-worth from the code that you write. Doing so leaves you more open to criticism, to learning, to improving your skills. Once the code is separate from you, who cares if it sucks? Code doesn't have feelings. You can make your code better.

In short, you are not your code. Don't forget that you can (and should!) separate what you do from who you are.

Are you like Jamie, or me, or someone else? Have you had any difficulty separating what you do from who you are, and how did you handle those situations? Share in the comments!

I Don't Care If I Suck, As Long As I'm Learning

I am an enormously self-critical person. If I'm going out to a party, or having dinner, or even just giving a presentation, I'm constantly playing back my speech and my actions in my head to see where I went wrong. It sounds like two awful television sports announcers who follow me around only to trash whatever I think or do or say.

DICK: And here comes Matthew, shuffling into the presentation arena, sporting a wrinkled button-down and black slacks with ugly shoes. He clearly wants to make an impression, Bob.

BOB: Right you are, Dick, though I'm not sure what kind of impression that will be.

DICK: The meeting has now started, and look at this! Matt is waving his arms around, trying to provide emphasis to his explanations! Has he lost control of his limbs?!.

BOB: He'd better rein in his enthusiasm here or he'll be mistaken for someone who is suffering a seizure.

DICK: Let's listen in.

MATTHEW: ...So here's why we might want to consider using SOLID principles in our everyday coding...

DICK: Did you hear that, Bob? All of those conditional words! "Might want to consider," wow! Could he be any less decisive?

BOB: I don't know, Dick, but obviously he doesn't know either.

I'm really hard on myself. I know this, and I accept it. I'm not sure if this is because I expect better or worse of me, but I do know that it leads to some really interesting conversations, during at least one of which I actually yelled at my own brain and startled the hell out of my dog.

Still, this state of mind is useful to me in my professional life. In an industry that expects us to keep with ever-changing technologies, being self-critical is important to our careers. After all, how can you know you need to improve on something without first being able to recognize that you're not good at it? In that vein, recognizing your shortcomings is a boon, a helpful reminder that you might need to work on some things.

After a while though, constantly reminding yourself that you suck gets rather disheartening.

I suck at jQuery, I should practice more, you think. But the next day it's I suck at mongoDB, I should practice more, then I suck at Technology X, I should practice more and eventually you're surrounded by demands from all sides to practice more, write more, DO MORE. It's never enough, and it'll never be enough, but you're not aware of that fact because you're too busy trying to keep up.

It didn't help that I was seemingly surrounded by more competent people than me, even though that was only my insecurity talking.

I'd see "rock star" programmers pass through my organization and think Wow, if I could have a tenth of his knowledge, I'd kick ass at Javascript. That other programmer might have been terrible at SQL, but he was a God of Javascript, and so I'd aspire to be like him. Anybody who was clearly better than I was at a particular aspect of development caused me immense envy. I was comparing the grand total of my technical knowledge with the best parts of theirs, and coming up short.

Hit your head against enough walls and eventually you realize that you have a headache. I'd gotten sick and tired of caring about what other people knew or didn't know, and so I found myself actively trying to stop being concerned about it. I had to reorient my mind, to focus on how I can improve my technical knowledge without comparing it to others. I had to stop making comparisons altogether.

The unexpected outcome of this was that, because I wasn't making comparisons anymore, I no longer cared whether I sucked at a particular technology. It just didn't matter.

The day all of this clicked into place, the day that I realized I didn't need to compare myself to anyone, was a glorious day. I was free, more free than I'd been in a long while, free to improve my development skills without the shackles of other people's perceived stardom binding me. I was free to learn what I wanted, when I wanted.

A sunrise over the ocean Sun rise at CuaLo by Handyhuy, used under license

With that freedom came a price, though; how could I know I was getting better if I couldn't compare my skills against anybody else's?

That's the paradox; if you no longer care whether or not you suck, how can you be assured that you are improving? I have a simple question that can give you the answer: are you learning? If the answer is yes, you're getting better. Otherwise, you may want to reconsider your position.

It took a while, but I finally discovered that the best way to offset my highly self-critical brain is to stop caring whether or not you suck, because it doesn't matter as long as you are learning.

Now if I could only get Dick and Bob to just shut up for a while. Does anybody see the remote? I'd like to change the channel.