Rename Perl 5? Marketing: UR DOIN IT WRONG

Earlier this month Ovid once again raised the question: Should we rename Perl?”

As usual, the question sparked a flurry of opinions on the matter. Most of the discussion occurred in the comments of Ovid’s original post.

I’m not here to chime in on that question. Whether the name should change or should not, what it should change to, when it would happen, these questions are all closed. RJBS has said there will be no change right now and that’s that. He is driving the Perl 5 bus right now. If he says the name is not changing then that’s good enough for me. Discussion closed.

No, I’m not here to discuss that matter. I’m here to point something out:

Damn, team. That was some dismal marketing I just witnessed.

Just what exactly is the problem you’re looking to solve here? Where are the metrics to support that? Whom are you looking to convince? How will the solution be rolled out? Who’s going to do the work? What’s it going to cost? How will you know when the work is done? How will you know whether it’s working?

None of the people participating in the conversation would ever consider releasing a small patch to a CPAN module without first having a complete set of tests for it. Yet the same people seem to have no problem changing something as fundamental as the name of the language without performing some sort of market research and testing.

Despite the reputation its earned, marketing is not a crap shoot. A successful marketing or branding campaign requires just as much forethought and carefully considered execution as a good piece of software. You don’t just throw it together, put it out there and hope it does what the target audience needs. It could be impossible to recover from the damage caused by rash branding decisions.

I would welcome nothing more than more discussions about whether Perl 5 should be renamed. But I would like them to be as well researched and considered as any other change which would be made to the language itself.

Putting Away My Pitchfork: The Yahoo Remote Worker Announcement

On February 22nd, 2013, Yahoo! CEO Marissa Mayer announced that all remote employees will be required to work from their local Yahoo! office by June.

The internet grabbed its pitchforks and lit its torches then exploded with anger and derision.

Does this announcement place a hardship on remote Yahoo! employees? Probably.

Is this a draconian move by Mayer? It seems that way.

Would I have done the same in her place? I don’t know. And neither do you.

The fact of the matter is that none of us are in her place. As a company, Yahoo! has been foundering for years and Mayer is now at the wheel trying to right the ship. I’m not their CEO. Neither are you (unless you actually are Marissa, in which case, “Hi!”).

To be entirely clear and open: My initial reaction to the announcement was horror and anger. I am a supporter of remote working arrangements, and not only because I have one myself. I realize that there are good people everywhere and setting up an infrastructure to support remote workers allows companies to find the best people for the job, no matter where they’re located. However I also realize that without the appropriate infrastructure a remote working arrangement can be disastrous to a product and a company. It’s not for everyone. It’s not for every company.

Mayer is many things, but one thing she is not is a fool. Before this decision was announced she knew it wouldn’t play in Peoria. She knew there would be PR fallout. She knew the internet would cast her in the role of the wicked witch. She also knew a hell of a lot of other details to which none of us are privy.

This could not have been a swift decision, made in a moment of passion. Undoubtedly it was researched, calculated and discussed ad nauseam. Without access to that research and the discussions around it, none of us can know whether this is a good decision for Yahoo!.

I feel for the Yahooligans who now must uproot their working lives, I truly do. But I’m going to resist my impulse to pillory Marissa Mayer for her decision until I know more about what led to it.

Is it OK to apply at a company which doesn’t excite you?

A question which just arrived at my desk:

There’s a company that has some openings for what I do. I’ve met with a couple of employees from there and wasn’t wowed by what the place is doing. Is it OK for me to apply or would that be unethical?

To answer the question: Yes, it’s OK for him to apply and No it’s not unethical. There are two reasons for this.

First of all, this is only an application and—as we all know—submitting an application is no guarantee of getting an interview. Even with the contacts he’s already made at the company, it’s possible that his skill set won’t be what the hiring manager needs or that someone else better fits the bill. There is no risk to him in applying for the position.

Secondly, speaking with a couple of current employees of the company may not have given him the information he needs to judge whether he would enjoy working there. I applaud that he’s taken the time to sit down and chat with these people. Ideally this is a step everyone would be able to take in their job hunting process. It is, however, only half of a picture. The other half comes with the interview, when he’s able to speak with a broader range of people within the company, including managers who may be able to give him the lowdown on the exciting things planned for the team. It may be that once he’s spoken with more people he’ll decide that it’s a company and a project he really believes in, but he’s not going to know for sure until after that interview.

