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]

Program Like a Pixar Story Artist

A friend recently tweeted a list of story basics from Pixar Story Artist Emma Coats. These basics are some of the story-writing guidelines Emma has learned from her colleagues and they’re pure gold for writers.

As I was reading the list I was struck by just how many of the items on her list–with just a little modification–apply to programming as well. It’s all creative work. It’s all writing.

Story Code
#2: You gotta keep in mind what’s interesting to you as an audience, not what’s fun to do as a writer. They can be v. different. You gotta keep in mind what’s interesting to you as a user, not what’s fun to do as a coder. They can be very different.
#4: Once upon a time there was ___. Every day, ___. One day ___. Because of that, ___. Because of that, ___. Until finally ___. In order to ___ as a ___ I want to ___. Given ___ when ___ then ___.
#5: Simplify. Focus. Combine characters. Hop over detours. You’ll feel like you’re losing valuable stuff but it sets you free. Simplify. Focus. DRY it up. Hop over detours. You’ll feel like you’re losing valuable stuff but it sets you free.
#6: What is your character good at, comfortable with? Throw the polar opposite at them. Challenge them. How do they deal? What are you good at, comfortable with? Throw yourself at the polar opposite. Challenge yourself. How do you deal?
#7: Come up with your ending before you figure out your middle. Seriously. Endings are hard, get yours working up front. Come up with your test before you figure out your method. Seriously. Passing tests are hard, get yours working up front.
#8: Finish your story, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time. Ship your code, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time.
#10: Pull apart the stories you like. What you like in them is a part of you; you’ve got to recognize it before you can use it. Pull apart the code you like. What you like in it is valuable; you’ve got to recognize it before you can use it.
#11: Putting it on paper lets you start fixing it. If it stays in your head, a perfect idea, you’ll never share it with anyone. Put it ‘on paper’ lets you start fixing it. If it stays in your head, a perfect idea, you’ll never share it with anyone.
#13: Give your characters opinions. Passive/malleable might seem likable to you as you write, but it’s poison to the audience. Be careful with your users’ options. Abundant options may seem good to you as you code, but it’s poison to the product usability.
#16: What are the stakes? Give us reason to root for the character. What happens if they don’t succeed? Stack the odds against. What are the stakes? Know the reason for the feature. What happens if it doesn’t work? Handle this gracefully.
#17: No work is ever wasted. If it’s not working, let go and move on – it’ll come back around to be useful later. No work is ever wasted. If it’s not working, let go and move on – it’ll come back around to be useful later.
#18: You have to know yourself: the difference between doing your best & fussing. Story is testing, not refining. You have to know yourself: the difference between doing your best and fussing. Coding is iterative.
#19: Coincidences to get characters into trouble are great; coincidences to get them out of it are cheating. A hack to get the test to pass is great; a hack which ends up in production is cheating.
#20: Exercise: take the building blocks of a movie you dislike. How d’you rearrange them into what you DO like? Exercise: take the building blocks of some code you dislike. How would you rearrange them into what you DO like?
#21: You gotta identify with your situation/characters, can’t just write ‘cool’. What would make YOU act that way? You gotta identify with your users; you can’t just code ‘cool’. What would make YOU use this feature?
#22: What’s the essence of your story? Most economical telling of it? If you know that, you can build out from there. What’s the essence of your feature? Most economical coding of it? If you know that, you can build out from there.

Look at the world around you and what people in other fields are doing and you’ll be amazed at the lessons they can teach you.

Open Source: Why Can’t We Just Make It Easy On New Contributors?

As an Open Source advocate I’m frequently asked to which projects I contribute. My answer is typically, “None right now.” Why is that? There are a few reasons but they mostly boil down to:

  • As someone who does not code often (or enjoy it immensely) I do not feel welcome.
  • It’s an opaque process.

For now I’ll set aside the first reason to focus on the second: the process is opaque.

From my point of view, there is absolutely no excuse for this. Wikis, CMSs and cheap hosting all make it abundantly simple to offer plentiful guidance to new contributors, yet somehow that guidance is rarely provided. New contributors must delve and divine and guess and pester in order to figure out where to start. It’s almost as though the community does this intentionally as a sort of rite of passage for new members. “If you can figure this out then you’re smart enough to become One Of Us.” This is incredibly arrogant and exclusionist.

Why can’t we just make it easy on people? Why can’t we spend a few hours writing some documentation and tutorials up front, guiding newbies along the community-accepted path of contribution? Long time contributors may find the concept of spoon-feeding new members offensive but doing so will not only bring in more people to the fold it will also raise the quality of the contributions from the get-go.

