Entries Tagged 'Becoming a Better Developer' ↓

This is part of an ongoing series centered on becoming a better software developer. For other posts in the series, see the Becoming a Better Developer heading in the right navigation.
–
In the book Joy at Work, the former CEO of an $8 billion energy company describes an experiment where he allowed a business development group to determine their own salaries over the course of two years.

The first year everyone chose their own salary but the numbers were kept private. The result was that the best people paid themselves too little, and the average and under-performing people paid themselves too much. This is in line with Paul Graham’s quote: “…people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.”

The next year the company set a total budget for the department’s salaries and repeated the exercise, except this time all of the employees had to submit their proposed pay to their colleagues for comment - not to be approved or rejected, simply for comment. When everything was said and done the department was only slightly over budget, and upon closer inspection the company determined one person was highly overpaid based on the salaries of his colleagues with similar abilities. This person had not listened to the feedback of his co-workers who had told him he was overpaying himself. After being informed of this, he reduced his salary and they met their budget.

What does this tell us?

First, people who think they are underpaid are probably not very good at what they do.

Second, people who think they are overpaid are probably pretty good.

Finally, the people you work with are the best judge of your abilities. Yes, even better than you.

If everyone at work thinks you’re abrasive, it’s time to take a serious look at your interpersonal style.

Have you ever seen yourself give a speech or teach a class? Every time I see footage of myself I’m shocked at how I look when I’m in front of a group. I’m appalled at my posture and nervous ticks I didn’t know I had.

Your colleagues are the video camera that can see your ability to write code, deal with stress, communicate your ideas, write clearly, and a whole slew of other things that are critical to our jobs as software developers. If you’re not using them as a resource you are overlooking a powerful tool that can help improve both your technical and non-technical abilities.

The moral: If you are genuinely interested in improving as a developer, ask your colleagues what they think of your abilities. Not just your development skills, but your writing skills, interpersonal style, ability to deal with stress, etc…

Then ask them again and tell them to be honest.

There comes a point in every person’s career when we have to offer criticism of someone else’s work. For software developers and managers this can be especially difficult since most programmers view the software they write as an extension of themselves, and take criticism of that software very personally.

We all know how to criticize, but the question is how to criticize well.

Be Specific
The #1 rule of good criticism is be specific.

In Freaknomics, Steven D. Levitt examined phrases in real estate listings that had a positive correlation on sale price (meaning a higher sale price), and ones that had a negative correlation (lower sale price). The results were as follows:

Higher Sale Price
granite
state of the art
corian
maple
gourmet
new
move in condition

Lower Sale Price
well maintained
fantastic
spacious
charming
!
great neighborhood
wonderful
immaculate

What you’ll notice is that higher sale prices resulted from being more specific. Tangible, real things like granite, corian, maple, new, outweigh ambiguous, possibly made-up things like fantastic, charming and wonderful.

And so it is with criticism. Telling someone their code is “total crap” is not helpful. Telling them they misspelled two variable names, have several place where they’ve repeated code, and they need error handling in all of their methods is much more helpful. It not only allows them to improve their current code, but perhaps it will help them out in the future, as well. They still may get mad, but that’s up to them.

It certainly takes more time to itemize mistakes, but it’s worth it.

Criticize the Code, Not the Person
If someone writes crappy code, talk about the code, not about the person’s ability to code. If someone doesn’t meet a deadline, talk about how that affected you and what needs to happen in the future, don’t talk about how the person is a complete slacker (at least not the first time you discuss it). Doing so will help keep the conversation less personal.

Be Constructive
Without much effort at all I can give you a list of negative things about Los Angeles: traffic, smog, too many people, and a distinct lack of trees.

I could also give you a list of bad things about the internet: spam, viruses, poorly-designed websites, and pornography. Just because I can point out a ton of negative things doesn’t mean that the internet is not worth your time, and doesn’t mean you shouldn’t live in L.A. For all the negatives there are tons of positives to outweigh them, at least for the 10 million people who live in L.A. County, or the 1 billion people on the internet.