Applying for the position allows the company to decide whether he might be right for them. Interviewing allows both parties to decide whether they are right for each other. Both steps are purely fact-finding in nature. There’s no risk. There’s no commitment.

The question of ethics comes in when and/or if a job offer is made. If, after all of the steps in the interview process, this man is still not particularly interested in the company then it’s best for all involved that he not accept the offer. To commit to a job and a company which you don’t really want leads you to have a life of drudgery, which is bad enough, but it’s also disingenuous to your new coworkers. They assume you’re there because you want to be there and that you care as much as they do about the mission of the team. Accepting a job just so you can phone it in and collect a paycheck is a dishonorable way to make a living.

Of course there are always going to be exceptions to this rule. For instance, if you’ve been out of work for a long while and need any job to keep the children fed and the mortgage paid then, by all means, accept the job you are offered rather than await the one of your dreams. There will be time enough to trade up once you’ve provided some security for your family. Exceptions aside, it’s generally a bad idea to accept a job about which you feel, at best, ambivalent.

Many thanks go to this anonymous gentleman who sent this question my way. As a tech hiring manager it’s a relief to see people who really think and care about their careers.

On a related note: if any readers are looking for a skilled technical project manager who is as friendly as he is knowledgable, I may know someone in the market. Drop me a line and we’ll talk.

Four Questions To Answer For Every Project

Pause. Push away from your keyboard. Answer these questions:

  1. WHAT are you trying to accomplish?
  2. WHY are you trying to do it?
  3. HOW are you going to do it?
  4. WHEN will you know you’re done?

If you don’t have answers then you need to stop what you’re doing before you waste more time than you already have. You’re working from best guesses and assumptions and setting yourself and the project up for failure.

Managers, if you’re not prepared to tell your team the answers to each one of these questions then you’d better be prepared to miss deadlines, go over-budget and miss the target entirely on functionality.

The best way to improve the chances of success for any project—technical or not—is to do some sort of planning. It doesn’t need to take very long, but at the end of the process everyone involved with the project should know the answers to the What, Why, How, and When of the matter. Only then can you have some confidence that everyone is on the same page and only then say you have a project team.

Improving Perl’s New Programmer Outreach

I don’t think I’ve ever seen so much demand for programmers or programming training. In an economy that’s still recovering from the recession, the remarkably low unemployment rate among programmers plus the relatively high rate of pay is drawing ever more people to the industry.

You hear it over and over again: “I want to learn to program but need help to start.” If you search on the web you can find an abundance of “learn to program” opportunities. Most of the offline/meatspace ones use Java, Ruby or Python as the language of choice. I found none that use Perl, which I see as an opportunity the Perl community should pursue.

The availability of more beginning programming training provided in Perl would be beneficial both to the trainees and to the Perl language and community. As languages go, Perl quite easy to learn (or at least no harder than the popular alternatives). The basic programming concepts are fairly straightforward in syntax, sigils can help a neophyte to keep her data structures straight, and CPAN can enable a beginner to produce remarkably functional code in a limited amount of time. This leads to higher student confidence, since (as we’ve all experienced), creating something that works makes you feel good and want to keep learning more.

Perl, for its part, could benefit by using this training as positive propaganda to help dispel the negative brand image it’s developed and been unable to shake for all these years. Pundits and wags on Stack Overflow, reddit and elsewhere enjoy repeating the chestnuts that Perl is dead or is good only for scripting and parsing text, not for “web scale” projects. An influx of new programmers—trained on Perl and in the best practices recommended and used by modern Perl developers—would help to dispel these misconceptions, even if afterward they went on to use other languages.

As an example of an organization I think really does training right, I direct you to the San Francisco Ruby community. SF Ruby puts on a training session at least once a month. At least one of these, admirably, is focused on teaching women to program. In addition to training sessions, SF Ruby also organizes several hack nights each month, providing ample opportunities for newbies to mingle with more experienced programmers and get personalized assistance.

Now, in comparison, I’m going to pick on my local Perl Mongers group. SF.pm. Before I start, please be clear that I use SF.pm here only because it’s convenient and—as you’ll see in a moment—provides a dramatic comparison. The SF Perl Mongers are a great group of people. This is not intended as a slight against them or the organization. I simply wish to show that the Perl community could increase its outreach to new programmers.

