The No Fun at Work Rule

I've got a pretty large government client at the moment. They feel better when they get to see me hangin' around the office (and can you blame them?). Problem is, hangin' around their office takes away some of the luxuries of my office. For example, my team and I like to go out to throw the football around from time to time.

Sometimes we get programmers block, or we need to talk about something, or we just need some sunshine so we mosey out to the parking lot for some ball. The other day, I asked one of my partners if it'd be okay if I brought a football to the client office. He looked at me like I was impaired.

Later that day, I was hanging out with another partner waiting to start a meeting. I said, "Hey Chuck, I'm gonna start smoking. I'm planning on smoking 6 cigarettes a day and I estimate that it'll take 10 minutes to smoke each one. Is that okay?"

Chuck said, "Well, Patrick, other than the fact that it's really odd that you are planning to start smoking, I don't really have a problem with it."

Then, I asked him, "Well, what if instead of smoking for an hour a day, Ryan and I spend 20 minutes a day throwing the football?"

Chuck leaned back in his chair and sighed. "Well, I'm going to have to think about that. I'm not sure that's going to look good to the client."

My point is, something is ass-backwards. If I want to spend an hour a day (on the clock) smoking cigarettes, nobody cares; but if I want to take a 20 minute break (off the clock) throwing the football, having a work related discussion, enjoying a brief reprieve from the stress of the work day, everybody thinks I'm going to look like I'm slacking off.

Don't get me wrong, Chuck knows that we enjoy our outdoor time back at the Emerald office. He knows there's benefit to it. Not only does it keep my team happy, but it helps keep the team cohesive and energetic. He's just concerned about how it will look to the client.

My point is, why is there this "no fun at work" rule? I've decided that I will, for the rest of my career, spend a portion of my time focussed on making sure that my employees are happy, comfortable, and healthy.

Your Field -- How to Land a Job as a Software Engineer

Well. This is it. My last post in the How to Land a Job as a Software Engineer series. I spent a lot of time deciding whether this would be the first post of the series or the last.

I thought about making it the first post because it's really the first step to becoming a software engineer, but I saved it for last because I wanted to make sure I gave these thoughts plenty of time to ripen. If you've been following the series, you probably know how this series came about in the first place.

Emerald Software Group has been interviewing programmers in search of new development talent. I've used a lot of examples (both good and bad) from real life interviews I've conducted in the past few months. This particular story is one of the most important lessons I've learned in my career, so it's really important to me to tell it correctly.

I know that my style and sense of humor can be pretty sardonic and I know that many would be readers find that off-putting, but I will do my best to convey my sincerity in this post.

A few months ago, I interviewed a candidate who had a masters degree in computer science from a relatively prestigious technical university in Georgia. I expected great things from this developer and was excited about the interview.

I went through my standard series of programming questions and was disappointed by his lack of understanding of the technologies he had spent the last 6 years studying. After a while, I started feeling bad for the kid and decided to move on with the interview. After all, like I've said before, just because you don't know the information doesn't mean I'm going to assume you're incapable of learning it.

I decided to ask him a little about himself. I closed my notebook, leaned back in my chair, and asked, "what kinds of things do you program in your spare time?" He said, "I don't really program in my spare time."

I was pretty surprised, so I asked, "Do you read programming blogs or books? How do you learn about new technologies and techniques?"

"I don't really bother learning it until I need it."

I was fundamentally confused. I didn't understand how he had spent 6 years in school studying computer science and was looking to begin a career in the field, but that he neither knew anything about it nor had any interest in learning it. I thought for a minute and I asked him, "Why are you here?"

He said, "I'm looking for a job."

"No, I mean, why do you want to be a programmer?"

"Because it pays well."

"Do you like it?"

"Not really."

I was dumbfounded. I asked him a few more questions so that I didn't have to end the interview abruptly, I told him we'd be in touch, and I walked him to the door. If you want to write software for a living, you need to love it. It's not just a job; it's a craft. If you're not doing it for the love of the field, then you're committing an injustice not only against yourself but also against your employer, your teammates, and the customers.

