Entries Tagged 'Becoming a Better Developer' ↓

Deadlines: On Being a Professional Software Developer

When I was in college I was a professional comic book writer. After numerous submissions I had several stories accepted by three independent comic book companies, all slated for publication.

I even received a $100 advance for one of the stories, with all of them paying royalties on the “back end,” meaning I’d probably wind up making $100 per story if I was lucky. And back then $100 was a lot of…no, let’s face it, even back then $100 was nothing. But I could call myself a professional comic book writer.

On Being a Professional
Which is a joke, of course, because I wasn’t a professional. I was writing in a tiny bedroom, typically from 10 at night until 2 in the morning, cranking out a short script every week or two. Sure, I had honed my skills as a writer enough to match the myriad of others trying to make it, but I was not a professional writer. And I’ve had a hard time puting my finger on what it was that distinguished me from those whom I considered “legitimate” comic book writers. It wasn’t the fact that I worked out of a small apartment. Or that I wrote at night.

It was the fact that I didn’t consistently deliver under the pressure of deadlines.

I’m sure I’ll receive a few comments saying that a professional is someone who gets paid for what they do, or someone who does something as their main source of income, or someone who’s easy to work with, or someone who comments their code. Those are some of the components of being a professional, but one of the most important and often overlooked pieces of being a professional is consistently delivering a usable product in the face of deadlines.

How Many Deadlines Must a Man Walk Down…
I knew at least two guys who were amazing comic book artists. Both drew as well as the books on the shelves, but neither could draw an entire 22-page comic in a month…and that’s what it takes to be a professional in that game.

I’m not saying if you miss a deadline you’re suddenly an amateur – the continuum is much less binary than it is fuzzy. But during your career, your present job, or the past 6 months, how many deadlines have you hit? How many have you missed?

There are going to be extenuating circumstances. There are going to be times when a third party vendor flops and the project falls apart at the last minute. And there are going to be times when the deadline is set externally and you know from the outset you’ll never hit it. But if you find that there’s always a reason you aren’t hitting deadlines you have to start asking yourself: Is it you?

I know that somewhere between 55 and 90 percent of software projects fail. Missing deadlines is easy; I could get my mom, who knows nothing about software development, to come in and miss project deadlines. Does the fact that she showed up and collected a check make her a professional developer? She’s easy to work with and comments her code.

So here is my question: during your career, your present job, or the past 6 months, how many deadlines have you hit and how many have you missed?

This isn’t a show of hands, just a gut check.

Advice on How to Become a Programmer

A Software by Rob reader writes:

I want to learn to program computers:

  • What is your advice on becoming a good programmer?
  • How do you acquire the knowledge?
  • Is it necessary to know mathematics, specifically algebra, to be a good programmer?

I receive several emails per month along these lines, so I’ve decided to share my advice on the subject. Note that I said “my advice” and not “the one and only way”; there are too many paths for one person to know them all. Here are some thoughts based on my experience:

Q: What is your advice on becoming a good programmer?

Everyone I’ve talked to has taken a different path. Programming is different from other engineering disciplines; if you want to become an electrical engineer you go to school, graduate, work for an engineering firm, and one day take a test and get licensed. Programming is different because people do it as a hobby; no one designs electrical subsystems for fun. This creates more possibilities for learning how to code.

Here are the elements I think are key:

  • Learn, learn, learn. You must have an insatiable appetite for knowledge. This usually means reading a programming book every few weeks in the early days, and moving on to more conceptual books like The Pragmatic Programmer, Code Complete, and Facts and Fallacies after 6-12 months of full-time coding. I can’t stress enough the value of reading, nor the value of immersing yourself in code early in the process.
  • Transition into Concepts. Learning how to be a good programmer begins with learning logic concepts and language syntax; they are much easier to understand when taken together. But good developers quickly desire knowledge that transcends language syntax. Perl, PHP, Java, ColdFusion, ASP…all languages I used in my first 18 months as a professional programmer. What made me a good programmer was not my knowledge of each language, but my desire to understand and refine concepts like D.R.Y., the broken window theory, and code re-use.
  • Hang Out With Programmers Who Are Better Than You. As a guitar player, the most I ever learned about the craft of songwriting was when I was hanging out with people who were much better than I. The same goes for writing software. And due to this new-fangled internet thingy you don’t even have to be physically present to be a part of the community: read programming blogs from the heavy hitters (Scott Guthrie, Rocky Lhotka, Dino Esposito, Scott Mitchell, etc…), check out programming forums, and look at other peoples’ code. Reading source code can be a pain, but the more you see the more you will be able to identity code that’s easy to understand, and code that takes a PhD to figure out how they output “Hello World” to the screen.