I’ve compiled data on the number of training and hacking sessions organized by SF Ruby and SF.pm in 2012. All data is drawn from the Meetup calendars for each organization. A ‘training’ event is defined as anything focused on helping people learn the language and includes beginners’ hack nights, study groups, API office hours and more formal training sessions. A ‘hacking’ event, simply enough, is anything with the word ‘hack’ in the title.

Month SF Ruby SF Perl Mongers
  Training Hacking Training Hacking
January 1 5 0 0
February 3 9 0 0
March 1 6 0 0
April 3 7 0 1
May 2 6 0 0
June 4 5 0 0
July 8 4 0 0
August 7 6 0 0
September 4 5 0 0
October 2 5 0 0
November 2 5 0 0
December 3 3 0 0
TOTAL 40 66 0 1

The numbers, as you can see, are staggeringly different. That said, there is also a huge difference in the size of each of these communities on Meetup.com. SF Perl Mongers has a membership of 380 people. SF Ruby has 5588. This naturally affords SF Ruby more resources to provide these events but does not, I believe, excuse SF.pm for providing almost none.

SF Ruby deserves everyone’s attention and commendation for all of their work in training and outreach. It’s a model which Perl should look to emulate. While the resources of my local Perl community may not allow it to scale to the level of the 44 training and 66 hacking events put on by SF Ruby in the last year (nor do I think they should attempt to do so), I would hope those resources could allow for at least one training session every month or so and a newbie-friendly hack session every few weeks[*].

If Perl wants to show people that it’s alive and well it needs to be more active in public ways like this. Outreach to help introduce novices (especially minorities) to programming would go a long way toward dispelling the out-of-date image the tech community has of the Perl language.


[*]: Full disclosure: I am guilty of not offering to help SF.pm in this effort. This is an oversight I hope to correct. This post is the first step in that process. Back to reading.

Stop Hoarding Knowledge

Imagine a manufacturer who starts up a production line knowing that each time a worker reached a certain point in the process she or he would have to walk over to the foreman and ask for a critical piece of raw material. Naturally no company would ever do such a thing and if it did it wouldn’t be around for very long. This process would cripple productivity, dramatically increase the cost to produce each piece and send the time to market through the roof. The company would fail and we’d all agree that with a workflow like that it probably deserved to.

Despite that opinion, we in software development seem to think it’s OK to function under the same asinine workflow. Don’t believe me? Has your team or company ever had to…

  • …delay a deployment
  • …rejigger the development schedule
  • …miss a deadline
  • …lose a customer
  • …call someone in the middle of the night
  • …deal with under-trained staff

…because the only person with the knowledge is somehow unavailable?

In our field of software development we’re justifiably proud of the fact that we make things. We take a jumble of arcane symbols and arrange and assemble them in such a fashion that the end product improves someone’s life in some way. We manufacture tools and toys to fill needs for our customers. Software is our product and programming is our production line. Like any production line we need a stockpile of raw materials. Knowledge is ours, but I’ve yet to see a software team or company which doesn’t fit the ludicrous example I presented above. Each one has at least one person on the team who’s been there forever and knows the entire product inside and out, idiosyncracies and all. Each one has a resistence toward documenting this knowledge, making the raw materials available to everyone on the production line. And each one pays a terrible price in productivity and scalability.

This isn’t the way things have to be. This is the way we allow them to be. We have it within our power to fix this problem and all it takes is documentation and sharing of information.

When asked why a process or fact isn’t documented most teams will answer, “We just don’t have the time.” While, yes, it does take time to write these things up it takes considerably less than the time that’s lost when people are searching for answers. The lack of time is just a convenient cover for the real reasons things don’t get documented:

  1. People don’t understand the value of documentation. We need studies showing how much time and money is wasted chasing down undocumented answers. I’ve little doubt that managers would be aghast at the resources they’re flushing down the loo. Once the managers understand the value they can start communicating it to their departments and making knowledge documentation a priority for everyone on the team. This sort of thing has been done before in our industry. Years ago no one had time to write test suites for their code. Eventually people grew to recognize how invaluable a robust test suite is to a product and started including them in the software development process. The same thing needs to happen for capturing knowledge.
  2. Writing docs isn’t as fun as the other parts of the job. Let’s face the facts: the team would much rather be running the processes than writing about them. Tell folks to write something up in the wiki and they’ll drag their feet and come up with every excuse in the book to avoid it. For most people it’s just not fun. Ya know what else isn’t fun? Getting woken up in the middle of the night because you’re the only one who knows how to restart the webapp properly. Taking a couple hours out on a Friday afternoon to write up tips and instructions on a mission-critical procedure can be a good way to wind down toward the weekend and can help reduce immense amounts of stress later on when someone needs that information.
  3. People want to feel important. You’re it. You’re the one. You know every line of code, every method call, every peculiarity of server setup, every script or tool and all of their undocumented uses and command line options. You are the Most Important Person in the Company. Capturing all that you know and sharing it with everyone would be best for the team but—so you believe—it would drastically reduce your power and influence at the office. Here’s the truth of the matter: You’re a bully and no one really likes you very much. You’re holding your team hostage and they’re right to start resenting it. What you need to recognize is that what makes you important and influential at your job isn’t the knowledge you’ve amassed but the fact that you have the ability to amass it in the first place. Documenting and sharing that knowledge with the team isn’t going to reduce the amount of knowledge; it’s going to free up the time you used to spend answering questions so you can learn and create even more knowledge. It starts a cycle of knowledge generation with you at the center. Congratulations: not only have you made yourself even more important but now people like you. A lot.