To be sure, I don't just feel this way about software engineering, but about all careers. Whatever it is you do, do it for the love of your field. If you don't like what you do, let alone love it, you'll be miserable for most of your life and there is no amount of money that will make up for a lifetime of misery.

Now, I know that there are plenty of people out there who would be perfectly happy spending 5 days a week doing something they don't care about so that they can have more fun the other 2 days of the week. You cannot be great at what you do if you don't care enough to try and I will not tolerate mediocrity, especially intentional mediocrity.

So chose your field carefully. Don't get a degree in software engineering if you don't like it. Obviously, don't get two degrees. Think about the things that you love to do. What would you like spending your weekends doing? Take those things and find a way to make money doing them. If you make your living doing what you love, you'll always love what you do, you'll always be proud of your work, and you'll be in the top of your field.

Your Communication Skills -- How to Land a Job as a Software Engineer

At long last (due to some intense deadlines), I'm getting around to the fourth installment of the How to Land a Job as a Software Engineer series. This concludes the job application sequence starting with your resume and ending with your interview.

This post is about maintaining good communication skills throughout the process. A very close friend of mine named Ryan LaFevre, who is a Ramblin' Wreck from Georgia Tech and a hell of an engineer, once mused to me, "I don't write good; I are a engineer." Obviously said in jest, I bring that up because I know a lot of programmers who feel like even a cursory grasp of language arts is completely unnecessary for anybody in a technical field. My former English teachers would probably be pleased to see me say that communication skills are of fundamental importance.

Do you ever watch those court room shows? If so, you've probably seen scenes where one attorney makes a damning argument or the witness breaks down in an emotional display, at which point the other attorney objects. The judge says, "sustained" and instructs the jury to ignore the preceding outburst and has the text stricken from the record. Now, imagine being on that jury. Could you possibly ignore that? Even if you don't make your verdict based on said event, could you possibly remain unbiased by it?

It's the same thing with your communication (both verbal and non-verbal). While I'd rather claim that I focus primarily on the skills you actually need to do your job, and while I can ignore your communication inefficiencies, I cannot ignore the feelings I had when I communicated with you.

For example, I'm not going to refuse to hire a candidate just because he's 25 years old and still can't discern the difference between they're, there, and their; however, there's a pretty good chance I will assume she's not all that bright. Thus, when I sit down with the resumes and my notes from my three favorite candidates to compare them side by side for selection, ceteris paribus, he'll get eliminated first because I won't feel like he has as much potential as the other candidates.

Here are some actual excerpts I've received from job hopefuls:

Hello Mr. Caldwell, I just wanted to touch base with you to see how your doing.

What about my doing? You leave my doing out of this and I won't say anything about your dumb.

The sample project I sent you is very simple on the front end, but it's back end is where all the magic happens.

I just read your email and its dumb is showing; it is back end is where you are not getting a job. Thanks.

I know what you mean about taking your work home with you. I've spent a lot of time with my computer in my underwear coding until the middle of the night.

First of all, gross. Second of all, your computer codes by itself? Third of all, what was your computer doing in your underwear?!?!?

Thank you very much for meeting with me today -- I really enjoyed talking with you -- If there's anything else that you need from me, please feel free to ask for it -- I'm available by phone most of the day and I'll get back to you as soon as possible

WTF? The period exists for a reason; please use it. If, by some chance, your period key is broken and you can't find a working keyboard with which to send your email, please hold alt and hit 0046 in lieu of the double hyphen.

i'll be available tuesday afternoon around 1:30 or so. is there anything i need to bring to the interview other than my resume? i'm really excited about the opportunity and i think emerald software group will be a great fit for me

i hate you (alt + 0046)