To demonstrate how a project can make it easier for new contributors I’m going to use the Perl project. This is not because it’s such a bad example of how to do things (it’s pretty good, really) but because I’m fond of Perl and want to make some suggestions on how to make it even better. Also, I know that the Perl community is generally friendly and open to ideas on improving community involvement. That said, most of the suggestions are more generally applicable to all Open Source projects.

First of all, kudos to Perl for having a dedicated Get Involved link very prominently displayed there at the top of every page of Perl.org! This visibility is a testament to the importance of contributions and contributors to the Perl community. Involvement is key for them and they put it front and center, right where it deserves to be.

However after that things get less obvious. The site is clean and well-designed, which is a pleasant change from many project pages, but this page is essentially just a list of bullet points with no context or meaning. For instance, what would I as a new contributor be expected to do with the Bugs, testing and reviews section? Is this for reporting bugs (yes) or fixing them (not so much) or…? What is meant by “testing?” Since I pay attention to happenings in the Perl community I know that this means automatically reporting test results to the imminently cool and useful CPAN Testers when I install new CPAN modules, but what if I were entirely new to the Perl world? I may think that “testing” implies a lot more hands-on work, perhaps testing new commits to the core language. It’s not obvious and it really should be.

The tagline of this page is Whatever your skill set or level you can get involved… While I believe this must be true, speaking as a mostly-non-coder this page does not make it obvious how I could get involved with the Perl project. Are there simple bugs I could fix (and if so, how)? Maybe documentation that needs writing/editing? How about project management? Ticket review? Marketing? Event organization? Donations? Not only are these subjects a good way to capture the less technical users and supporters of your project, they’re also a brilliant way for the new coding contributors to get a feel for the project and up to speed on the processes it uses.

Here’s a quick and dirty first draft of a version of this page which would be more useful to new contributors:

Whatever your skill set or level you can get involved…

Community

Some say CPAN is the strength and heart of Perl, but they’re wrong. The people are the heart of Perl.

Getting Started

Ready to dive in? Here’s how to do it!

Everyone
  • Contributor FAQ Every project has those questions which come up repeatedly. Collect them and their answers to help remove the barrier to entry.
  • An overview of the processes used for Perl. Link to another page. Key for everyone to know the steps in the process, not only so they’ll know what to expect but also so they’ll know better what language to use when asking for help.
  • Where to go for help. While this should be an element of every bullet point here, it also should be aggregated on a single page for ease of use. Broken down by subject. Include names whenever possible (mentors would be awesome and heroic). New contributors are more likely to ask for help if it’s obvious there’s a real person at the other end.
  • Where to find the documentation. Link to another page. List every form of docs that exist. Keeping all this in one place drastically reduces frustration for new contributors.
  • Where to find the code. Link to another page. Not just where to find it, but how to get a copy and, if you wish to commit, how you’d go about doing that (including expected code style).
Non-Coding
  • Review and rate – the CPAN modules you use.
  • Send automatic reports to CPAN testers every time you install a new module.
  • Review trouble tickets. Link to a page describing the process, requirements and expectations for reviewing project trouble tickets. Ideally will include a link to a list of tickets in need of review.
  • Write or edit documentation. Link to a page describing the process, requirements and expectations for writing or editing project documentation. Ideally will include a link to a list of documentation tickets.
  • Translate documentation. Link to a page describing the process, requirements and expectations for translating project documentation. Ideally will include a link to a list of translation tickets.
  • Organize or Volunteer at an event. Calendar/list of events (locations and dates), assistance required and whom to contact for more information.
  • Donate. Link to a donation page and/or page detailing whom to contact to give a donation.
  • Have another idea how you could help? Contact us! Link to the correct contact information.
CPAN
  • Best Practices for coding for CPAN.
  • How to report a bug for a CPAN module.
  • How to contribute a fix for a CPAN module.
  • How to contribute a new CPAN module.
  • Contacting CPAN module maintainers and what to do if they don’t respond.
Core

Perl6

Want to learn more about Perl6? Have a look over here! Anticipate the question rather than forcing it to be asked or searched for.

Again, this is just a quick pass at a possible Contributors page, but as a non-contributor it’s much more inviting than the current, sparse version. I can easily look at this and see my options and the methods for performing them.

Granted, there is a lot of organization and writing which would need to be done for a page like this to work. Believe me, I know it’s not easy getting all these ducks in a row. That said, I strongly believe that any project which goes through the steps necessary to make it much easier for new contributors to join will find its quality and reputation improving by leaps and bounds. It’s an effort very much worth making.