There are some ways that managers can help reduce knowledge hoarding on their teams. The first thing they can do is start asking the team to include documentation in their time estimates. This helps show that brain dumps are as much of a priority as test suites. It also removes the excuse of not having the time to write up processes and procedures.

Another thing that can help is including documentation in the build process. If no documentation is found, the build should fail.

Also, managers can and should reward team members who make contributions to the internal documentation. Have a doc-a-thon. Hand out prizes. Do whatever you need to do to show the team that documenting processes and procedures is valued by your organization.

This isn’t something that you’ll be able to do overnight. It’ll take infrastructure, time and commitment. Undoubtedly you’ll fail and have to start again. Maybe more than once. But when you hire someone new and she’s able to hit the ground running and be productive in less than a week because she was able to find her answers in the wiki then you’ll know that all the effort was well spent.

‘Fail’ doesn’t have to be a four-letter word

Projects fail. Companies crash and burn. Screws fall out all the time; the world is an imperfect place. Just because it happens doesn’t mean we can’t do our best to prevent it or—at the very least—to minimize the damage when it does. As a matter of fact, embracing failure can be one of the best things you do for your organization.

First, let’s start with a few extreme examples of how things can go wrong…

A grim roll call

  • Despite warnings from many engineers, the space shuttle Challenger was allowed to launch with a faulty design on its oxygen tanks. The thinking, paraphrased, was “it will only be dangerous in these specific and unlikely circumstances…” Those circumstances, unfortunately, occurred.
  • A stuck valve, a signal light known to be ambiguous and lack of training led to the near meltdown of the TMI-2 cooling tower at Three Mile Island, to date still one of the worst nuclear disasters in history.
  • The Deepwater Horizon oil rig, off the coast of Louisiana, exploded in 2010 due to a number of factors: A cementing procedure was not followed correctly, allowing gas to escape from the well…on a windless day when a man was welding nearby.

Each of these tragedies has something in common: it could have been avoided. In each case there were known problems or procedures which were ignored and in each lives were unnecessarily lost. Each was the result of a compounding of small issues and oversights which unfortunately combined in just the right proportion at just the right (or wrong) time, small issues which were insignificant…until they weren’t.

Most likely lives are not on the line in your business but that doesn’t make your project failures feel any less personally and professionally devastating at times. Like these three tragedies, it’s likely that your failures can also be avoided.

Before suggesting how to avoid project failures, we should take some time to understand some of the factors which lead to them in the first place. There are many reasons why a project might fail, but two of the biggies are Culture and Cognitive Biases.

Cause #1: Culture

Do you like failing? No, nor do I. In general, humans do not like to fail. If things don’t go as expected we tend to get very cranky and sometimes irrational. This is unfortunate as failure is one of the most effective teachers we have.

Many project cultures are openly hostile to failure in any degree. In these cultures, backing or working on a project which doesn’t succeed as forecast can be very unhealthy for one’s career. Mistakes—even honest ones—are punished. This frequently leads to errors and oversights being swept under the carpet rather than being brought to light and addressed promptly. As we’ve seen in the examples above, ignoring the small things can have devastating results.

