Edit - “do it right the first time” defined in the comments.
The most valuable thing I have ever learned in programming is to do it right the first time. I take extra care now to make sure the logic of a program is carefully planned out ahead of time and that the core code is written to the best of my ability. It takes a lot of discipline, but it results in fewer bugs and gives me a sense of pride on the project from the very beginning (which is actually more valuable for momentum). Projects I’m proud to work on make it easier to come back to them day after day. If you’re also interested in becoming a better programmer, I highly recommend checking out these great resources:
Start by reading this: The Pragmatic Programmer. Make sure you read all of it.
Danny Burbol wrote Being a Better Programmer over at Flipcode, a game development site. The article outlines some common pitfalls, mistakes, and best practices. Game development was one of my first forays into programming (and one of the hardest to date) and the mistakes learned there apply to all platforms.
Becoming a Real Programmer by Guy Keren takes a look at 9 brief lessons to learn. I don’t agree with all of them, but there are some interesting concepts.
How to be a Programmer is the popular essay by Robert Read that you need to read now if you haven’t already done so.
Paul Graham’s Great Hackers and every other essay he has written are great ways of looking at things from a refreshing and practical point of view.
Absolutely do get the Pragmatic Programmer book. I’ve been programming for 23 years and I really wish I’d had that book when I was starting out; it would have saved me a huge amount of time and trouble. If I were managing a software group, I would buy a dozen copies and hand one to each new hire.
Even if you’re an experienced programmer, buy it. I read a number of things that I’d learned through hard experience, but I learned new tips and tricks as well.
Just curious, but I think what you said in the first paragraph goes against all Extreme Programming teaching. Does anyone know what I mean? The model for Extreme Programming is to get something up fast, and retool, retool,retool. The idea is that you cannot possibly think of all cases when you first begin. Now, I’ve never subscribed to Extreme Programming, but I’m more or less just hacking things. So I’d like to hear some thoughts.
It does go against extreme programing, and my statement deserves clarification. My focus on planning has nothing to do with diagrams, meetings, or other time consuming processes. Instead, I take as much time as needed to ensure the logic is correct. This may consist of a one hour thought session with a sketchpad before I start programming, or it may take more.
The reason this is the most valuable thing I have learned is because I used to only do extreme programming. I would jump right into the code. Mistakes are guaranteed, and some mistakes lead to rewriting entire pages. For example, I wrote a page that took 1000 lines of code. I wasn’t happy with it, and rewrote it. Before the rewrite, I planned out the logic thoughtfully, and got it down to 280 lines of code.
Over time I have noticed less bugs and less lines of code when I do logic planning. Basically I’m trying to skip the screw up page and go straight into the rewrite page. I also think part of it is personal preference. Retooling over and over gives me no pride or desire to continue working. I see an ugly blob every time I look at my code / project.
Well, sure, it’s a hybrid of both. I’ve always done something like XP. I used to feel bad that I just couldn’t bring myself to do the BDUF and all the silly block charts. When XP came along I was relieved to see I wasn’t the only one.
But just sitting down and coding isn’t always the best approach either.
I study or discover the requirements, think about it for a bit, try coding some potential troublesome sections. Then I go sit with a pad or whiteboard. First a mind map, to draw out as many ideas as you can think of. Then maybe some rough sketch-out of the required components. Soon enough you’ll be jumping back into the editor and coding madly.
But without that short planning phase, I find that I get overwhelmed with a thousand vague alternatives. It’s not a BDUF or even what most managers would call a ‘plan’. Just a bit of thinking to get on track.
Then I take the advice that many prose writers give – just get something down on paper first, revise later. I used to try to make my code beautiful and perfect on the first pass, and that wasted so much time. I just rough out some sort of rude hack first. You learn more about the problem as you do it, so the right design makes itself known, and then you can re-factor.
To anyone who says “I get it right the first time” is NOT a real programmer. Sure, if you work for a large corporation that allocates 200 hours for you to do a project which will take 1 hour AND they give you 3 months notice, then yes, perhaps it is possible. But in smaller groups where often there isn’t a deadline, but rather an oh-by-the-way, this isn’t always possible. And then there is the business model itself which can be in a state of constant flux. No programmer can program for that. The best you can do is to try and make it flexible enough to handle pretty much anything, but there comes a point when you end up making things way too complicated.
After reading around different community sites, it seems the wording of my post is misleading. I was not trying to send the message that your project will be done right the first time. I am basically saying write your code with some pride and some logic planning.
For example, lets say you have a piece of code that ideally belongs in a class, but it would still funtion properly if not inside of a class. I now find it easier for me to take the extra 15 or so minutes planning out a flexible class instead of “just making it work” the first time around.
I also added “core code” to the post because features change, but some are staying no matter what, and those are the ones I plan around.
Above all, I don’t call myself a “great” programmer, which is why I provided the links to people who probably have more experience than me.
If you want to be a good programmer you need to learn what is going underneath that high level language your using. Understand memory allocation, pointers, stack usage, task switching, etc. And to take it to the next level read a book on Assembly Language and Compilers. That will take you to the next level.
It’s sad how many interviews I have given to CS graduates from well known accredited four year universities who only know Java and/or C#. When I ask them to write a simple strcpy() function is fail miserably.
If you can’t write and explain in detail a strcpy() function in C, I won’t hire you.
I’d add the Joel Test.
I completely agree that The Pragmatic Programmer (and the similar Code Complete) are essentials for anyone starting out programming, but I’m not sure your description of XP is entirely accurate.
XP isn’t about just sitting down and coding, it’s really about splitting a piece of work into a number of smaller chunks, each of which you write as best as you can. Instead of trying to figure out the entire system all at once (which seems to be what you prefer), you start with the most basic functionality, write a test, code it, and go from there.
It’s not that you don’t think before you code—you absolutely do—but just that you do so on a smaller scale. For me anyway, this makes it easier to focus on what’s really required rather than how you presume the system should work. It also cuts down the amount of code you write since every line of code is “the simplest thing that could possibly work” and essential for the system to work.
It’s also worth pointing out that one of the writers of The Pragmatic Programmer, Dave Thomas, is an XP-advocate himself! See here for details!
Aghh! The link worked fine in preview, check out this to hear Dave Thomas talk about XP:
http://www.theserverside.com/talks/video.tss?id=DaveThomas&format=http
Insanum I don’t agree with that. I had to do everything on your list for three years, and while it was a fun challenge I don’t think it gave me the intangibles of a great programmer. I see those things as skills, just as I see learning a for loop as a skill. I’d like to believe there is something more – some greater ability to motivate, inspire, approach and organize a project beautifully that comes with experience and defines a great programmer.
Michael I definately see your point of view, and agree with it. I prefer to take it to a slightly larger scale, but not the entire project.
It’s also funny that most of the articles I linked to contradict each other in one way or another. It is just nice to see professional opinions, so you can try something new and see if it works for you.
By saying ‘do it right’ I basically meant ‘Fix It, Don’t Hack It ’ from the Flipcode article and ‘Being lazy the smart way’ of this article.
Everyone needs a hug.
Everyone needs a hug.
Nice little article, I’ll be sure to have a read of that book, thanks!
PS: I love the way the comments work :O