It’s easy to be negative. It’s easy to come into a situation and complain. It’s easy to point out the flaws in everything (have you ever read the comments on Digg or Slashdot?). If you don’t have a suggested solution in mind it’s going to be difficult for people to respect your opinion. Someone who complains often will be ignored rather quickly.

Constructive critisism is helpful; venting just pisses people off. Before you criticize something stop to think if it really matters to you and needs to be improved, and make sure you’re talking to the person who can do something about it.

From my new article How To Burn $6,540 a Week: Indecision and Software Development:

“These kinds of decisions come up constantly during development. Let’s say we have five developers working on a project and between them we encounter 10 in a week . If a monkey flipped a coin he’d choose the right answer half the time. Giving the manager the benefit of the doubt, let’s say he chooses correctly 60% of the time. 6 out of 10 times we break even, the other 4 we lose $420, for a total cost of $1,680 per week.

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week.

Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That’s a difference of $6,540 per week.

Give that a few minutes to sink in.”

You can read the full article here.

From my new article Nailing Your Technical Interview:

“People are strange. I’m not just talking about your Uncle Cedric with the hairy feet and stale piece of toast with the image of Tina Turner that he swears will grab six-figures on eBay, I mean it more in terms of our mental capabilities. Think about how brilliant we are compared to a tape recorder, but how hopelessly inaccurate our ability is to remember a conversation.

Ask any police officer who’s interviewed six eyewitnesses and he’ll give you six different accounts of the same event.”

Read the complete article here.

People are strange. I’m not just talking about your Uncle Cedric with the hairy feet and stale piece of toast with the image of Tina Turner that he swears will grab six-figures on eBay, I mean it more in terms of our mental capabilities. Think about how brilliant we are compared to a tape recorder, but how hopelessly inaccurate our ability is to remember a conversation.

Ask any police officer who’s interviewed six eyewitnesses and he’ll give you six different accounts of the same event.

$200 Dinners
It’s widely accepted in the world of research that humans remember meaning rather than fact. As an example, if I told you “I went to the mall the other day,” it’s likely that in 10 minutes you would remember the sentence as “I drove to the mall the other day.” In other words, the meaning would stick rather than the details.

Let’s take Fred as an example. Fred is on his way to a job interview for a position as a software developer. His experience meets all the requirements, and based on his resume he’s the top candidate out of the 50 or so that applied.

Fred arrives, dress to impress in his $149 suit from TJ Maxx and $20 black leather shoes from Payless. The interview goes extremely well; he builds rapport with the interviewer, answers most of the technical questions correctly, and manages to craft an artful LEFT OUTER JOIN on the whiteboard.

Fred is on top of the world until, to his surprise, he notices a huge ink stain on his shirt. It turns out Fred likes to keep fountain pens in his shirt pocket (because the ladies dig it). On this fateful day, that pen decided to gush it’s payload all over Fred’s brand new cotton dress shirt. Fred’s embarrassment is palpable as the interview wraps up and although he makes it out of there alive, he doesn’t get the job. Why?

You could say it’s because I made this story up and can twist it any way I want to prove a point. That’s valid, but how about this: after interviewing four more candidates over the next two weeks the hiring manager doesn’t have point by point recall of every interview. In fact, although he made a few notes here and there, all he can do is go with his gut feeling about who would be the best fit for the position. And you know what? Even though Fred fit the position perfectly, there’s a voice in the back of the hiring manager’s mind that won’t let him hire Fred. He doesn’t know why, but he has an awkward feeling about the whole experience. All because of a lousy fountain pen.

The moral of the story is to buy high-quality fountain pens. *ahem* I mean, the moral of the story is that human beings remember meaning rather than fact. This means that the impression they take away from an experience is much more important than what actually happens.