Also, sometimes it's not what you say, but how you say it (or, how often). Don't nag me please. I will get back to you; I promise. If you email me every day asking about the status of the job, on your third try (or second if I'm in a bad mood), I will simply let you know that you have been selected out of the applicant pool.

Written communication isn't the only place you can make silly mistakes. Oral communication is replete with its own difficulties. Sure, you less often misspell things orally than you do in written communication, but there are some things you're unlikely to get away with. For example, I really don't want to hear your stance on the adult entertainment industry, I don't want to hear a story about a time you were drunk, and I really don't want to know what crimes you've gotten away with. Keep it on a professional footing — please!

Here are some other hints for oral communication:

• Don't swear a lot; I'll just think you've insufficient vocabulary.
• Don't tell me a dirty joke you heard a few days ago. Let's get to know each other a little first
• Don't opine on politics or religion. Chances are you won't offend me, but on the other hand, chances are I know someone at the office you would offend.
• Don't tell me my school sucks. For that matter, don't tell me any school sucks. I don't care if you're just kidding and I don't care if you went to a rival school. If you say something disparaging about any school, I'm either going to think you weren't smart enough to get in or you're pompous. Either way, I don't want you on my team because I may later want to hire someone from that school.

Finally, it is worth mentioning that not all communication is verbal. There are plenty of ways you can non-verbally tell me you're not ready for the position in question. For example, don't be late. Don't smell bad. Don't wear your favorite pair of tattered jeans and raggedy flip-flops. Don't be over-confident. Don't be under-confident.

By all means, be yourself and try to have some fun. If you have fun, people are more likely to enjoy talking with you. If you have fun, the worst that can happen is you have a good time, meet some good folks, and learn some new skills.

Your Interview -- How to Land a Job as a Software Engineer

This is the third installment of the How to Land a Job as a Software Engineer series. Now that you've submitted your resume and completed your prescreening, you've been called in to interview.

It's a pretty safe bet that you'll have several interviews to go through including talking to someone in HR, some management folks, and some technical people too. I do the technical interview around here and there are some things I've noticed interviewees do that consistently irk me. Here are things you shouldn't do on a job interview (in no particular order):

• Don't tell me you don't need to answer my question. I've actually had several interviewees tell me that they don't need to answer my question because it's obvious that they know the answer. If I've asked you the question, it's because I want to know how you're going to answer it. Especially if it's obvious you have no idea WTF you're talking about.
• Don't bother going if you embellished on your resume or cheated on your prescreener. If you tell me you're a 7 out of 10 with SQL and you can't tell me the difference between an inner join and a left join, I'm not going to hire you. If you tell me you're a 3 out of 10, then you have a fighting chance.
• Don't ramble. I've only got so much time to talk with you. Most of the time, I enjoy interviewing and I enjoy the conversation, but I really do need to get back to work. Just answer the question I asked and move on.
  
  Also, as a side note, when I was in graduate school, we talked a lot about interview techniques. The business oriented interviewers are likely to ask you questions like, "What's your biggest shortcoming?" or "Tell me about a time you had a conflict with a co-worker." These are cheesy questions and you're going to have a canned response, so you probably wonder why they even bother asking the question. Keep in mind that these folks have a lot of experience interviewing . . . much more than you do most likely. They ask the question because if you have a canned response, they can catch you off guard.
  
  Here's the technique. I ask you a question, you give me the canned response, and I just look at you waiting for you to say more. In only seconds, the silence becomes deafening and you start talking again. Now, you're out of your comfort zone and you start telling the truth. The more I nod and keep my mouth shut, the more you confess. Moral of the story? Don't ramble. Just answer the question and then STFU.
• Don't make things up. If you can't answer the question and you can't make an educated guess, don't just make something up assuming I won't know. I very seldom ask questions in an interview that I don't already know the answer to. If you make something up so that you don't have to say, "I don't know," I can almost guarantee that I'm going to know you're full of it.
• Don't say you don't know the answer to a question unless you're absolutely sure you know nothing about the topic. Most of the time, I'm trying to figure out where you are in your professional journey. I don't expect you to know everything. Chances are, if you can give me a starting point, I'll prompt you until you get the answer. I just want to get a feel for how well you understand programming concepts. If you simply say, "I don't know" then I have nowhere to start and you don't get partial credit.
  
  For example, if I ask you the difference between an interface and an abstract class, and you say, "I have no idea" then I have to operate under the assumption that you indeed have no idea. If you say, "well, I know they both define contracts for classes" then instantly you have partial credit. Then I'll ask you, "why would you use them?" You say something remotely intelligent about why you'd want to do this and you have even more partial credit. I'll keep asking you questions until I'm convinced that I've given you as much credit as you can possibly get.
  
  By the way, this doesn't contradict the previous item. If you make something up and present it like it's fact, I'll assume that you're making things up. If you look at me and say, "you know, I'm not sure, but it sounds like . . . " and then you make your best inference drown from past experience . . . even if you're way out in left field, you still get partial credit.

The ThoughtWorks Agile Southeast Conference

I'm taking a quick reprieve from my How to Land a Job as a Software Engineer series to write about a very informative and enjoyable event I attended this Tuesday. ThoughtWorks held its first professional conference in the Southeast and a friend of mine who is a thought worker invited me to go. It was a well organized event and several noteworthy thought workers presented.

We kicked off the day by listening to a keynote by Neal Ford called, "Why, Not How." Neal pointed out that there is solid evidence that agile works, but that few people investigate why it works. That is to say, the talk focused on why agile works rather than how to work agile. There was a great deal of merit to the things he said about the psychology and biology behind the effectiveness and efficiency of agile methods. This was one of my favorite talks, perhaps because it appealed to my background in behavioral neuroscience research at Duke, my experience getting my MBA, as well as my interest in becoming a better programmer. If only he had said something about airplanes it would've been perfect.

The breakout sessions started after Neal's keynote allowing us to chose between the management track and the technology track. I generally stuck with the management track. Just kidding. But, I wish I could've been in two places at once and I'll explain why shortly.

The first breakout session I went to discussed code metrics, tools for gathering metrics, and ways to interpret metrics. In fact, the significant interest in measurement may be one of my favorite aspects to the agile method. I suppose it appeals to my empirical nature; after all, if you can't observe it, it didn't happen. :)

