Michael's Perspective on Programming
Without further ado, let me introduce you to my thoughts and philosophy on programming in general.I have been writing code and programming software since high school. While it's not considered much time by many I do have a wide range of experience working with many programming languages and development tools. These experiences are critical to me as they form the foundation of how I solve a problem in software.
If you are a technical person you may be interested to know how I approach a software project. Enjoy!
How quickly you learn is much MORE important than how much you already know
Things change constantly. New things are being invented every day and if you
cannot keep up with the current trends that's too bad.
Although I know a lot, there are still many, many things I don't know anything about. In that case I am fully willing to learn. I am extremely quick on the uptake and can learn anything in a short amount of time.
Knowing your tools before you use them
Programmers generally do not know everything about their tools before
they use them, which is a common source of bugs.
For example, the standard input cin in C++ ignores white spaces; the int type in Matlab remains unchanged when asked to go beyond its limit; JVM's class loader loads up the class files and attempts to optimize them. Examples go on and on.
Whenever I learn something, I make sure I know as much about it as possible, either through reading or by consulting the experts.
A little knowledge is a dangerous thing. Knowing something partially could
prove fatal, and I don't want that.
Knowing the requirements can take up to half of total development time
Before I get down to programming I
make sure I know absolutely everything about how I will implement it. I don't
dive in without any planning, getting started without thoroughly grasping the
requirements a very dangerous thing to do. I always map
out my design and make sure every detail is taken care of. With a clear
design in mind, I am always able to finish the program very quickly.
The thing is that without thorough planning, it could be the case that your approach is
not a good one and you end up having to change things here and there in order
to get around a snag in the way, but then it creates more problems. You get the
idea.
This stage can take a LOT of time, sometimes as much as half of total development time.
I have real experience when I was involved with HSM
projects where I needed to build an Application to Control an HSM Machine. Getting to know the requirements and sketching the overall
design took more than a week. But once I had the design in mind, I was able to
complete it with great results.
Flexibility and user friendliness is the best policy
I make sure the
program maintains high flexibility in the sense that many things can be changed
and extensions can be added fairly painlessly. In other words, I make sure I do
not 'hard code' important attributes of my program.
Also, if I am designing a user interface I have to make sure it looks nice and easy to use, by which I don't mean gaudy or complex. Many programmers or developers love to make their products stand out by making them look exceedingly showy and complex. However that's not necessary a good approach. Google is a case in point. Look at its search page. So simple and clean!!
A clean user interface is definitely sweet on the eyes.
The clean user interface may belie its true identity - the
most POWERFUL Internet search engine. Anyone who uses it can vouch for this fact. I
just love it! Therefore I say
the user interface should be as simple as possible to appeal to users of all
ages and knowledge levels.
In regard to a non-UI-related program, I believe it is also the case. For example many UNIX utility programs are easy to use and have parameters that are intuitive. I believe before designing a program, one must think about its intended users and make sure it is user friendly from their perspective.
Having a senior guide by your side saves TIME
One lesson
I learned in an electrical engineering class is that whenever I
don't know something, don't guess; ask someone who does. Even if you do know
how to solve a problem, asking the experienced for their suggestion and advice
is not a bad idea.
The thing is that in the software realm there are almost always more than one way to achieve a goal. How do you know the approach you adopt is good? You gain more experience as you write more programs but there's always a first time to everything, in which case if you have a mentor guiding you along you are blessed. His or her unique insight can make a huge difference.