People in these cultures go to great lengths to avoid association with failure. Frequently, they’ll shelve a new and potentially profitable endeavor rather than take the chance it may fail. This risk aversion stymies innovation and company growth. As well, when a new project is pursued and is not going as planned the people associated with it will not report this underperformance. Doing so is often perceived (at best) as rocking the boat or (at worst) hitching yourself to the failing project. Therefore the project chugs along, devouring company resources, rather than being cut as it should be. All because of a culture which is hostile to failure.

Cause #2: Cognitive Biases

We all come with mental software packages which help us cope with life, allowing us to form judgments and take actions in situations both mundane and exceptional. Usually these work as expected and everything is just fine. But then there is the edge case, where the software doesn’t work quite as it should. This is a cognitive bias, “…a pattern of deviation in judgment that occurs in particular situations, which may sometimes lead to perceptual distortion, inaccurate judgment, illogical interpretation, or what is broadly called irrationality.

While many cognitive biases have been identified, there are four which most commonly contribute to instances of failure. You will all recognize them:

  • Normalization of deviance: The tendency to accept anomalies as normal. “Yeah, we get that error message all the time. Nothing’s ever blown up so we just ignore it now.”
  • Outcome bias: The tendency to focus on the outcome rather than the complex process leading up to it. “Sure, some things went wrong during the code deploy but the product shipped and isn’t that what really matters?”
  • Confirmation bias: The tendency to favor evidence which will support existing beliefs. “No, see, I know Windows would suck for this purpose because I read this article by RMS…”
  • Fundamental attribution error: The tendency to put too much blame for failure on personal rather than situational factors. “We fired the out-sourcers because they were hacks who didn’t know anything.” (Actual: the out-sourcers weren’t given the information and support required for success)

Suggestions

The possible causes for project failure are too varied and unpredictable to be able to avoid them all. However, given what we know it’s possible to minimize the impact and occurence of many potential failures.

First and foremost, it’s necessary to change the project and/or company culture so that it encourages people to report problems, no matter the size. The saying of this is, of course, much easier than the doing. Changing a culture is difficult but, at least in this case, very worthwhile. You can only solve those problems you know. The ones which go unreported end up costing dearly in money, time, effort and team morale.

Any cultural change must have honest and complete support at the highest levels of the organization. An effort like this can only succeed with commitment and leadership. Management must understand why the change is needed and lead by example. Only then will other members of the team feel comfortable enough to pull back the curtain and expose the problems which are holding the organization back.

Leadership should also learn to celebrate rather than blame those who bring errors, problems and failures into the light. Such actions should be seen for what they are: successfully preventing the waste of vital resources. Most people in tech have heard the phrase, “Fail early, fail often.” Few live by those words or reward those who do.

Many organizations will perform a postmortem on a project which has failed. While useful, these processes don’t even show half of the picture. The best way to identify issues which may put future projects at risk is to postmortem all projects, successful or not. Thanks to outcome bias, a near-miss will look like a success and typically will then escape a postmortem scrutiny. This leaves a raft of issues unidentified, ready to appear and compound in future efforts.

But even this won’t help you identify potential problems when you need to. While locating and anaylzing them after they’ve occured is, of course, valuable, wouldn’t it be better to spot them before they become real problems in the first place? Part of the cultural changes which must occur is an organization-wide commitment to spot and report potential problems as quickly as possible. This is more likely to happen if people are asked to use simple and familiar tools to make the reports. Rather than re-invent the wheel or roll out yet another tool for team members to learn, I suggest that the organization’s existing issue tracking system be used for this purpose. After all, while these problems may not be software bugs they are issues which need resolving. Simply create a new database/project/what have you in your issue tracker then open it up to everyone in the organization. It does little good to report issues if people are not able to see them, after all.

Reporting the issues isn’t enough. If people believe that the reports go into a black hole, where they are never viewed let alone addressed, they will stop creating them and you’ll be right back where you started. These issues should be analyzed to determine the root causes for them. When resolving a problem, all too often people will scratch the surface and leave it at that. “This build failed because $team_member didn’t follow the procedure.” That’s not a reason for the problem; that’s a symptom. The true reason is buried somewhere in there. Why did $team_member not follow the procedure? Is the procedure wrong? Was there some exception? Was $team_member getting undue pressure to work faster, causing corners to be cut? Did $team_member not know that the procedure exists or that it should be used in this situation?