Next, Anthony Pitluga and Ali Aghareza talked about cloud computing. They made an interesting distinction to me regarding Software as a Service (SaaS), Platform as a Services (PaaS), and Infrastructure as a Service (IaaS). They also pointed out a use for cloud computing that I can really get behind. Just so you know, I think there are very few instances where cloud computing is better than having your own infrastructure, but I believe these fellas were right on when they said it's perfect for testing. I mean, you can spin up (on demand mind you) a full test environment that very closely mimics your production environment on Amazon's EC2. Imagine that! Rather than doubling your capex to get two (or god forbid) three duplicate environments, you just build, test, and deploy your solution to EC2. You bang on it for as long as you need and the whole testing cycle costs a few hundred an hour. Very clever indeed.

I switched over to the management track for Saleem Siddiqui's talk about software complexity. He talked about essential complexity and incidental complexity in software, making a distinction between complexity that has to be in software and complexity that just sort of happens. Then, he talked about why it's better to focus on the latter rather than the former because, well, the former has to be there. He's a well spoken and interesting speaker to be sure.

After that, we took a much needed lunch break and had some really good food (although there was a vegimarian behind me in line who seemed to disagree, but since I'm a meatitarian I didn't notice). During lunch, Scott Conley gave his keynote about Platforms and innovation. As ThoughtWorks Chief Strategy Officer, Scott knows a lot about innovation and he's damn good at talking about it. Despite the incessant tinging of forks on plates, I got a lot out of Scott's talk.

After lunch, I went back to the technical track and enjoyed Graham Brooks's talk about testing web applications. He showed us a framework he's been working on that allows him to apply test driven development techniques to web applications.

Next, Dave Vollbracht talked about the perils of allowing everyone to have a unique development environment. It's important to note, though, that he didn't say anything about being able to try new tools. Basically, he said that if a team member finds a great tool and starts using it, that everybody should have it as well. That way, the machine you are working on may not be the same piece of hardware, but the environment will always be identical. That makes it much easier to image new development machines, to engage in paired programming, or to share team members with other teams. Dave also talked about several methods to achieve this uniformity.

Really, the biggest downside is that I couldn't be in both breakout sessions at the same time. I would really have enjoyed Ross Pettit's talk about Budgeting and the Financial Implications of Agile and I'm sure I would have loved to hear about Gregory Reiser's experience with offshore development. Can agile make offshore development actually work? I guess I won't know until next time.

