Elegant Solutions and Learning

An elegant solution is one in which the optimal outcome is achieved with the minimal expenditure of effort and expense. The bells and whistles in some of todays electronics can easily get out of control resulting in the danger of complexity and customer alienation. Real learning is a cycle of questioning, experimenting and reflecting. Its how we convert curiosity into and innovative solution, so learning must BE the work, not something seperate from it. Learning triggers creativity down the line. Software services require people who are good bridging the gap between the needs of the businesses and the technologies that can make them more efficient or increase their revenues

Todays technology

Today’s technologies are so complicated, no one person can know everything there is to know about any one of them. Do you “know Java”? Yeah, right. Which “Java” is that? Whichever part of Java you know, it’s only a small slice of Java technology. You need to communicate with others in order to leverage their knowledge of the technologies you’re using. And you need to communicate to your teammates your knowledge of the technologies you know and create. And you need to explain to others how to use your code. You need to document your own API’s. When you write a program, what you’re really doing is communicating to another human what it is you want the computer to do. Programming is about communication, just like any other form of writing.The thing is, coding is also a communication skill.

Good Design and Coding

Understanding is as important as coding. Spend as much time thinking about your design as you do coding it. Never code around a design flaw. If you get stuck, always go back to the drawing board. But then follow through with your conclusions.
Flow and design:  Code is more than a series of statements. It is also a relationship of parts. Stepping through your code with a debugger is not how to understand what it does. You must understand the design as well. Don’t think like a debugger, or your code will be incomplete. Think abstractly as well as concretely.
Together belongs together; separate belongs apart. Good Design = High Cohesion + Loose Coupling. Parts that work closely together, keep close to each other. Parts that work separately, keep apart. The bad thing about global data is that it couples code in one part of the system to code in another part. Passing around a massive structure does the same thing. Even passing around a reference to a single variable does the same thing.  
Only relevant coding standards are effective. Indentation, brace style, spacing, blank lines, these all communicate information. Use a consistent style that tells future programmers how the design works.
Maintaining unused code is more expensive than rewriting it. You need to maintain unused code, modify it, tweak it. But you cannot test it, because it is unused. You cannot know whether unused code still actually works. This is an unnecessary burden. Delete unused code, even if you may need to use it again someday. You can always write it again if you need to.
Comments tell why, not what or how. Add comments to explain why the code does what it does. Never add a comment to describe what the code does or how it does it. Instead, use descriptive function and variable names. If you need a comment to tell what or how, your design is flawed.