Q: How do you acquire the necessary knowledge?

There are a number of possibilities:

  • A Software Apprenticeship. If you haven’t ready my article on Software Apprenticeships, I recommend you do. The best (and I would argue the quickest) way to become a good programmer is to write code under the wing of an experienced developer who will teach you not only the basics, but the in-depth knowledge that takes years of experience to learn. I consider this option leaps and bounds above all others.
  • Learning while Doing. Want to learn to code? Get a job writing code. I don’t care if you make $5 an hour; you will progress more in 1 month as a full-time developer than you will in a year of hobby programming. There’s no better way to learn to program than to write code.
  • Books & Mags. Books and magazines have been key in my quest for programming knowledge. When I’ve apprenticed developers in the past, I use books as their primary source of basic knowledge, having them read 1-2 programming books per month, while teaching them more advanced techniques in person.
  • College. Having gone this route myself I am well aware of the limitations of the U.S. College system in preparing students for a career in computer programming. Preparing them for a career in determining little-o and big-O notation, sure, but actually writing code from the get go? Nope. College is great for high-level theory, but work experience trounces it when it comes to learning software development.
  • Tech school. I’ve only worked with one programmer who went to a technical school and she had good knowledge of language and coding concepts, but not a ton of theory or design knowledge. As a result, her code was utilitarian and used a lot of brute-force, but was often not well-designed or easily maintainable. There’s obviously a balance between not enough practical knowledge (college) and not enough theoretical knowledge (tech school). I am using a very narrow sample, so don’t take this as a blanket judgment of tech schools. Perhaps an SbR reader with more experience in this area can enlighten us. As an aside, the network administrators I’ve worked with from tech school have been well-trained and great to work with. Perhaps the nuts and bolts of networking are better suited for such a practical teaching approach.

Q: Is it necessary to know mathematics, specifically algebra, to be a good programmer?

Quite simply, no; it’s not necessary to know math in order to be a programmer.

If you’re developing games, then mathematics and physics play a large part, but building an invoicing application does not require much beyond basic addition and subtraction.

However, from personal experience, people who have an easy time learning mathematics and enjoy solving logic problems (be they algebra or how to move Mount Fuji), tend to learn code quicker and enjoy it more in the long run. It takes a twisted mind, my friends.


If you are interested in reading more on the subject of becoming a programmer, I’ve written a totally free 33-page ebook titled How to Become a Programmer: Everything (Non-technical) You Need to Know. You can download it here.

Top 20 Programming Lessons I’ve Learned in 20 Years

JD over at DCS Media published an insightful post titled Top 20 Programming Lessons I’ve Learned in 20 Years. A few highlights:

  • Always backup your code
  • You are not the best at programming. Live with it.
  • Simplify the algorithm
  • Reminisce about your code
  • No project is ever simple
  • Software is never finished

New Article: Nine Things Developers Want More Than Money

From my new article Nine Things Developers Want More Than Money:

“If you want to collect a paycheck for 25 years and retire with a gold watch and a pension then go for companies that have the hygiene factors nailed. Stroll in at 8, head for the door at 4:59, and count the years until you’re kicking up your feet on a beach bar in Costa Rica.

But if you’re reading this, odds are that you aren’t the kind of person who never thinks about code after 5:01; you’re more likely to have a collection of DVDs that come up in an Amazon search for “Silicon Valley.” You’re probably one of those people who needs motivation factors or you go crazy with restlessness, and when the motivation factors are in place you’ll work ridiculous hours for low pay just because it’s so damn fun.

I talked to a dozen colleagues and pored over my own experiences to arrive at this list of nine software development motivation factors – Rob’s Criteria for Keeping Your Developers Happy.”

Read the complete article here.

Becoming a Better Developer Part 10: What Do Your Colleagues Think of You?

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.

Becoming a Better Developer Part 9: How to Criticize a Software Developer Without Getting Punched

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
state of the art
move in condition

Lower Sale Price
well maintained
great neighborhood

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.

New Article: How To Burn $6,540 a Week: Indecision and Software Development

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.

New Article: Nailing Your Technical Interview

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.

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.

$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 HireMeTM 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 HireMeTM 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 ]

The 3 Great Virtues of a Programmer

“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