#code simplicity

I prefer fundamental programming books that are short and to the points. Books having more than 250 pages ... I see it as reference books and avoid them as much as I can. One of the driven points behind my preference of short book is that when I was in college, I was assigned to read various thick textbooks. The instructors would go through contents in those textbooks so quickly that at the end of each quarters I barely remember any of those materials. As a result, I came to reason that thick textbooks are for chumps and exams. I do not bother reading them unless I truly really need to. Short books are concise and it gives avenues to relate / expand on its contents on my own. Best of all, I can remember a big chunk of those contents and apply them.

Once in a while I come across amazing books that it is worth reading them over and over again. Here are example of those amazing books that I always have on my desk or in my laptop bag.

Code Simplicity by Max Kanat-Alexander

Javascript : The Good Parts by Douglas Crockford

The Developer's Code by Ka Wai Cheung

The Mythical Man-Month by Frederick Phillips Brooks, Jr.

From the books, I picked up really worthy facts that I think all software developers should be aware of. These facts I can relate in my work and I believe that if everyone in a Dev Team understand and accept these facts... programming life would be so much easier.

First, let's define what facts mean without being too philosophical. Facts as Max Kanat-Alexander wrote...

Facts are just true statements about something. Any true piece of information is a fact.

Facts on Software Engineering

Attributions: I literally copied these from Max's book with my added thoughts. Hopefully, my readers can grasp its context.

Fact #1: The difference between a bad programmer and a good programmer is understanding. That is, bad programmers don't understand what they are doing, and good programmers do.

Review these: https://www.youtube.com/watch?v=0SARbwvhupQ http://www.joelonsoftware.com/articles/HighNotes.html

I am not a rock star programmer by any mean.

I am a good programmer because of my experiences in working with other GREATER programmers, problems / solutions that I have encountered... and that I understood my project specifications. I do not start programming until I understood exactly what I am building. An old saying, "a journey of a thousand miles begins with a single step". In programming, my take is that it should began with writing specifications.

When I write specification... I sometime find an easier solution to the customers needs. If my customers ask me to find a unicorn and fly it to the moon, my specifications tell me their actual end goals.

Fact # 2: Everybody who writes software is a designer.

This fact is very relevant and significant. It is a shame that many programmers overlook it. In my view, bad programmers write codes for themselves. good programmers write codes to be understood by others. Always write codes so dead simple so that other programmers can easily follow.

In a team, regardless how I think .. codes should reflex the invention of my entire team. If I ever get hit by a bus, someone else in my team will be able to hold my responsibilities.

Fact # 3: The most common and disastrous error that programmers make is predicting something about the future when in fact they cannot know.

I do not write codes for the future. I write codes for its current purposes. In my earlier days.. I was all about complex design patterns... because I read codes in open source project (MediaWiki) that apply complex design patterns. I overlooked its application. MediaWiki has complex codes structure because its sister project Wikipedia.org need it to be complex.

Fact #4: The three mistakes that software designers are prone to making in coping with changes* are:

Writing codes that is not needed. Not making the code easy to change. Being too generic. *The longer an application exists, the more probable that any piece of it will have to change.

The counter to these three mistakes is to alter codes for its current purposes... and re-factor them incrementally. When I was younger.... I tend to write codes that I later regret spending so many hours on that piece of codes.

Fact # 5: When your design actually makes things more complex instead of simplifying things, you are over engineering.

I am a victim to this fact so many times... I came up with these two simple rules for myself.

If you copy / paste codes .. you are over engineering.