In Praise of the Junior Developer

"She's a project," my boss said to me. "She's green, and even though she's been working here for several months, you should consider her like a brand new college graduate. She'll need a lot of oversight, a lot of hand-holding and you'll still be expected to finish your projects on time."

"Excellent," I said.

I'm not sure why my boss felt the need to warn me. Melissa is a new, green developer. I know that; I knew that from the moment the coding section of the interview began. She had trouble with the FizzBuzz test, stumbled over the differences between an abstract class and an interface, and generally showed that she needs some experience. This ain't my first interview; I know she's a newbie, that's she'll need some help (maybe a lot of help) to get started.

And it doesn't friggin matter. I'm happy to have her on my team.

We need junior programmers. And I don't mean my company specifically, I mean our industry as a whole. This profession runs on the backs of the juniors. They're the one who get the crap work, who check the nitty gritty details, who learn and advance and become seniors and leads and managers. They are the people who will eventually replace me. I'm not scared of them; I want to see them succeed. But to do that they're going to need teachers, mentors, someone to help answer their questions.

I've been saying for a long time that what this profession needs is more teachers of technology. The problem, I'm now beginning to realize, goes much deeper than that. The real issue is not a lack of people willing to teach others, it's a lack of compassion in doing so.

The odd thing about programming is that it's entirely mental (with all the different usages of that word applying). There's no real physical component. Sure, we type on a keyboard, but that's the result of the mental work in progress, not the end goal. And it's tiring. Programming is mentally exhausting work. If the brain is a muscle, then programmers work it to the metaphorical bone each and every day. Good programmers solve people's problems using code in an efficient, skillful manner.

When you think about it, that's also the issue with teaching: it's a mentally exhausting job. Now, instead of trying to work out problems, you're trying to work out how different people learn and then teach to their skills, which is infinitely more difficult that just solving static problems. People are dynamic, changing, varying from one to the next. If you're a good teacher, you can innately understand how people learn, and then construct situations in which they will acquire the skills they need in the most efficient manner.

Here's the rub: the skills that make you good at programming (solving problems) and the skills that make you a good teacher (solving people) are not, and never will be, fully compatible. You can be the greatest damn programmer in the world, and yet anybody you try to teach will be just as bewildered as before, if you don't have compassion for the learner.

Compassion bridges the gap between teacher and learner. The less skilled you are at teaching, the more compassion you need to have for your learner.

(I'm tempted to use the word patience here instead of compassion, but you can be patient and still not be compassionate. It's the difference between a boss needing work done and a teacher helping a student study; they might both wait a long time and be perfectly fine with that, but the boss will simply expect the work to be done, while the teacher will understand why it took such a long time and work to help the student improve that.)

Look, not everyone will be a good teacher. Not everyone will be a good programmer. But those of us who are in a position to help others learn should take advantage of that. At the very least, attempting to teach others will help your communication skills; by describing a problem, you increase your understanding of it, otherwise rubber duck debugging would not be a thing.

But everyone can be a compassionate teacher. I can, you can, even newbies like Melissa can. Skill doesn't matter, ability doesn't matter; compassion matters. Compassion is what makes a good programmer into a great teacher.

So, bring it on, Melissa. Bring it on, junior devs. We need you. And we'll be doing our level best to be compassionate, to be teachers, even if we're not very good at it. Despite all our misgivings, despite all the hate and impatience and intolerance you might run into out there in the wilds of the Internet, there are still those who want to see you succeed, and are willing to use our compassion to help you reach your goals. This industry runs on the backs of the junior developers, and we would be loathe to forget that.

Post image is Representatives of the database development team from the U.S. Department of Agriculture, used under license

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!

Explain Yourself!

A few days ago I was summoned to a meeting where one of the most basic ideas a web programmer can have wasn't obvious to our non-technical customers. Something had gotten lost in translation, and now I had to try to explain myself.

A mistranslated sign, reading

