Blog Journeys of a Lifelong Learner
Subscribe
Understanding Every Line of Code January 6, 2012
Programmers who have moved into the realm of understanding always suspect their own work first because they know that they cause 95 percent of errors. Understand the role of each line of code and why it’s needed. Nothing is ever right just because it seems to work. If you don’t know why it works, it probably doesn’t—you just don’t know it yet.
Bottom line: A working routine isn’t enough. If you don’t know why it works, study it, discuss it, and experiment with alternative designs until you do.
Steve McConnell in Code Complete
Avoiding General Hackery January 5, 2012
Compiling before you’re sure your program works is often a symptom of the hacker mindset. If you’re not caught in the hacking-and-compiling cycle, compile when you feel it’s appropriate. But be conscious of the tug most people feel toward “hacking, compiling, and fixing” their way to a working program.
Steve McConnell in Code Complete
The vicious cycle of hacking and (in the case of web development) refreshing is highly tempting, but it does not foster development excellence.
Future-Proofing Code January 5, 2012
The best way to prepare for future work is not to design extra layers of base classes that “might be needed someday;” it’s to make current work as clear, straightforward, and simple as possible. That means not creating any more inheritance than is absolutely necessary.
Steve McConnell in Code Complete
Reading Code and Writing Code January 4, 2012
Code is read far more times than it's written, even during initial development. Favoring a technique that speeds write-time convenience at the expense of read-time convenience is a false economy.
Steve McConnell in Code Complete
I must heed this prudent counsel more frequently.
Reinventing the Wheel November 22, 2010
Software develompent is filled with repetition. Some say that repeating old projects is reinventing the wheel. Wheels have been mastered, so making them could be called a waste of time.
Reasoning against developing software to solve problems that have already been solved might include statemens like these:
- Almost anything that can be done in software has already been attempted.
- There are very few truly original products.
- Existing solutions are available for almost every computational need.
- New code presents many opportunities for inserting errors.
Why, then, should new solutions to common software problems be attempted?
- New versions of old ideas help to develop personal software development skill.
- A better understanding of how things work can be developed by building things.
- Building new implementations of known systems can yield new insights.
- Skill in building and implementing software should start with known systems.
Reinventing the wheel is useful if it helps you understand how wheels work.
Building simple systems that are well understood provides a solid foundation for future excellence in developing non-trivial software constructions.
Working on custom implementations of these systems can yield tremendous benefits in the development of personal expertise, even if future projects make heavy use of existing software solutions:
- blog systems
- shopping carts and online stores
- general-purpose content management systems
- contact management applications
- microblogging platforms
- and many others
Familiarity with existing code and ability to work with it is very important, but completely neglecting original development and the learning experiences it provides will destroy potential software development expertise.