Johntron

While I would much prefer to talk about some aspect of software development, I have decided to take a step back for a moment. As a Dallas-based software developer with an insatiable taste for figuring things out on my own, I’d like to explain three things I’ve learned since starting a career in software: how to deal with management and clients, acting as an ambassador, and coping with burnout. While these can all be generalized to any profession, I am going to explain how they affect developers, specifically. I’ll try not to bore you.

Managing management

There’s a lot that they don’t teach in school. While they would like to argue otherwise, I’d have to say that most professors neglect the business side of software. When a programmer enters the marketplace, they have to interact with people that are not like themselves. These people are coworkers (the easy part), customers, and bosses. While it’s easy to pick up how to work with other programmers, it’s much more difficult to work with non-technical people. The problem stems from a mutual ignorance of inherent differences. We don’t understand them, and they don’t understand us. We’re in a class of our own. We are driven by challenges and numerous sources of inspiration. Management and customers are (usually) completely different. While everyone is driven by the same things, these people tend to be driven by their reputation or revenue more so than developers.

You’re an ambassador

As you enter the marketplace, you must also realize you have two roles: a programmer, but also, an ambassador. This means playing a proactive part in your work environment. You have to do your job by writing code efficiently, but you must also be able to explain yourself and the things you produce to your peers. Provide frequent status updates (more than you think), and be ready for questions. Figure out a routine that works for you and your coworkers. Personally, I’ve found that giving verbal updates at the end of the day, and an email at the end of the week listing all of the things I’ve accomplished works well for me and my superiors. This keeps everyone on the same track, but also shows your superiors how productive you are. Your mileage may vary, because different companies require different levels of communication. I would speculate that larger companies can accomodate less communication than smaller companies, but this is just a hunch.

In the business world, communication is everything. If you’re going to miss a deadline, make sure the appropriate people know this. This is particularly important when you’re working with third parties. If a client shows up to a meeting expecting to see a completed project, the last thing you want to do is tell them, “Sorry, we need more time”. Take some initiative, explain the problem (in layman’s terms) and ask for some more time. As long as you haven’t pushed back the project too much already, I’m sure the client will understand. If the client doesn’t understand, be sure your management knows this so they can handle the client for you (that’s not your job). Who knows, management might just get rid of the client if they’re too unreasonable.

Burnout sucks

As a programmer, you are highly succeptible to burnt out. You will at some point begin hating the things you’re currently working on, the people you work with, and possibly even programming in general. From what I have seen, in myself and my peers, this is normal. There are ways to delay the onset of this boredom as well as ways to reduce the effect.

One way to avoid burnout is to avoid feeling rushed. Take your time, think things through, and enjoy your challenges. Yes, there are deadlines, and these are very important, but remember to pace yourself. If you start feeling overwhelmed, try to add some variety to your tasks and take the larger tasks in smaller steps. Progress is important, but working at a sustainable rate is just as important. There will be last-minute issues that must be dealt with as soon as possible. Deal with these as they come up, but try your hardest to avoid the major setbacks. This is probably one of the hardest things to conquer. Computer science is not as concrete as most people realize. Our work is fraught with hidden conflicts.

Here’s an example: Recently I was moving a website to a production server from a development server. The website was mostly plain HTML, with some PHP includes interspresed throught the site to handle some common sections of the site (my production team refers to them as “includes” in short). The development server and the production server were virtually identical; however, the production server allowed for PHP short tags (a historical relic from PHP 4), and the development server did not. This means that anytime the server sees the “<?” and “?>” tags, it sends the stuff between them to the PHP interpreter for parsing. Unfortunately, most of the pages we were transferring had the following at the very top of the file:

<?xml version="1.0" encoding="ISO-8859-1" ?>

Obviously, this isn’t PHP code (though it is good practice). The server was the first to point out the problem, and this is not good on a live site. The solution I came up with was to run some fancy commands through SSH to do a recursive find/replace for this string (replacing it with nothing) on the development server, then re-uploading everything. If the server did not belong to our client and was not on a shared hosting account, things would have been easier. Regardless of the solution, the point I’m trying to make is this – things come up, don’t freak out. Take things in steps and be intentional with your actions. If you don’t, you will begin sliding down the slippery slope known as burnout.

Once burnout sets in, how do you deal with it? Unfortunately, there is no straightforward answer. Sometimes burnout lasts a few days, sometimes weeks (maybe a month?). If it is not too severe, simply getting some extra sleep each night can help. If it is very severe, you may need to use some of your paid-time-off (PTO). If deadlines are approaching, obviously you cannot just take a break. If this is the case, ask your superiors if you can get some more help. Begin by explaining the problem (you are overwhelmed, bored, or whatever), and suggest looking for a freelancer to help out for a while. If this doesn’t fly (and your bosses don’t hate you), you may be able to get some additional PTO after you’ve completed whatever it is you’re working on. My boss actually suggested this to me, so it’s definitely not unreasonable.