This is why restaurants like The Melting Pot can charge 50 bucks a person for fondue when you can make it at home using the change in your sofa. It’s also why, two years after you see a crappy movie, you won’t be able to remember the character names, dialogue, scenes, or much of the plot, but you will remember that it was terrible. It’s all because the experience of these events is forever lodged in our brains, while the fact of a $200 dinner have long since departed.

This is easily translated into advice for interview day: do everything within your power to make sure you leave the interviewer feeling like she’s hugged a warm puppy. Be cordial, don’t show negative emotions, have excellent manners (the ones you never use around the house) and never, ever act indignant about answering technical questions.

Some people think it’s unfair to ask candidates to write code on the fly; you may be one of these people. The interview is not the place to voice that opinion, whether verbally or through your body language (like the “leaking tire” noise you make when asked - I actually had a candidate do this once).

I’ve also had candidates act bored or roll their eyes at basic programming questions. If explaining how GET is different than POST is beneath you, suck it up, answer the question, and hope the interviewer moves on to topics worthy of your genius soon. If not how will he ever discover how you built a Ruby on Rails compiler in assembler on your Commodore Pet?

Finally, it’s been shown over and over that attractive people fare better in job interviews, get more promotions, and earn more money. Unless you’re Brad Pitt you should show up showered, shaved, and wearing a suit. It doesn’t matter if you don’t believe in suits and don’t ever plan to wear one to work - everyone looks better in a suit (even Brad Pitt).

Bring Something Real
People also remember things that are related to other memories; the more connections, the easier something is to remember.

This is why commercials contain catchy jingles that are really just remakes of pop songs with the words slightly modified. It’s because these songs touch on a piece of our brains that will somehow relate the “coolness” of the song to the product.

If the marketers did their jobs, the next time you hear the song you will likely have an urge to run out and buy yourself a new pair of insoles. These insoles may hurt your feet so bad you’ll feel like you’ve been dancing on broken glass, but somehow they’ll still seem cool because Britney Spears sang “Oops, I bought insoles again.”

This is also why every single memory improvement book revolves around relating things to common objects you encounter in everyday life. Be it a list of items or peoples’ names, the more memories you have that link to an object, the stronger the memory of that object becomes.

To capitalize on this, bring something memorable to the interview. You want the interviewer to link you with as many “good feeling” thoughts as possible. Bring glossy, color print-outs of a UI you worked on or prettied-up copies of a data model you designed. You could even bring sample products from your current or former employer. Your company makes soft drinks? Bring a 6-pack of root beer. Your company prints newspapers? Bring a few copies of today’s edition. Bring something real that the interviewer can look at and touch once you’ve left.

This brings me to a concept I’ve been cooking up for quite a while: a HireMe^TM book. With cheap, high quality, on-demand publishers like Lulu and Blurb, creating a few copies of a custom tome is economical and requires minimal time investment. For around $10 a pop you can print your own commercial-quality paperback containing your resume, samples of your work, and, if you’re the creative type, a section of “Reasons to Hire Me.” I plan to devote a future essay to the concept and design of a HireMe^TM book.

The Self-Reference Effect
Psychologists have discovered a phenomenon they call the self-reference effect, which boils down to the following: people tend to remember information that refers to themselves.

This is why you easily remember someone with the same name as your brother, while forgetting the other 19 people you meet in an evening. This is also why the Jack in the Box commercials during Soccer games have Jack racing after a soccer ball; the marketers are trying to relate to something that a large chunk of the audience will find as a self-reference.

In addition to remembering names and marketing quasi-food, the self-reference effect is amazingly effective at making interviewers relate to you, remember you, and maybe even like you.

Before your interview try to find out as much as possible about your interviewers. If necessary, politely request a list of names to help with your preparation, and head to Google. With common names, try to narrow your search by including terms like the name of the company, or the name of the city where the company is located, or even something as generic as “software developer.” If you find a personal homepage or can pull up a resume you’re golden. This type of information allows you to build a picture in your mind of who they are and what they’re about.

