Entries Tagged 'Becoming a Better Developer' ↓

I received the following email a few weeks ago:

I graduated with an MIS degree while serving in the Military. I took some programming classes like JAVA, C++ etc… I am now back in Boston, MA and find it difficult to find employment where I can learn to become a better programmer. I don’t have the experience but I am willing to learn. Can you please provide me with some direction on what to say on my resume, to gain the experience in the civilian workforce so I can become a better programmer?

My response:
Continue reading →

SmartMoney.com interviewed me this week for their article Web Sites Find Security Seals a Boon for Business. The article talks about ways online merchants, specifically small businesses, can use security seals to legitimize their websites in the eyes of potential customers.

It occurred to me that displaying seals doesn’t change how a website operates; the seals are all about marketing. They’re all about playing the game of looking legitimate to potential customers.

In this case, standards and seals are a good thing: they allow people to quickly verify if a website uses SSL or is reasonably “hacker safe.” This is helpful when you’re shopping for that antique Platypus Beanie Baby and wind up on a site you’ve never heard of. Seeing the Verisign seal probably gives you a bit of warm fuzziness.

Continue reading →

When I was a coding newbie I thought applications should never crash. I wrote code that caught and ignored errors because I didn’t know how else to handle them. I didn’t want the user to see an error page, and figured a running application was always better than an error page. Oh, how wrong I was. On one application alone (not written by me) I wasted 50+ hours over the course of a few months because of exceptions that were caught and not properly handled. Don’t let this happen to you.

I’ve found this mindset to be so common among new developers that I’ve distilled the basics down to two fundamental rules a new developer should follow to the letter. I’m exhausted with cracking open code and seeing a Try/Catch block with no action after the catch. Whether you’re using a language with actual exceptions is beside the point - what matters is that you read through these few simple paragraphs and never, ever obfuscate your application errors.

Picture this (in C#):

Try
{

‘ Application code here
}
Catch
{

‘ Do nothing
}

What happens when an exception is thrown from the application code? Nothing…and that’s a problem.

Continue reading →

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.
–

Last Valentine’s Day my wife gave me a gift certificate for a massage. Nearly a year later (obviously a busy one) I finally redeemed it, and had the most productive day I’ve had in a while.

I’m a pretty healthy guy with no medical conditions or injuries, and I only occasionally eat my weight in carne asada. But I have aches and pains just like anyone else who sites in front of a computer all day.

My massage therapist (whom I mistakenly called a masseuse…oops!) gave me quite an education while I was there. She began by asking about my breathing; most people with desk jobs tend to have very shallow breathing while seated. She drew my attention to my breathing as she worked on my neck, chest, rib cage and, oh yes, the back! Anyone out there with neck aches? Rounded shoulders? Pain in wrists & forearms? Yeah, I thought so. You can have the best ergonomic workstation in the world, but our bodies need care to compensate for endless hours in a chair. Massage with an eye towards specific work in these problems areas can go a long way towards longevity in this field.

Continue reading →

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.

An SbR 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 one or two 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.

For more information on becoming a good programmer, check out the books I mentioned above, as well as my article Personality Traits of the Best Software Developers, and my series on Becoming a Better Developer (links located in the right navigation).

Feel free to chime in with your experience of becoming a programmer.

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

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.

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.