Software engineering can be an absolutely thankless job. Oh sure, it has its perks. You get to be creative and solve problems, and there is a beauty and elegance in well written code sometimes that can be hard to describe to those that don’t speak the language. Where we were once portrayed almost universally as pocket-protector-wearing, tape-on-the-glasses nerds, Hollywood now depicts us as elite hackers that can sit down at a never-before-seen terminal and instantly predict the passwords to any government agency in the world, and find a way to copy and then delete their entire database onto a USB drive in under 60 seconds. I wish. I don’t think I could hack my own laptop let alone anyone else’s, and some days it can take me more than a minute just to copy some Word documents to my USB drive.
The reality of being a programmer is a bit less sexy than our Hollywood counterparts however. Our bosses and co-workers don’t give a damn about how elegant our code is. They don’t understand that we are asked every single day to estimate how long it will take to code features and fixes that we have absolutely no idea about until that very moment. Frankly, we’re often asked to do things by people that have no idea what they are even asking us to do! Our worth is often measured by our ability to crank out code at a record breaking pace, and our willingness to work insane amounts of hours doing so. Impossible deadlines are common. Work/life balance can often be non-existent. And as we all know, one “aww shit” can wipe out volumes of “atta-boy’s”. At the end of the day, it’s your job to produce, and unlike sales-people and executives, going above and beyond doesn’t often net you a trip to the Bahamas, a gold watch or a profit-sharing check. In fact, working harder usually only ends up raising others expectations of you, and when you fall short of that new bar you just set, you end up looking and feeling like a slacker.
We all look at people like Steve Jobs, Bill Gates and Mark Zuckerberg, and think that if we were just more talented, more creative and more driven that we’d be more successful at our jobs. We stay up until the wee hours of the morning learning the latest new frameworks and technologies, spend entire weekends refactoring our core libraries to be faster and more efficient, and in many cases we end up neglecting our own needs, friends and families in the process, and for what? I can’t begin to tell you how many times I’ve bent over backwards to get my code done and checked in, only to be met with frustrations and complaints from my bosses and co-workers, rather than the kudos and rewards I was hoping for.
“Why did it take you so long to code that new feature? Why did QA find bugs in your code? Didn’t you even test anything? And why aren’t we using <insert latest beta technology here> in our app?”
It’s easy to get defensive when people call our babies ugly, and when our hard work and sacrifice is rewarded with negativity and a lack of appreciation. Even when dealing with team members, sometimes simply pointing out an overlooked issue in code, or requesting a small additional feature can net an aggravated and sometimes accusatory response from the person who coded it. It’s not a personal attack however. It’s just business. When the widget doesn’t “widge”, and the “foo” is missing a “bar”, it’s not the fault of the person that found the problem, nor does it constitute an attitude problem on the programmers part. How we respond to the questions and complaints of others, our co-workers and clients alike, will have a huge affect on how our value to the company is perceived, and ultimately, how far we can go in our careers.
The most successful programmers have the right attitude. A great attitude will trump great skills any day, and will be recognized and rewarded by even the most non-technical of people.
Empathy is the key
What can really hold us back in our careers however is our attitude. For people who solve problems for a living, you’d think we’d figure that out a little faster. As we discussed earlier, no one cares how many hours you work or how elegant or imaginative your code is. Breaking our backs to get our code cranked out is seen as “what our jobs consist of”, and no one rewards you for doing what are supposed to be doing in the first place.
What other people do notice however is how you respond to their needs and their efforts. This same premise applies whether we are talking about co-workers, clients or end-users. If you want people to recognize you as a great employee, they first need to experience and appreciate you as a person. No amount of skill or hard work will ever replace that fact. I’ve seen some of the worst programmers I’ve ever known rise through the ranks of companies, surpassing much more experienced and talented programmers than themselves, based simply on the fact that they know how to get along with others, and how to play the game. Usually, these same people end up becoming leaders and managers while other programmers continue to struggle along in their own personal “bubble”, wondering where they went wrong and why they didn’t get the promotions they felt they deserved.
Let’s look at some typical examples to see how we might approach things in such a way that people will respond more positively to what we do and say, given how we do and say it.
Boss: I don’t understand why it took 3 days to just add a button to a page? What were you doing all that time? Joe added a new button to our other app just last week, it took him 2 seconds!
Bad reply: Joe works on a Windows app, and he added a button to a button bar that was already designed to easily add buttons to it! This app is a web app, and it needs to look and work correctly on all devices and adapt dynamically to screen size and rotation and browser and changing internationalization ! You asked for that button where there was no room for a button, so I had to redesign most of the page around that request, test everything in different browsers to make the layout doesn’t break on small devices, create a new service, add new logic, yada yada yada…
So why is this a bad reply? Yes, it’s true, your boss probably has no idea how much “invisible” back-end work goes into “just adding a button”, no idea how much testing front-end work can require compared to the business layer, no idea that you worked overtime making this happen, and can’t seem to understand that they are comparing apples and oranges. But that’s not their job, is it? And at some point all this detail just starts to sound like excuses and justifications, which is bad when your boss is already questioning what’s going on.
What I suggest is “reading between the lines” and seeing things from your bosses point of view. Your boss has likely never had to write code in his/her life, and why it took you so long is not really the question they are asking anyway. What your boss cares about is meeting their deadlines, making the client happy, increasing sales, and making their own boss happy. By caring about what your boss cares about, you’ll make them happy too. Use your empathy to connect with them and their feelings, and address their needs and goals. For instance…
Better reply: I can understand why you feel frustrated, and appreciate that getting this new feature added is critical to you. It’s important to me as well, and I want to do the best work I can so that our product will function flawlessly and our customers will be delighted. There was a lot of back-end complexity involved in adding this feature, and I’m happy to go over that in detail with you if you like. It took some extra time however to make sure that the button will work flawlessly on all devices and in all situations, and to test it thoroughly so that QA will be reduced. In the future I’ll make sure to send out more frequent updates so that you’ll have a better idea of where I’m at and what I’m doing.
In other words, don’t make excuses, heck, you don’t even really need to explain, what you do need to do however is let them know that you feel and understand their pain, and are focused on the things that they are focused on. Offering a suggestion on how to make things better never hurts either, and takes the pressure off of them to come up with an idea themselves.
QA Person: I tested that new button you added again, and this is the second time now I’ve re-opened that ticket because it still isn’t working like I expect it to. Did you read my notes in the bug? Did you even test it before checking it in?
Bad reply: Yes, I read your notes, and I followed all the steps you spelled out. I’m just not able to recreate the problem, and I even sent you a video of what’s happening on my screen. Did you see what I sent you? If you want this fixed you’re going to have to find a way to re-create it such that it will fail on my machine too.
The problem with this reply is that it is angry and unhelpful. It expresses frustration with the person, and then puts the extra work on them to do something that they already feel is your fault and due to your inaction. Again, the best approach is to “put yourself in their shoes” in your reply.
Better reply: Thank you for your patience, and for catching any mistakes I may have made before the client sees them. Since I can’t seem to reproduce this on my system, can we instead plan to meet tomorrow morning? I’ll bring my laptop to your desk, and you can walk me through what’s going wrong. That way we can both make sure we understand what is failing, and maybe I can fix the problem right there before I leave so that you’ll know it’s already tested and ready for check-in. Let me know what kind of donuts you like, and I’ll bring some!
The solution here again is to get the person what they need. A QA person wants a clean bill-of-health on the app, and is frustrated by what they perceive to be a lack of communication and understanding. Offering to come over and see the problem first-hand shows dedication and initiative on your part, and helps them feel as though you are serious about getting their problem fixed for them. In fact, they are being offered one-on-one attention and service, and are also being offered a solution that should guarantee that the bug will be fixed properly when checked in. The donuts might be a little kiss-assey, but it is amazing how far food will take you in relationships.
Some general tips to follow in order to stand out and be recognized at work
- Never apologize unless you actually need to make amends for a fault. Instead, try a positive response. For example, instead of, “I’m sorry I took so long”, try, “Thank you for being so patient”.
- Emulate top performers. Look for the rock-stars at work, the people everyone likes and count on. They are doing things the way other people respond positively to. Make friends with them, and mimic the way they act and respond to people. Consider it a “best practice”.
- Get in before most people, leave after they do. While this isn’t always possible to do, people do notice you coming and going, and if they aren’t there to see it, then it didn’t happen. If everyone else gets in at 7am and you waltz in around 11, people get the sense you are lazy and unambitious. If most people work until 6pm and you skip out around 4, they think you are eager to leave and don’t want to work as long as everyone else. Appearances matter, so be conscious of them.
- Be the life of the party. Programmers aren’t always the most social animals, but movers and shakers in the company are. If you want them to notice you, be noticeable. Invite people to lunch every day. Send out funny emails. Put a bowl of free candy on your desk. Bring bagels in the morning. Do these things for a week and watch how many new people begin to notice you.
- Communicate early and often. If you Scrum every day, great, but if you don’t, then make sure to update your boss, your lead and your co-workers about what you are working on, and any blocking issues you come up against. There is no need to be overly verbose, just a quick update will let everyone know you are there and working on something, and that you care.
- When you’re not working, don’t talk about work. If you are out to lunch with the group, or at the water cooler, or anywhere that people converge that isn’t work related, then be more vulnerable and personal with them. Ask about their families, how was their last vacation, if they have any plans for the evening, anything that expresses an interest in who they are and what they like to do.
When all is said and done, the best person for the job is not always the best programmer, it is actually the person who people relate to and trust the most. I once knew a guy who had been with the company for a month. He was a younger guy and not very good at his job, and lacked experience. Every day however, he stopped by the bosses office to make small talk and tell her a joke or two. One day, when she stepped out to use the restroom, he jumped on her computer and put photos of David Hasselhoff all over her desktop wallpaper. Instead of being fired for using a manager’s machine however, she thought this was clever and hilarious. A few months later, he was made the lead of our group, a group where most of the other people had 10+ more years of experience than him. Now, I’m not saying to break into your bosses PC. What I am suggesting however is that attitude is king, and that you may actually find that takes you a lot further in the company than your elegant coding.
Let me know how it goes!
If you like this article, please take a moment to give it a few claps, and follow me so that you’ll see more of my posts!