7 quotes that helped make my programming life easier

Although it is easy to write several hello worlds, programming is not always easy. In my life, I had came across inspiration quotes from famous people which had benefited me in different ways. Here are 7 quotes which I felt had helped make my programming life easier.

1) "We don't know a millionth of one percent about anything." - Thomas Edison

Quite often, being resistant to understand something new is the reason why we find it difficult to understand. Knowing that I don't know a millionth of one percent about anything is how I get myself into seemingly tough programming jobs.

For instance, designing and implementing client components that coordinate application virtualization activities was once tough to me. The virtualization domain was new, the .NET framework was new, and even the C# programming language was new. After I had completed those client components, I had added a new programming language and a few technology concepts into my toolbox. With these new concepts, subsequent similar jobs became much easier.

2) "Genius is one percent inspiration, ninety-nine percent perspiration." - Thomas Edison

Things don't often come easily, especially proficiency. As Malcolm Gladwell suggested in Outliers, 10,000 hours of practice is necessary to make someone an expert. Although not all experts have 10,000 hours of practice before they became experts, they most probably would have put in considerable amount of effort in their area of expertise.

For programming, this quote reminds me to "get my hands" dirty constantly. It is easy to read about programming, but without practice, those wonderful theories will not stick. To make myself comfortable with Java, I had created a Swing version of TicTacToe, a simple file transfer program to transfer files from Windows XP to Fedora Core 3 and a record booking system that was part of my Sun Certified Java Developer assignment. Similarly to hone my web development skills, I bought techcoil.com and built the portfolio sections of this website from scratch. A month later, I implemented the blog section with WordPress.

This quote also helped in motivating me in programming parts of the program that are no longer difficult because of previous familiarity. This motivation is important as a novel program often consists of many easy parts and a few difficult parts. Furthermore, chances are that if I do not complete the easier parts first, I will not be able to work on the tougher ones. Who knows? Perhaps the easier parts are not really that easy as it seems initially.

Too much sweating could lead to boredom, especially when churning similar programming constructs repeatedly. When that happens, you can consider getting your computer to do that for you.

3) "A person who never made a mistake never tried anything new." - Albert Einstein

No matter how prepared you are for a certain task, you will most likely make mistakes along the way, especially if you are venturing into new areas.

Before the J3 Roving Eye could be a winning piece, bugs surfaced in the computer to servo interface that caused our model car to crash.

Programming the client components that coordinate application provisioning activities were not totally smooth either.

While dividing and conquering helps isolate problem areas and logging helps identify them, it is this quote that calm my nerves when unexpected situations occur. Even when I could not produce a fix immediately, taking the situations calmly certainly helped me slept better so that I could tackle the problems with more energy the following day.

4) "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." - Doug McIlroy

Software engineering and programming classes often recommend dividing big problems into many smaller pieces and then conquering the big problems by making the smaller pieces work well together. Such a recommendation had helped me create codes that are easy to revisit time and time again. When the user interface did not show correctly, I would know that I need to look at the codes that are responsible for rendering the view. When needed data did not get loaded correctly, I would focus my attention at the codes that query the database. And when there is a need to handle new data in the program, I would add the changes at the database wrappers.

While the first two statements helped me in programming directly, the final statement contributed indirectly. The last statement has had a strong influence on the ecosystem of the web.

The web is made up of many programs that interpret text streams. Browsers and servers communicate with one another through HTTP requests and responses. Browsers know how to render screens by interpreting HTML, CSS and Javascript. The ubiquity of these universal interfaces makes it convenient to create applications that are accessible anytime from anywhere. Without these universal interfaces, I would probably have to spend more time to create techcoil.com.

5) "The computing scientist's main challenge is not to get confused by the complexities of his own making." - E. W. Dijkstra

Although we cannot guarantee that others can understand our codes, the least we can do is to write our codes such that we ourselves are able to maintain them. As such, this quote invites me to spend a considerable amount of effort in designing my code structure before I follow the second quote from Thomas Edison.

To make sure I reduce complexities in my own making, I ask myself these questions before I introduce a new set of codes into my program:

  1. Why is it necessary to add this set of codes?
  2. How much code savings can this set of codes introduce?
  3. What is the main responsibility of this set of codes?
  4. Where will I use this set of codes?
  5. When will there be changes to this set of codes?

The gist of this set of questions is to eliminate unnecessary codes. If there is a need for code inclusion, I will name identifiers based on the main responsibility of the codes and employ software design patterns to mitigate the effect of code changes.

6) "Intellectuals solve problems, geniuses prevent them." - Albert Einstein

Programming is an activity to solve problems, which makes every able programmer an intellectual to start with. This quote reminds me to always try and prevent problems that can surface from usages of my code. In the case of a graphical user interface, I will code the login form such that the submit button is enabled only when both the required fields are supplied. And as advised by Joshua Blotch in his Effective Java, I will always return a container instance instead of null for a method that declares a container as its return type. By preventing problems that may occur, I made my programming life easier by reducing the need to relook at the same piece of code.

7) "Success is a lousy teacher. It seduces smart people into thinking that they can't lose" - Bill Gates

Success begets sucess, but only when one never gets too complacent to consider possible failure points and accept new ways of getting to success. In programming, it is often tempting to stick with a comfortable way of programming because of previous successes. However, just because a particular way of doing things work well in a particular case doesn't mean that it will work well for other cases as well.

Keeping this quote in mind, I am always receptive of new programming ideas and concepts. This attitude has always helped make my programming life easier. For instance, there was once when I reached a point where I could build C# projects by borrowing concepts from the Java programming language. Even though that was enough for me to get my paycheck, I continued extra hours to deepen my understanding of the C# syntax.

My efforts paid off after I had acquired the knowledge to use events. In my subsequent C# projects, implementing observer patterns through events had resulted in less programming work as compared to implementing them the Java way.

About Clivant

Clivant a.k.a Chai Heng enjoys composing software and building systems to serve people. He owns techcoil.com and hopes that whatever he had written and built so far had benefited people. All views expressed belongs to him and are not representative of the company that he works/worked for.