The statement, “This build failed because $team_member didn’t follow the procedure” is a presumptive and possibly incorrect placement of blame. As you can see, it is much more likely the case that the system within which $team_member is working is flawed than that this person is incompetent. The urge to point fingers is strong, but a vital part of the cultural change required is to discourage laying blame without doing analysis. Take an hour to speak with everyone involved to figure out the true underlying reasons for the error. Never punish but in the cases of gross negligence or repeated incompetence. Let people know it’s not only OK to make mistakes, it’s entirely natural to the human condition. Not only will you find that people start reporting and addressing issues before they become real problems, you’ll also find that team morale improves as people realize that they’re respected and trusted.

Once you’ve identified the underlying reason(s), make sure to correct and communicate. It does no good to analyze a problem if you’re not going to do something with what you discover. Fix the procedure. Provide additional training. Add a new Nagios warning. Modify the schedule to allow time to do things right. Bring in a specialist. Do whatever needs to be done to be sure the issue never happens again. And, of course, it’s vital that you communicate not only the necessary fixes but why they were necessary in the first place. Team meetings are a good way to do this but don’t forget that issue tracker. Any resolution should be captured here for posterity. Just like adding comments to a complicated piece of code, Future You will be grateful if you document both the problem and its solution.

Other Resources

As I mentioned above, there is a myriad of ways in which a project can fail. This article only starts to address that and some of the things you can do to prevent or minimize damage. If you’re interested in learning more, here are some of the resources I’ve stored up on the subject. Most of them are from HBR, so you may need to pay to access them. You can also probably get them from your local public or university library.

Common Resume Mistakes

I’ve been hiring in the tech industry for the past ten years or so. In that time I’ve looked at hundreds—if not thousands—of resumes from people applying for a variety of positions on my teams. While the positions may differ, the majority of the resumes share the same quality: they stink.

See, here’s the thing: While I’m a hiring manager it’s not the only thing I have to do with my day. There are staff meetings and progress reports and design meetings and scheduling development and any of the myriad of other of tasks which land in the lap of a software engineering manager. By the time I carve out an hour to sift through all of the resumes I’ve received for an open position, the average resume crosses my desk in less than 30 seconds. If you can’t make a good impression in that amount of time then, I’m sorry, but I need to move on. I have too many other constraints on my time.

Therein lies the problem with the average resume: the average part. It doesn’t stand out from the pack. The same words, used in the same way, conveying the same lack of information.

Are you average? No? Then why in the hell is your resume? Let’s fix that…