With this information in mind, try to honestly relate to them during the interview. If they publish a lot of articles, be sure to bring up recent articles you’ve written. If they like to water ski, bring up the fact that you go every summer. Do they play the guitar? Mention your Taylor that you play every chance you get. Obviously, this isn’t a license to lie about things you’ve never done to make yourself more familiar; trust me, you’ll get caught. But anything you can do to relate to this person is not only a step towards a connection, but it’s a step towards being burned into their mind forever…or at least until your start date.

The self-reference effect, when used appropriately, is extremely powerful.

Finishing Touches
These techniques are like a coat of Carnuba wax on a Corvette; they add shine, but the underlying paint has to look nice, too. These techniques won’t salvage a lack of technical knowledge or a disregard for punctuality, but used in conjunction with basic interviewing skills they will improve your chances of landing a job.

Just be sure to leave the fountain pen at home.

Special thanks to Mike Taber and Sherry W. for reading drafts of this article.

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Digg this ]

“We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.”

— Larry Wall, Programming Perl (1st edition)

Read more

Some colleagues and I recently started a .NET User Group in the San Gabriel Valley (Pasadena area). Our first meeting was a rousing success with almost 40 attendees, and we’re looking forward to our second meeting next Wednesday, February 15th from 6-9 pm in Monrovia.

We have a great speaker lined up and I’ll be there MC-ing and giving away crazy stacks of books, t-shirts, and software. The cost is $5 at the door which includes pizza.

Check out www.sgvdotnet.org for full details.

Hope to see you there!

Developers come in many shapes and sizes, but over the years I’ve noticed a handful of archetypes that we tend to embody. These archetypes are the fundamental building blocks of who we are as developers, and two to three of them exist in each of us in varying quantities. I’ve worked with a few people who were 90% in a single area.

The archetypes are:

• Trainer/Author - spends the majority of his/her time teaching, training, writing articles and books, and otherwise helping others learn how to program.
• Coder - a hard-core developer. Into design patterns, the next cool and experimental language constructs, and talking about web service proxy generators.
• Lead - excellent organization skills, driven to make projects succeed, and skilled at leading others.
• Technologist - into all the new applications; would rather integrate than write code.

Take a minute to decide which two or three describe you best, and make a guess at the percentage of each. A trusted co-worker can easily verify or dispute your numbers. It’s not an exact science.

I’m 45% Coder, 35% Trainer/Author, and 20% Lead. However in my current position I tend to do a lot more Lead-based tasks with some Coder stuff thrown in. I’ve been doing the Trainer/Author portion in my spare time for the past several years.

The benefit of knowing your archetype is three-fold:

• Career Path - Realizing that you love to teach might make you think twice about taking a promotion requiring you to manage other developers in a deadline-driven environment. Similarly, if you are a technologist you might think about leaving your job as a corporate developer and applying at a product company where your desires could be more easily fulfilled.
• Strengths & Weaknesses - Knowing your strengths is critical to your career happiness. I realized long ago that I have very little desire to be a technologist, which, in retrospect,. explained my distaste for every integration project I’d ever worked on. As a result when it comes time to volunteer for project roles I’m on the other side of the room when people start talking about Biztalk.
• Your USP - Though the term “Unique Selling Proposition” (USP) typically applies to products, it can be applied to people. The idea is to find what differentiates you from the alternatives. Why should a company hire you (whether for full-time, contract, or consulting work)? There are hundreds of seemingly qualified candidates - what do you bring to the table that no one else does? Now is the time to specialize, so whatever your strong archetypes, focus on them and make your focus razor sharp. Make it so there is no competition.

Remember that no area is better than any other. I used to be intimidated by people who knew more than I did about software development until I realized that I had the edge in the areas of writing and leadership. It’s not that my percentages made me better or worse than that developer, it’s just a way of realizing that we each have strengths in certain areas.

Feel free to post your percentages in the comments.

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Submit to Slashdot ]