Speaking of next time, I'll definitely be there and I'll be bringing friends. It was a good conference, and I enjoyed getting the ThoughtWorks perspective. I hope the next one will have a lot more attendance because I'd love to get other perspectives too.

Your Prescreening -- How to Land a Job as a Software Engineer

My How to Land a Job as a Software Engineer series has me inspired and this is the third post I've written today. If you've ever applied for a technical position, you've probably met the prescreening questionnaire before. For software engineers, it generally comprises a set of questions about the language you'll be using and a few puzzles or programming tasks.

My company has something of a prescreening questionnaire and we're working on a more robust one. I've done them in the past and I have several friends who have done them for the companies they work for now. It's a common tool to assess your goodness of fit with the requirements of the position being filled.

So, you get the email from the HR department that says, "Thank you for your resume. You've been selected to move to the next stage of the process. Please complete this prescreening questionnaire and return it. You have one week from today." Sometimes the questionnaire will be online in quiz form and other times it'll just be a list of problems. Sometimes you're allowed to use the internet to help you and other times they ask you not to. In any case, my suggestion to you is to follow whatever rules they give you. Don't cheat! In my post about what hiring managers are looking for in a resume I kind of harped on the whole honesty thing.

Well, I'm about to do it again. Some people have their friends help them with the test or the coding problems or they Google when they were asked not to. Sure, this may help you get the job, but you are setting yourself up for failure. If you cheat on the test, they're going to find out when you go in for the technical interview. If they don't find out in the technical interview, they're going to find out that you're ill qualified once you start working. In any case, you're just gonna disappoint them and there's very little good that can come of it.

Work the problems and do it with integrity. If you don't get the interview or you don't get the job, it's for the best; that job was not for you and you're now better prepared to move on. After you submit your results, study the questionnaire. Learn everything you didn't already know. Then, learn more about what you know. Next time you have a prescreening task, you'll actually know the information you need. When you do get called into that interview, you're going to impress them with your knowledge and capability instead of disappointing them.

Your Resume -- How to Land a Job as a Software Engineer

This is the first post of a series I call How to Land a Job as a Software Engineer. I chose this as the first post because it's really the first step in the process; however, I do not think it's the most important step because I believe that accolade belongs to selecting the right field in the first place. Also, from your perspective, finding a job to which to apply is the first step; however, I'm writing this series from the perspective of the person who makes the ultimate decision about who is and who is not worth hiring.

That being said, your resume has to be your foot in the door. Let's say that for a given job opening, we receive 100 resumes. At least half of those will be screened out before they even get to me. I'll eliminate at least half of the remaining resumes before we start inviting people to interview.

I've worked with resumes from every angle I can think of. I studied job applications and resumes when I was getting my MBA, I've been a job applicant, and I've reviewed dozens of resumes of job hopefuls. In graduate school, I read chapter after chapter about how a good resume is structured. As a job applicant, I perused every online resource I could find for hints and tricks. As a hiring manager, I can tell you what makes a difference to me.

But, before I get to my tips and tricks, I think it is worth pointing out what happens when a job opportunity opens up. First, the organization has identified a need. Second, the organization publishes that need. Third, many people apply. Fourth, one person is selected.

When you apply for the job, you feel like the organization is trying to hire the best candidate; well, they're not. Don't worry though because they think they're trying to hire the best candidate too; but they're not. In reality, they're trying to eliminate the worst candidates from each phase until there's only one left. I know it's something of a pedantic distinction, but it is important.

Why? Well, when I start looking at resumes, I'm not looking for reasons to hire someone. I assume that if you've sent me your resume, you feel like you'd be right for the job and that the job will be right for you. Therefore, when I look at your resume, I'm looking for reasons you're wrong. I'm trying to eliminate you because I don't want to waste your time and mine by having you in for an interview if I can tell it won't work out.