What follows are tips for how to make your resume stand out from that big, tall stack through which I have to sort every time I have an open req to fill.

  • Don’t get fancy with the design. Unless you’re a graphic designer, please stick with a more traditional formatting for your resume. Anything else is at best jarring for the hiring manager and at worst actively distracting. The most important part of your resume is the content, not the layout. As with any good design, the layout and formatting should take a back seat to the content it supports. It should enhance the content, not be the focus of attention. This means you should probably stick with black on white and use minimal (or no) images. In truth, this will probably help to get your resume more noticed than a tightly designed document. Many companies use online job app services now. Those services require you upload a resume file, which they then—for better or worse—scan for keywords. A beautifully designed ‘Shop job of a resume will not parse. No parsing: no keywords. No keywords: no attention for your resume. You don’t get hired.
  • Order by most important/impressive to least. Remember that 30 second skim I mentioned above? When listing out your experience, your resume is more likely to leave an impression in those few moments if you organize it so the most important or impressive bullet points are at the top of each section. This is where my eye is most likely to alight during my skim so logically I’m most likely to pay attention to things I see here.
  • Do not include a picture of yourself. I cannot recommend against this strongly enough. Your resume is not about how you look. It is about what you can do. Including a headshot removes attention from your accomplishments and places it squarely on that photo of you. Furthermore a resume which includes a headshot puts me, as your hiring manager, in an incredibly awkward position. Suddenly I’m opened up to the possibility of accusations of not hiring you because you’re female or overweight or older or younger or have piercings or appear to follow a particular religion or are of a certain ethnicity… Job seeking is hard enough. Don’t cripple your chances by making the hiring manager feel uncomfortable. Instead, use that room on your resume to tell me more about how great you are.
  • Expect to be Googled and make it easy for your reader. Oh, don’t look so surprised. Yes, people who look at your resume will be Googling both you and any company or organization you list on it. If you recognize this and make it easier on them by including URLs to everything then you’ll leave a very good impression on your reader. Also, if you have any pseudonyms by which you’ve done relevant work (for instance, many in the Open Source community may be better known by a handle than the name on their birth certificate), make sure to mention that name somewhere on your resume. I can’t be impressed by your accomplishments if I can’t find them.
  • Stop being cliché. “People person.” “Team player.” “Responsible.” “Motivated.” “Hard worker.” Stop it. Just stop it. None of these phrases mean anything to a hiring manager. Even if they once did, they’ve since been so diluted that they’ve been washed clean of any meaning. Don’t describe yourself with empty adjectives like everyone else does. Do it by listing all the cool things you’ve done.
  • Be specific. Don’t tell me “Managed a project for a large client.” Tell me what you did—specifically—while managing it and just how large that client was. Tell me what you did and why I should care that you did it. Don’t say, “Organized company events.” That tells me nothing. It could have been a birthday party for a group of five or it could have been the 30th Anniversary Bash for a company of three thousand. Be specific. At no point should your reader be left wondering, “Well, what’s that mean?”
  • Ignore the “only one page” crap. And while we’re on the subject of specificity, don’t leave out details just because you want to keep your resume on a single page. This precept is an archic throwback to the days of analog resumes. Newsflash: we’re digital now. One of the perks of going digital is that no one cares if your resume is more than a page long. Everyone is just going to skim it on their computer or device anyway. Unless someone’s wasteful or inefficient, odds are good that they won’t be printing out your resume until/unless you reach a later stage in the process (like an interview). That said, practice moderation in all things. Just because you now have license to exceed a single page doesn’t mean you need to send a novel. Don’t forget that the hiring manager’s time is at a premium. Don’t waste it. A maximum of a full two pages ought to be plenty of space for you to say what you want without overwhelming the nice person who has to read the thing.
  • Numbers Numbers Numbers. Quantify as much as possible. You didn’t just help land a client. You helped land a $2 million client. You didn’t just improve processes. You streamlined a process which reduced client response time from two days down to four hours, retaining $500K in business and saving an average of $150K in staff costs. This goes hand in hand with the edict to Be Specific. If you currently don’t have numbers then start collecting them.
  • Update early and update often. When I say you should start collecting numbers, I mean you should do it on your resume itself. Most people only update their resumes when they’re about to start a job search, and that’s a mistake. By the time you start editing the file several years could have passed since the last update. That’s several years of memories you now need to dredge. What are the chances you’re going to remember everything you’ve done in that time, let alone numbers associated with your accomplishments? If you answered, “Pretty bad” then you win a gold star. If you want your resume to best reflect your skills and abilities, you should update it frequently to be sure it includes your latest and greatest accomplishments. I have a repeating Remember The Milk task to remind me to update my resume every month (or at least consider doing so).

    Once you hear this tip it’s one of those “duh” moments, but it’s not something most people would usually think of on their own, myself included. I first heard this tip to update your resume regularly from Andy Lester in his excellent book Land the Tech Job You Love. I highly recommend it for all job seekers, technical or otherwise.

  • Save that sucker. You can’t update what you can’t find. Many people end up having to rewrite their entire resume from scratch each time they need to update it because they’ve lost the file for some reason. Do yourself an immense favor: use a version control system for this and all other important files in your life. Version Control: It’s not just for code, dammit. I use and recommend Github for this purpose. Not only is your file safe and backed up, it’s also stored offsite and safe in case of disaster or harddrive crash. Truthfully, what I have is a git repo in a Dropbox directory, so in my case the file is well and truly backed up in several locations.

    Also recommended: if you use Github, shell out the minimal monthly charge for private repositories and use that for your resume. No one wants to get a pull request on their own resume.

Hopefully these tips will help improve the chances of your resume turning heads the next time you’re looking for a new job. Good hunting!

Managers: It is NEVER OK to be a jerk

Earlier today I had a conversation with a friend. She had just been chewed out by her manager. It seems my friend had let a typo slip into some copy. Normally a typo wouldn’t be that big of a deal, but this one was in the price for an item. Customers saw the typo’d price, contacted people to make a purchase and were disappointed to learn that the price was incorrect. They complained to the manager. He took it out on my friend and her coworker. I believe the phrase my friend used was something about being glad she’d managed not to cry when her manager was yelling at them.

From where I stand, there is nothing correct in the way this incident was handled. There is never a good reason to be a jerk. There is never a good reason to bring an employee to the brink of tears. And, because it bears repeating: There is never a good reason to be a jerk.

