The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

Seven Secrets of Successful Programmers

There was an article today on reddit, Seven Secrets of Successful Programmers. The article contains some good tips, but overall it is too simplistic and not challenging enough, as pointed by Lars Wirzenius, in his follow up to the first article, Rant: Secrets of Successful Programmers.

What are the good points from the first article? Code for human consumption. That’s true. You should code for humans first, computers second. Make your code readable, it’s very important. Comment often and comment well. I think it’s critical to write a self-documenting code, as recommended by Steve McConnell. If you have to comment your code, your code is not good. Change it so you don’t need a comment, and then add a comment. Name your variables to aid readability. True, variables should not be cryptic. Keep your functions simple. That’s very important. Your function should do one thing and do it well. Same goes with your objects. Your object should have a well defined, cohesive set of responsibilities and do them well.

In his follow up, Lars suggests different seven secrets. They’re very good. In fact, I think they’re excellent. Much more comprehensive, and challenging. Maybe in the future I’ll come up with my own list. :-)

Lars Wirzenius, Rant: Secrets of Successful Programmers

1. Learn to worship the goddess of simplicity. KISS a lot. This is much harder than it seems: it’s more difficult to be simple and good than to be complicated and adequate. Simplicity starts with the specification of the program or system, and needs to permeate the design, and the implementation, at every step.

2. Pick good tools, and learn them well. You need to know many tools, and know them well, or you’ll waste time on doing unnecessary things. Tools include software programs, books, algorithms, data structures, and mental models. Learn editors, programming languages, Unix command line tools, and so on. Learn at least three different paradigms for programming.

3. Learn how to learn and keep on learning. New stuff is invented daily, and you need to keep up with it, or you’ll end up as useless as a COBOL programmer doing a web shop.

4. Develop debugging muscles. This is perhaps the hardest thing to learn, since no-body seems to be teaching it. You’ll be spending most of your time doing it.

5. Learn how to do testing well. Unit tests, test driven development, black-box testing, integration testing, regression testing, test automation, … There’s lots of ways of reducing the likelihood that code escapes your hands with bugs still in it. It will inevitably happen, but if you know what you do, you can be better than most everyone else. The industry standard for commercial, proprietary code seems to be around 20 to 30 bugs per thousand lines of code; the Linux kernel has less than 1, and is known as a cesspool of bug-infested muck, so surely you can do better?

6. Learn to write prose well. Then write a lot. If you can’t write a README, a manual page, or the specification for your next work project, who’s going to know about your great programming?

7. Oh, you need to learn how to program well as well, and that isn’t so easy either. Knowing how to program well merely isn’t enough to be a successful programmer.

ReferenceDuncan Merrion, Seven Secrets of Successful ProgrammersLars Wirzenius, Rant: Secrets of Successful ProgrammersSteve McConnell, Code Complete

Favorite Quote

Topics

Tags

Archive

Currently Reading

Info

© 2001-2024 Stanley Kubasek About me :: Contact me

Me on Twitter

»see more

Recent Entries