Your company is a massive jigsaw puzzle and each employee is a unique piece. Once a week go to a different department and ask someone to show you what they do. If they use software you’ve written, find out how they use it. If not, find out how they fit into the big picture of your organization.

The more you know about your co-workers, the more you’ll understand the puzzle. The more you understand the puzzle, the more indispensable you become.

Many of you gasped at the title of this post:

“Become a manager? Has he lost his mind?! I’ll be a coder ’til the day I die!”

I’m not implying that you should give up your coding gloves and step into the ranks of full-time management, but you gain incredible perspective about what makes good and bad developers once you’ve managed a few of them. Even if you never become a full-fledged supervisor, managing a project, being a technical lead, or running your own business are all suitable ways to experience what makes a “better” developer from a different angle.

Before working in software I was a project manager for a large electrical contractor in the bay area. So naturally, when I began my technology career, I quickly moved from writing software to leading projects and managing other developers. Over the next few years I continued to function as a lead/PM until I became the manager of 10 DBAs and developers for the City of Pasadena. And let me tell you, I learned more about what makes a good developer from a management perspective in my short tenure at the City, than in the previous two or three working as a consultant.

Lesson #1: What Makes Someone the Best
One of the first things you’ll learn is who your best developers are and why. And it’s not what you think; often times it’s not the most technically savvy person in a group, rather it’s the one who’s able to make things work with the least amount of management intervention. If you think you have a lot of things to worry about, your manager has to put up with 5 or 10 times more context switches than you do. And when your most critical asset is time, someone who may not be the end-all be-all of personality or technical ability, but who’s able to do a lot of coding without bothering you every few minutes, that developer is worth his weight in platinum.

Lesson #2: It’s Easy to Complain about Your Boss Until You Have to Do His Job
I can’t tell you the shock I felt when I realized for the first time that as a manager the success or failure of a project didn’t rest solely in my hands. The project’s success, and ultimately my success, rested in the hands of programmers whom I had to motivate, work with to ensure they were building the correct software to our development standards, all the while being told by customers and management that we should be doing it faster, for less money, and with less people. It was a horrendous tug-of-war with me in the middle.

In software, as in business, every decision is a compromise. If you’re on the losing end of that compromise it’s easy to complain that the person made a bad decision. For the most part, unless you have an evil boss, she is trying to make the best decisions she can. Trust me, someone who makes a compromise is better than someone who makes no decision at all.

Lesson #3: How to Self-Manage
As a supervisor you can’t get any work done unless your developers learn to be self-sufficient. A large portion of your time should be spent putting out fires (since there are always ample fires to fight), not performing basic developer-related tasks (”For the hundredth time, we use i for our For-Loop variable, not j!”). So as a developer, if you can make something work while bothering your boss even one less time per day, you’re taking a huge burden from his shoulders.

Lesson #4: Do What It Takes to Achieve Results
I’m not an advocate of an unhealthy lifestyle, in fact I’m the guy who takes three week vacations to Africa, but one of the facts of our industry is that there are times when it’s necessary to work overtime. Do what it takes to hit the deadline; don’t make your boss ask you, or worse, order you to stay late. As a developer you can read the writing on the wall and should know well in advance when you need to tell your spouse you’ll be late for dinner.

When it comes time to play, show up and get the job done.

Lesson #5: No Surprises
Surprises are never a good thing in the business world.

I remember being told the day before launch that we weren’t going to hit the deadline. I asked how long they’d known about it and they said a week and a half. Ugh.

If your boss doesn’t require email updates, drop her a 1 or 2 sentence email twice a week letting her know what you did over the last few days and how things are going. I bet it will become standard practice for the entire group. “Pushing” information is a big help when trying to manage many people, and it helps eliminate surprises. Don’t be afraid to share bad news. Bad news in advance is 10-times better than bad news the day everyone else hears about it.

Walk a Mile in My Shoes
Even if you never become a manager, try to walk a mile in your boss’s shoes once in a while. It won’t take long to realize how much you can learn from looking at your job from a different perspective.

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Submit to Slashdot ]