The internet is an interesting beast. It offers privacy and anonymity, yet at the same time gives us plenty of opportunity to pull those curtains aside and become celebrities in our own right. In the world of community-shaped brands, overnight popularity and popularity as fickle as a mouse click, we are given plenty of opportunities to make a quick buck, win a quick victory, be a featured celebrity or make a quick contribution.
The only thing that seems to be tying all these things together on a consistent basis is speed. Contribution needs to be fast, results have to be instant, and if something doesn’t catch our attention within our rapidly diminishing attention span, the audience moves on to the next best thing. Things with real staying power are growing fewer and fewer, and the last thing that seems to have any kind of tenacity is reputation.
Let’s face it: Employers, clients, friends and colleagues will search for our names online, and an even sightly determined sleuth will be able to uncover a substantial amount of our history. As a result we each have to be very careful about managing our online activity, and in particular our professional reputation; Even the slightest negative comment found in a search result will raise unwanted eyebrows, and raised eyebrows mean lost interviews, bids, and job opportunities.
To that end, I’ve tried to list a few rules and guidelines that I follow. I’m hardly perfect at them, and there are exceptions for each, yet overall they are things that I’ve learned that are absolute must-haves in order to properly manage your reputation as a developer.
Rule #1: Don’t misrepresent your skills.
The first and foremost rule is not to lie about what you’re capable of. This can often be tricky, because skill and competence are largely subjective in nature, and the title “Developer” can span anything from a college dropout with a PHP tutorial and an Ego to a 15 year assembly veteran who knows how to read a core dump.
This rule is especially hard to follow when you’re a junior level developer, trying to break into an industry, or a freelancer short on paying projects. As the bills start piling up the pressure to enhance a resume increases, and there are many ways of spinning a phrase to make it say one thing but mean something completely different.
Consider the consequence: You’ve engaged in some creative embellishment and finally landed a gig. You start working, and your lack of skill comes to light. Now not only have you lost your paycheck, but you have also demonstrated that you’re wholly untrustworthy and left a sour taste in your employers’ mouth. This then begins to cascade: You may be asked about it in interviews, they might do some background checking, someone might make an idle comment on a blog or in a discussion at a local professional group and suddenly you’re working at McDonald’s just to make ends meet.
In contrast, honesty about your skills will properly frame your employers’ expectations, and give them a good sense of how to compare you against other candidates. You will definitely lose some opportunities, but now these opportunities will either have been outside your skill set (with all the issues listed above), or for a boss who’s expectations aren’t in line with the project scope (whom you probably didn’t want to work for anyway).
Rule #2: Credit where credit is due.
If you write code, you deserve credit for it. If someone else wrote it, they deserve credit for it. This is not rocket science, and falls neatly under the Golden Rule. Even so, it is very easy to take full credit for a particular body of work, especially if you were the sole developer on the project.
This is perhaps the hardest rule to give proper shape to, because while we all appreciate the work of developers whose libraries make our jobs easier, it’s difficult to figure out exactly when to show that appreciation. Do I send an email thanking that developer? Do I put his name in the documentation? Do I blog about it?
I personally err on the side of being reciprocal. Whenever I take or receive credit for something, I make sure to note everyone who’s made a substantial contribution. This doesn’t always work- for instance I can’t go into too much detail on my recent work on HP Print Studio, both because of client agreements and internal policy (As much as I’d like to), and you might have similar restrictions.
Rule #3: Own up to your mistakes.
Risk is an everpresent part of projects. The risk of not meeting the launch date, the risk of hiring the right skill set, the risk of a client that won’t pay their bills or the risk of your project manager being suddenly hit by a bus. Many of these are not under our control, and yet even for those there are ways of mitigating the damage, usually involving project contingency time and exit clauses.
From a developer’s perspective, the three risk factors are (broadly speaking) the risk of not having the right resources on the project, the risk of improper time estimates, and the risk of development mistakes (frequently referred to as bugs). The first of these is largely an issue of staffing, so doesn’t affect us directly. The other two however are factors of our skill as developers, and can frequently be subject to errors of judgement.
The second to last thing a project needs to deal with when the pressure is on is a long, extended blame game that wastes everyone’s time. The last thing a project needs is a lurking mistake that’ll blow up in everyone’s faces just because someone didn’t have the guts to raise a red flag.
If you screw up, admit it. That way everyone is up to date, can plan for the extra time, and though you might lose some face (though you’ll gain some points for being honest) in the long run it is far preferable to the alternative.
Rule #4: Ask for help.
One of the hardest things for a technologist is to admit that we don’t know how to to do something. We’re asked to complete projects of staggering complexity, and after a while adopt a sense of infallibility that lends itself towards making extravagant promises. This pride cometh before the fall, as sooner or later we make extravagant promises in spite of having no clue of how to implement a request, and a single broken promise can derail an entire project.
We are usually the first to know whether our promises have landed us in hot water, and the hardest thing to do once this realization hits is to ask someone else for help. I for one am far more likely to pull ridiculous hours than admit that someone else might be better qualified to solve a problem, and the resulting billing mayhem has to be dealt with by someone.
Here’s a secret: People like to feel important, and asking someone else for help is doing exactly that. What for you is a pretty tight situation is to them a casual request that makes them feel good about themselves, and that goodwill may even get you some pro-bono help. It could be that they have that one remaining piece of information you need to get the job done, or maybe they can point you at the shape of the solution so that you can fill in the blanks. Alternatively if they don’t have an answer, they might know someone who does.
One cautionary note: There is a fine difference between asking someone for help and relying on them.
Rule #5: Respect your team
Lets face it, we’re an independent bunch, especially those of us who are freelancers. The teams we work on don’t usually include a full complement of project contributors, and it’s often that we have to take on the duties of other Developers, Information Architects, Designers, Testing and in some cases even Account and Project Managers. Yet even when we’re burning the candle at both ends and the other team members aren’t available, we have to remember that we do not work in a vacuum, and there are others whom we can rely on.
Everyone has their part, and each specialization is there to support and complement the goals of the project. While it might be tempting to assume that you can take on the duties of a Designer, chances are he has experience, nuanced training and a method of thought that you simply cannot compete with.
Lets take the case of Design vs. Development as a case study, because for flash developers like myself this is one of the blurriest lines. Here, a designer has set a vision for a particular project, and you are asked to implement it. In the course of development it turns out that there are several pages/screens that have not been accommodated for, but you can easily extrapolate something from the existing comps and maybe add a bit of personal flair. If you do so without the designer’s input, you are bypassing him altogether and effectively telling him you can do his job. If instead you inform him of the oversight and ask him whether you should do that, you’re deferring authority to him and acknowledging his place and responsibility on the team. In short you’ve just turned a potentially volatile situation into a team bonding experience.
That about sums it up. I’ll probably keep this list updated as I encounter more things, but these five should get you off on good footing. Remember, your reputation is as valuable as your paycheck, because in the long run that’s what will define where, what, and how you work.