Our customers (let's call them Kate and Harold) wanted us to develop a web site that would allow users to type some answers into a questionnaire on a webpage, then take those answers and insert them into a PDF document that would be placed in their document database. We needed to keep these questionnaires for review later by our internal auditing group. All of this was completely doable, since we already had the PDF document template that we could insert values into.

While the programming group and the customers had had some emails being flung back and forth, discussing the various ways we could implement the system they wanted and the amount of time it would take, something just wasn't clicking for the customers. It should be said that this group of customers is very non-technical, and so they called a meeting to ask us programmers (specifically me, being the lead programmer on this project) some questions about the kinds of things we could do to implement this questionnaire system.

The meeting went pretty well for the first twenty minutes or so. Then, Kate started asking about what would happen when the content of the questionnaire changed:

KATE: So what would happen if we added a question to the questionnaire?

ME: Well, we'd need some time to work up a new template and add the question to the webpage.

KATE: That takes too long. Can't we set up the tool to allow us to just edit the webpage ourselves?

ME: We can certainly do this, but I'm not sure why you would want to. You want to be able to edit the questionnaire?

HAROLD: That's correct. We can incorporate changes a lot more quickly than we can now if we have this. How long would it take to set this up?

ME: Not too long I think, since we already a foundation for this kind of change in place.

KATE: Perfect!

HAROLD: Let's just be clear about this. You're going to enable us to edit the questionnaire, and the changes that we make will be in the document that is submitted to our document storage, right?

ME: ...That's why I said I wasn't sure why you wanted to do this. We can certainly enable you to edit the questionnaire on the webpage, but that doesn't automatically mean the changes you make will be included in the PDF document; we would still need to write some code to do that.

HAROLD: I thought you said you already had the foundation for this in place.

ME: We have the part that allows you to edit the webpage, yes.

KATE: So we will be able to make changes to the questionnaire?

ME: Yes.

HAROLD: I must be missing something. If we can modify the questionnaire, and you already have the foundation to do that, why does the programming team need more time?

ME: (annoyed) Because we still need to write code to make the appropriate changes to the PDF document.

KATE: But why do you guys need time to make those changes if you can already allow us to edit the questionnaire?

ME: (realizing the problem) Because the webpage and the PDF document are not the same thing.

Apparently this was news to them. It was not obvious to them that the webpage and the PDF document were not the same thing, that we programmers still had to write code to keep the webpage and document in sync. Further, I repeatedly failed to draw that connection and explain it to them, and just kept repeating myself using different words.

My immediate reaction was to be annoyed. Seriously, I thought, that's so basic! A webpage and a PDF document are OBVIOUSLY not the same thing! My annoyance faded quickly, though, because I realized that I was expecting non-technical people to know technical details.

Let's face it: customers don't give a crap about the code. All they care about is "click here, type this, submit that, done," and frankly that's all they should care about. I had incorrectly assumed that something that was obvious to me would also be obvious to them, and because of this assumption, I had failed to properly communicate to them the amount of effort it would take to implement the process they desired.

This miscommunication between technical developers and non-technical customers is a gap that I've seen a lot of programmers (including myself) fail to bridge: we're so caught up in the details of an application that we forget that not everybody knows what we know.

My old self, the one that was locked in an ivory tower, didn't see any reason to be able to communicate with customers. After all, that organization employed project coordinators, people whose job it was to communicate back and forth between the programmers and the customers, and I was perfectly happy to let them handle the customers' inquiries. It wasn't until I accidentally ran into one of these customers in the hallway (and utterly failed to explain to him what it was that I was doing) that I realized I should be putting more effort into my communication skills.

Communication skills are essential for programmers. I believe we should always be able to explain ourselves to both technical and non-technical people. At some point in our careers we will be placed in a situation where we need to explain our code and logic to a non-technical customer. If we can do this in a way that they end up understanding what we are saying without needing to know any technical details, then we've bridged the communication gap. If we can do it repeatedly, then we've become more effective at communicating than many developers out there.

And, hey, if you find yourself at a meeting similar to the one I was summoned to, maybe you'll be able to explain yourself better than I did.