#over engineering

Emphasis mine…

The Web erases the barrier of distance between people, and it puts all of human knowledge at our fingertips. It also allows us to look at still images and videos of millions of cats, basically all of it for free, from our homes or a small device we carry in our pocket.

No one person owns it, no one person controls it, you don't need permission to use it. And the best part is, you are encouraged to contribute right back. You can post your own cat pictures.

Why is this not enough?

The feline vision of the Internet is fundamentally a humble one, because it does not presume that developers and designers know what they are doing. There are no limits on what people (and cats) can get up to once you link them together. On a planet of seven billion people and millions of cats, the chance that you are going to be able to think of all the best ideas is zero. Someone is always going to come up with something you never expected. A web that connects people in a way where they can contribute gives its authors a chance to be surprised.

We've seen this play out time and again, in that the most productive and revolutionary aspects of web culture came out of left field. The idea of a free, universally editable encyclopedia sounded insane. The idea that a free operating system could run half the Internet was insane. That volunteers in blog comments could write collaborative math papers with some of the most brilliant mathematicians in the world sounded insane.

A currency based entirely on cryptographic hashing still sounds insane, but it sure is interesting.

Even the world wide web itself is the product of a physics nerd winging it, and convincing his colleagues to try out something new.

The Internet is full of projects big and small whose defining trait is that they came out of nowhere and captured people's imaginations. It's also full of awesome cat videos. The key part of this vision is that the Internet succeeds by remaining open and participatory. No one acts as gatekeeper, and it is not just a channel for mindless consumption.

Concéntrate en la solución, no en el problema

Concéntrate en la solución, no en el problema Problema 01

Cuando la NASA comenzó con el lanzamiento de astronautas al espacio, descubrieron que los bolígrafos no funcionarían sin gravedad (o con gravedad cero), pues la tinta no bajaría hasta la superficie en que se deseara escribir.

Solución A) Resolver este problema, les llevó 6 años y 12 millones de dólares. Desarrollaron un bolígrafo que…

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.