Solarbox - Programming Advice

Blog >

Over the years as a Java web developer, I've learned a lot about programming (and a little about love). Below is a small collection of programming advice I personally live by and offer to anyone willing to listen. I've excluded implementation-level things you would typically find in best practices programming books. Take it for what it's worth.

Customers often give solutions, not problems. Sometimes they're right; often they're not. Like a psychologist, help them dig deep to discover the root of their problems so you can address real issues and not mere symptoms.
Don't be afraid to push back when asked to bastardize a project. You're not doing the customer or company any favors by being a "nice guy". In fact, it's your job to warn and prevent adverse technical ramifications.
Read every day to stay current with the latest technologies. You don't necessarily have to know how to do them; you just have to know what they are and when they might be applicable.
Stay marketable by keeping your resume and skill sets up to date.
Build everything like it's going to be your problem. Assume you're the one who has to maintain it for life.
Take the time to do things right the first time. Never cut corners; it will always bite you later.
Recognize that in most cases you're kidding yourself when you say you'll come back and fix it later. While your intentions at times may be genuine, it seldom actually happens.
Be consistent in everything you do, whether it be naming convention, coding style, formatting, documentation, etc.
Develop everything as a public API. In other words, be as generic and loosely coupled as possible.
Always code from the client's perspective. Don't assume everyone knows what's in the black box. Make your APIs as simple and easy to use as possible. Make no assumptions.
In spite of what non-GUI developers might tell you, presentation is important.
Constantly refactor as you go, even if it means breaking a bunch of working code.
Always favor the Java API or some industry-standard over homegrown solutions.
Take the time to javadoc as you go. You won't remember what you were doing later and won't want to go back when you could be coding new stuff. Just as importantly, be sure to keep your javadocs up to date.
Try to think about and incorporate design patterns up front. While at times it may take a little longer to develop, it will enforce good design practices and make your code more extensible and easy to maintain.
When possible, pair program. You'd be surprised what you can learn from junior programmers.
The key to successful object-oriented design is to accurately represent the real world. Always ask yourself, "Does this thing as I've defined it accurately represent its real-world counterpart?"
When creating member instance variables, always ask yourself, "Why should I NOT make this into its own object (as opposed to a simple primitive, String, or wrapper)?"
Take the time to create an interface for each of your key domain models. This will enforce strong design contracts and make it possible to implement various design patterns such as decorators, adapters, and so forth.
Always be explicit, as opposed to implicit. Readability is crucially important. There's nothing wrong with verbosity.
Favor simplicity over complexity. When things are complex by their very nature, avoid complicating it.
Every line of code should read as an English sentence. A great way to achieve this is to break large methods into smaller methods (logical groupings). Be sure to name those methods as descriptive English sentences.
In general, when writing code, favor maintainability over performance. Without compromising maintainability, substantial performance gains can be realized via hardware, containers, and databases.