Sure, there have been times that something really stood out on a resume. Usually, it's a bad thing, but sometimes it's a really good thing. Just, keep in mind that things that stand out don't always stand out in a good way. So, in all forthrightness (and at the risk of seeming petty), here are some of the things that I find to eliminate you from the applicant pool:

• I don't want to read your 5 page resume. In fact, I won't read your 5 page resume. I'll look at the first half of the first page and the last half of the last page. If you cured cancer in the middle of your career, chances are pretty good I'll never even know about it. If there's something you want me to know, put it in those sections. Even better, keep the whole thing succinct so that I don't think you're verbose.
• Don't have grammatical or spelling errors in your resume. Ultimately, you're talking about a two page report about a topic you're the only living expert in -- you. If you're writing a doctoral dissertation about a topic you previously knew very little about and a few grammatical or spelling errors slip into the first draft, it's one thing. It's another thing altogether to write a two page paper about what you've been doing for the last 10 years and to make grammatical or spelling mistakes in your final copy. What does that say about your attention to detail?
• Be factual; don't be boastful. I don't care if you think you're a great communicator or if you think you're an excellent problem solver with 12 years of experience leading successful teams. I just want to know how long you've been at it and what you've done. I'll figure out on my own if you're a great communicator or an excellent problem solver. Besides, how do I know that your definition of a "successful team" isn't one where no more than half of the team quit and 10% of your projects were on time and on budget? In fact, if you put this in your resume, I'm going to tailor your interview to prove you wrong.
• Tell the truth! I mean, seriously . . . in the name of all things holy and good, don't lie on your resume. If you tell me you have 10 years of programming experience but you really only have 5, I'm probably going to figure it out. As soon as I figure it out, I'm just going to tell you to leave. I'm not kidding; end of the interview. If you tell me you have 5 years of experience and I need a 10 year programmer, you didn't want the job anyway because you're probably not ready yet; however, I'll think, "man, that person was honest and I'm gonna save that resume for the next junior opportunity."
  
  Most of the time, I just need a programmer of any sort. So, if I'm just looking for a programmer and you say, "I have 5 years of programming experience," and I can tell that you're being honest, I may still hire you; I just won't pay you as much. So, just be honest. If you're honest, the worst that can happen is you don't get the job and everybody's happy (or at least at worst mildly disappointed). If you lie, the worst that can happen is you take a new job, everybody suffers, and you get the ax after your 90 day interim.

Now, here are some positive things I look for in a resume:

• I actually do care what your hobbies are. I'm not going to hire you based on your hobbies, but if you're up against someone who is exactly equal to you in every way except that your hobbies are cooler, more relevant to the field, or are similar to my own then I'm more likely to hire you. In fact, I once invited someone in for an interview because I wanted to know more about his hobby. Came to find out that he was a very capable engineer, but was just a little too expensive for us. If I had the money, I'd have hired him on the spot.
  
  It also makes you a real person. I look at a lot of resumes and none of them are real people, but if I know you're into underwater basket weaving, then I'm likely to remember you. In fact, I don't even look at the names on resumes. I just look at the resumes, chose the ones who seem capable, and hand them to my boss saying, "call these in please." If I see that you're into underwater basket weaving, I'll be like, "heh, what's this person's name?"
  
  So, unless your hobby is rolling your poop into little balls, then go ahead and include a hobbies section on your resume. (Not that there's anything wrong with rolling your poop into little balls; I just don't want you touching company equipment.)
• I want to see that you stick with jobs for a long time. While I know that contractors will have a lot of short term projects and few long term employments, I really like it if you consolidate your contract work into one item on your resume. Then, you can list the contracts you've worked on under that line item rather than listing each contract as though it was one job. It helps me rapidly review your work history. If nothing else, at least specify that the position was a contract position or I'm going to assume that you can't keep a job longer than a 9 months.
• Apply for a job that's appropriate to your experience. If you've been programming for 10 years and still consider yourself a junior developer, I'm probably not going to call you back. I know that in most cases, one of two things will be true. Either you're not progressing at your craft and thus aren't worth the investment or you're better than the job you're applying for and you're just going to quit as soon as another opportunity comes up and then you're not worth the investment either. If you should be a senior developer, be a senior developer.