While I’m not familiar with the intimate details of the situation in question, I’m going to hazard a guess at a healthier, more professional and more productive way to approach it…

  • Be open with your customers. Unless you’ve cornered some freaky market about which the rest of us have no knowledge, your customers are human. If an error is discovered, openly and honestly notify them and apologize for it (even if they haven’t approached you about the error). They will understand that mistakes happen and appreciate you proactively approaching them about it. Odds are they’ll forget about the error or, if they remember it at all, it will be with a positive feeling thanks to how you handled it.
  • Figure out how the error occurred. A harmful typo got into the wild? A product flaw? Site crashed? Complaining about it and attacking people does not fix the problem. Instead, channel your energy and the energy of your team into locating when, where and how the error crept in and how it was allowed to be exposed to the customers. THIS DOES NOT MEAN FIND SOMEONE TO BLAME. By looking to point fingers and assign blame you make everyone uncomfortable and set up barriers to people revealing errors in the future. While, yes, a human made the error that does not mean (s)he is to blame for it. If there is proof that the error was a willful effort by someone to cause damage then, yes, there is blame. But otherwise it’s just what it is: an error. An error which can be prevented. To whit…
  • Set up a process to prevent the error. Even something as “simple” as writing and publishing copy involves a complicated set of processes and procedures. If there is an error then odds are good that the problem is not with the person but with those processes. Fix that so that the error will not happen again.

Mistakes happen. It’s a part of life and therefore a part of business. Embrace them and learn from them. Don’t pillory your people. Don’t be a jerk.

Increasing the Role of OSCON in Community Education

I recently returned from OSCON. It was, as usual, brilliant. My talk—a part of Business Leadership Day—was well-received, which is always validating. As I perused this year’s schedule I was pleasantly surprised by the number of community-related[1] talks. Nine! Nine talks about community!

My first thought was, “Attention to community! My, but isn’t this an encouraging trend!” This is, of course, an assumption. One data point does not a trend make.

But twelve of them might.

I delved into the OSCON schedules as far back as I could easily access them: 2001. The 2000 and 1999 schedules are undoubtedly available somewhere but seeking them out became a game of diminishing returns so I’ve set them aside.

My results can be found in this Google Spreadsheet, but in summary:

As you can see, the first several years tracked contain no community-related sessions whatsoever. Things pick up a little with a single session in 2005 but then take a large leap to five sessions in 2006. 2007 was lackluster, with only two sessions. But then! 2008! Eleven! Wow… Could it be that Open Source is starting to publicly recognize the value of strengthening its communities? Oh, wait…no, no it’s not. Or at least not consistently, judging by 2009-2011. The community-related sessions in these three years together totalled those in 2008 alone. And then we get to 2012. I exclaim again: Nine sessions! It’s no 2008 but it’s still fairly impressive.

That said, there is definitely not a trend here. But wouldn’t it be nice if there were?

One of the greatest strengths of Open Source is the communities which form to create and support the technologies. While the technologies themselves are undoubtedly very important the communities which build them have been given short shrift. Only 2.875% of all of the talks in this year’s OSCON [2] were at all related with community issues. Considering the undeniable importance of people and community to the success of any Open Source project it would be great to see this percentage start to creep up over the next few years.

Nota Bene: None of this is meant to diminish the work of the people at the Community Leadership Summit, which meets each year immediately before OSCON. It’s a valuable asset to Open Source, but typically it’s attended by those who already understand the importance of community. It necessary to reach a broader audience.

What I would like to see is a gradual increase in community-related sessions at OSCON itself (which by design receives a far higher attendance than CLS) to help raise awareness. Lately there has been a lot of attention given to the importance of things like Codes of Conduct for conferences. I would like to see that attention to the human side of Open Source to get more traction beyond the confines of conference administration, reaching into the communities themselves. OSCON is where Open Source comes to play and to learn, to see and be seen. When a large chunk of the community is lodged within your doors it seems the perfect opportunity to teach those people the meaning of the human side of the community of which they’re a part.

You’re never going to have strong, diverse communities if you don’t start educating everyone what a strong, diverse community is. I wholeheartedly applaud OSCON’s efforts to do so in 2012 and I hope that it continues to carry the flag and leads the charge with more even attention to community matters in future schedules.


Footnotes
[1] By “community-related” I mean talks about building and strengthening communities, not those simply about personnel or project management. [back to reading]

[2] This percentage will, in fact, be smaller. It does not include the sessions from the Education track, which don’t appear on the 2012 OSCON schedule menu. [back to reading]