The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
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
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
What are the key elements that ensure the success of your project? What are the keys that will tell you not to continue with the project? I don’t know to tell you the truth. 
But the four things that are outlined below, and explained by Reganwald blog, I are crucial, in my opinion. This is a very good, must-read and re-read (notice new category ), article.
Excerpts from the entry:
1. The quality of the people doing the development2. The expected value of the product to its stakeholders3. The fitness of the proposed solution4. The quality of project management and expectations communication
I’ve read the whole article and it is one of the best I’ve read on the subject! I concur that these things are crucial.
Reference What I’ve learned from failure, Raganwald blog
I believe that good programmers are egoless and humble. There is no room in software development for attitude. Of course, you can be that way, and a lot of people are, but what they fail to recognize is that the path takes them downwards. That path will not make you better, that’s for sure. So be humble, admit mistakes, learn from others, and you’ll do well.
Lamont Adams has a list of 10 Commandments of Egoless Programming. It’s good stuff, read it.
1. Understand and accept that you will make mistakes.2. You are not your code.3. No matter how much “karate” you know, someone else will always know more.4. Don’t rewrite code without consultation.5. Treat people who know less than you with respect, deference, and patience.6. The only constant in the world is change. Be open to it and accept it with a smile.7. The only true authority stems from knowledge, not from position.8. Fight for what you believe, but gracefully accept defeat.9. Don’t be “the guy in the room.”10. Critique code instead of people傭e kind to the coder, not to the code.
For a more detailed version, go to the article, below.
ReferenceTen Commandments of Egoless Programming, Lamont Adams
RelatedEvery Craftsman Is Dump and Lazy, my post
Various CSS design templateshttp://www.intensivstation.ch/en/templates/
Nice array of searchable templateshttp://tools.i-use.it/
Find more design stuff — ideas — at digg.com/design. (I’m really enjoying digg.com so far.)
Related500+ Colorshttp://cloford.com/resources/colours/500col.htm
I came across a good list of tools (most of them Eclipse plugins) that provide reports based on your source code. All free. Cobertura is a code coverage tool that looks very similar to Clover (which costs a lot) and it’s free.
This list is taken from an article by Mike Clark on StickyMinds.
Checkstyle: A highly configurable coding standard checker with a default set of standard and optional checks. (http://checkstyle.sourceforge.net)
Cobertura: A code coverage analyzer that identifies areas of code that aren’t covered by tests. Unfortunately, code coverage metrics are often used as instruments for programmer (and tester) abuse. When used properly as constructive feedback, these metrics can help improve your testing skills by identifying aspects of code that often go untested. (http://cobertura.sourceforge.net)
JDepend: A static code analyzer that generates design-quality metrics based on Java package dependencies, including identifying circular package references. Disclaimer: Your humble author wrote this tool. (http://www.clarkware.com/software/JDepend.html)
ReferenceCode Craft: Staying Out of Code DebtStickyMinds.com, by Mike Clark
Hibernate Quickly
by Patrick Peak, Nick Heudecker
ISBN 1932394419
Date Read 10/2005
My Rating
A quick book to read. A book written quickly. Good intro and overall a good book, but I expected something better.
The book left a “I need more info” feeling. I know this is supposed to be a “quick” book and not totally comprehensive, but still, any book has to do that. There is just not enough details to understand Hibernate totally. There is enough to get you started, but not enough to get a comprehensive understanding.
Throughout the book, I was thinking “I”m not sure if I believe that” or “that’s not correct.” For instance, in the chapter on testing, the author explains the different test strategies. First of all, none of the strategies explained were really unit tests, and the author does not mention that. Second of all, the author does not explain how you can test using mock objects. That’s just an example, but there were more points like that in the book.
You can read the book quickly (which is good), gain some knowledge, and move on to a more detailed reference book. A decent book.
|
If you don稚 have time to do it right, when will you have time to do it over?
–John Wooden
basketball coach |
This is true in sports, but especially true when developing software. Ask yourself that question constantly and you’ll do a better job.
Are you thinking of creating an application on the web? Maybe create a company out of it? Evhead has a set of excellent web-startup ideas — rules — that you should read before you go ahead. Very good stuff for all web programmers.
ReferenceTen Rules For Web Startups by evhead
Lots of them. Check them out at programmingebooks.tk
|
|
A critical ability in OO development is to skillfully assign responsibilities to software objects
–Craig Larman
author, Applying UML and Patterns |
Can’t agree more with Larman. To be a good OO developer, to truly understand what object oriented means, you’ve got to treat classes as objects with responsibilities, and be knowledgeable on how to assign them. Larman’s book is classic in this category.
Here’s what Martin Fowler had to say on the subject.
|
|
Understanding responsibilities is key to good object-oriented design.
–Martin Fowler
quoted in Applying UML and Patterns |
