|
From the desk of
|
Master of Information Technology,
Software Design
Thesis :
Functional Abstraction to Support Rapid Compiler Construction
Brussels Free University, 1988
View my profile on LinkedIn
You have been asked to implement some program and you have been brainstorming. You got all kinds of ideas of how the user might be helped by adding this and that. You have taken into account all kinds of scenarios and provided lots of parameters.
Well, let me tell you that most probably you are over providing. Your imagination produced all these ideas, but they are not necessarily what the user needs.
Chances are that the user does not know what he really needs until you show him something. Save on your efforts. Produce a working prototype. Show it to the end user.
Take note of his observations and ideas, so that you can come up with things that are really useful for him.
Has it ever happened to you that you spent some good time implementing things, and then showed your creation to the user only to find out that it was not exactly what they wanted?
Or suddenly it turns out that they do not remember something they said and you have implemented it according to what you thought they had said.
To avoid such surprises, put everything in black and white.
Do a profound analysis. Write an outline of what the program will do, what screens and reports you will create. Let this be reviewed by the end user.
Obtain a formal agreement from the user. This can be a hand written signature or simply a confirmation email.
Just make sure that you have something to show him or others to prove what you agreed on.
Click here to search for "Tips for programmers" on Amazon...
Ok, you have just finished squeezing the best of the best out of your brain. Finally you have been able to write down your ideas in programming language. The program is finished!
Now you are all excited and ready to show your new baby to the world, right? Wrong! Before you start screaming and inviting over everybody, test your product yourself.
Do not make the mistake to think that because you have put in all your best efforts and best thinking your product will work flawlessly. Try it out. Put yourself in the shoes of the end user. Make sure that you try out everything very thoroughly.
Do not assume that because you consider yourself some kind of programming genius everything you spit out will work as expected. Do not trust yourself.
Make sure to deliver quality! No matter how small a change you make to a program, test it.
First admit that you are not perfect and that there may be mistakes in your own programs.
When you must find a bug somehow you need to narrow down to the exact spot where things go wrong.
Insert code to show some messages throughout your program so that you can see what the program really does. Or use a debugger so that you can trace the execution path of your program and see how far it gets.
Apply the binary search method :
If you were testing with large inputs then test first with few inputs only. Gradually add more inputs.
Temporarily comment out parts of your code.
I remember when I was implementing a program for my thesis. In one of my routines the program did not behave as expected. I tested and tested again and again. I examined the logic of the routine and the programming logic looked fine, but it did not produce the expected result.
After thorough testing and thinking out of the box I found that a specific variable was being overwritten unexpectedly. In the declaration section of my routine this variable was preceded by another one. The code generated by the compiler was faulty: assignments to the preceding variable were overwriting the other variable.
That was really hard to find!
So do not take for granted that the programming environment you work with is 100% trustworthy.
If you are facing an unexplainable programming error then do some specific testing to see if the code generated by your programming environment is ok.
Often when you must produce a new program or when you must add something to an existing one you will find that it is similar to something you have done before. Or someone in your company did something similar before.
Do not reinvent the wheel every time you need to implement something.
Look through what you or others have programmed before and find what is most similar to what you need now. Copy it and modify the copy. This can save you lots of time.
Use sheets of paper or a document on your pc to take note of all ideas that pop up in your mind.
Write down all your ideas the very moment they occur to you. Do not rely on your memory alone. Often you have a good idea and later you cannot remember exactly what it was.
Review your idea sheets from time to time and implement each one of the ideas that you have written down.
Check off the ideas that you have already implemented.
If you are working on a very large program implement it step by step.
Do not make the mistake to implement everything and then test it as a whole.
Make small changes, test them, and make corrections if necessary. Then make more small changes.
If you implement everything and then test it all at once you will have a hard time finding out where exactly are the errors in your program.
Make use of special purpose project management software tools if you or your company can afford it.
Otherwise, at least write down all you need to do on paper and check off the things you already did.
Or use a text editor, putting a "+" in front of things left to do and an "ok." in front of things done. For example :
+ this thing left to do
ok. this issue was handled
+ another thing to do
Or use an Excel sheet with color coding. For example :
Keep a log of everything you do in a text file or in an excel.
Each time you start to work on a new topic or project part or support ticket, write down the start time and what it was.
If you use excel, use formulas to calculate the time you spent on each issue. This may also help you to fill in a time log if your company requires you to do so. For example :
Note : Columns B, D, E and F have format Time.
Maybe you would rather relax in your hammock, or watch television, or surf the net, or whatever it is that you like to do, than sit behind that computer and squeeze out code or fill in parameters in your programming environment.
Then when you really get to sit behind your computer, still your mind is traveling. Physically you are at the job site but mentally you are absent.
Well, after all, you will have to get down to earth, concentrate, and do the real work.
Stop postponing. Get over your internal resistance, over your fatigue, your depression, over your laziness, whatever it is that keeps you from being productive.
If you are just sitting idle without knowing how to start the task at hand, then start by opening up the source file of the program that you must modify.
Review the source code in which you must make the changes. Try to understand what it does.
Then start applying small changes and do some testing step by step.
Run the program and see what it does, how it behaves under different circumstances.
Get your feet in the water and the rest will follow.
You really must know your programming language and your programming environment.
Not everything is what it looks like or what it is named after.
Sometimes the naming of things may mislead you.
Read the manuals so that you know what things were really meant for.
Of course also be aware that manuals may be out of date, contain errors, or be incomplete.
Study the manuals and apply common sense.
All the time while you are programming you are making decisions and compromises.
Limitations of the programming environment may force you into specific workarounds or weird programming constructs.
Leave a trace of your thoughts and your decisions by commenting your code throughout.
Also use significant identifiers in your code.
This will be of great help for you if you have to come back weeks, months or even years later to make changes.
Your memories may have faded, but if you can read over whatever lead you back then to make certain decisions, that will help you refresh your mind and pick back up where you had left before.
Sometimes it seems you just cannot get things to work.
Try to find a workaround. Try again and again. Do not give up.
Try different combinations of parameters of your environment.
Take a break. Try again later. Try again the next day or next week.
Think about what could be the reason that something is not working.
Push through, do not give up.
Read books about your problem at hand.
Consult with fellow programmers.
Research the internet.
Launch a question at Experts Exchange. If you can afford it, sign up for their premium service. Their experts have helped me out several times.
In my first year at the university we learnt Pascal programming. We used the textbook "Programming in PASCAL" REVISED EDITION (ISBN 0-201-02775-5)written by Peter Grogono.
Our learning of data structures was done on top of what Pascal provided. For this we used the textbook "DATA STRUCTURES USING PASCAL" (ISBN 0-13-196436-4)authored by Aaron M. Tenenbaum and Moshe J. Augenstein.
In my second year we learnt about modular software development. We practised in the Modula-2 programming language. Our textbook was "MODULA-2", subtitled "A SOFTWARE DEVELOPMENT APPROACH" (ISBN 0-471-87834-0)by Gary A. Ford and Richard S. Wiener.
When you got tough software design decisions ahead, how do you make sure to choose the best alternative?
Here is a small collection of design principles I encountered over the years. Take your time to investigate them all and decide for yourself how you will apply them, if at all.
YAGNI : You Aren't Gonna Need It
If it ain't broke, don't fix it
Oh yeah, this tip is for Christians only!
By the way, if you do not yet believe in the Lord Jesus Christ, I kindly invite you to visit the web sitewhere you can read my testimony and so much more!
Yes, I am a computer programmer who now believes in the God of Israel, in the Lord Jesus Christ and the Holy Spirit. And I try to walk with the Lord Jesus every day of my life.
Well then, if you are a Christian programmer, use prayer.
Consult with the Master Programmer. Ask God to reveal you how to design your programs.
Ask the Holy Spirit : what do I do next?
Then the ideas will flow. Just write them down and implement them!
Here are just a few Bible verses you should put into practice if you are professing to be a Christian.
Joshua 1:9 The Voice (VOICE)
9 This is My command: be strong and courageous. Never be afraid or discouraged because I am your God, the Eternal One, and I will remain with you wherever you go.
Colossians 3:22-25 The Voice (VOICE)
22 Slaves: obey your earthly masters in all things. Don't just act earnest in your service only when they are watching.
Serve with a sincere heart (even when others aren't watching), fearing the Lord who is always watching!
23 So no matter what your task is, work hard. Always do your best as the Lord's servant, not as man's,
24 because you know your reward is the Lord's inheritance. You serve the Lord, the Anointed One, and
25 anyone who does wrong will be paid his due because He doesn't play favorites.
Be available and committed in your job as a programmer!
I remember when I studied Latin Mathematics at St. Rombouts College in Malines, Belgium. That was from 1978 to 1984. We had to buy a scientific calculator for mathematics classes. My parents bought me a HP-10C. I loved to spend time writing and executing small programs on this calculator.
Somewhere around 1982, 1983 a Texas Instruments computer was for sale at the local supermarket. There was a model in exposition, free to use and try out. While my parents did their shopping I started to read the manual and actually typed in my first BASIC program, copied straight from the manual. That really made me want to get my hands on my own computer, but right then the price was a real obstacle for me.
In the summer of 1983 my father told me that there had been a spectacular price drop in the Commodore 64. One day we went to Brussels by train. Together with one of my father's colleagues we went to a shop and I spent about 16,000.00 BEF (sixteen thousand Belgian Francs) to get my hands on this computer.
On my own I experimented a lot with BASIC. Later I bought a manual and learnt the C64's machine code. I programmed Conway's Game of Life in machine code because it was way too slow in BASIC. That last year of secondary school I spent more time playing and programming on my C64 than studying.
Then there came along a moment of decision: keep studying or start to work. At that time I really was an introvert out-of-the-world older kid and I felt anything but ready to start working. So I decided to grab my father's offer to keep on studying. Most fellow students of my grade decided to become civil engineers. But the five years of that study and its technical contents really scared me off. So finally I decided to study "Informatica" at the Brussels Free University.
But basically I had already learned how to program on my own before I decided to get that formal study. The first year at the university was mostly filled with mathematics and little information technology. But each year there was more computer stuff and less mathematics. In the second year of my study I sold my C64 and bought an Atari 1040 STf. I learned to program in Pascal, Cobol and Modula-2.
I graduated in 1988 on the thesis "Functional Abstraction to Support Rapid Compiler Construction".
Since 1988 I am working as an analyst and programmer in the information technology field, mainly using Oracle databases and Oracle's Developer programming environment. I have also set up several web sites since 2001, using plain HTML, PHP, or ready made software like Content Management Systems.
In my youth, after 12 years of Catholic religion classes at school, I asked myself if God really existed. But I didn't get to believe then.
As a young adult my life got filled with alcohol, codeine pills, pornography, visits to prostitutes and massage parlors. I consulted the western and Chinese horoscope, Feng Shui, and practiced yoga. For a few years I lived together with a girl friend, followed by some short term relations.
In 1995 I met a Salvadorian woman in a yoga class in Brussels. When she got pregnant we decided to marry and move to El Salvador.
We moved to El Salvador in 1996 and married there a week later. Our first daughter was born at the end of the year.
Early 1997 I was invited to a Spanish speaking chapter of Full Gospel Business Men's Fellowship International, an organization of Christian Business Men that brings people to Jesus by sharing their personal testimonies in the non-religious setting of a meal in a hotel or a restaurant.
In 1998 I was going to those weekly meetings, also started to assist to a Baptist church, bought a Bible in Spanish, reading in it at home and praying to God daily, and also watching Christian television.
My personal search of God culminated in a special event in august 1998. I woke up in the middle of the night and sat up straight in bed. I saw a white, bright light. In the middle of it I saw an arm extended towards me, with the hand beckoning me. At the same time I heard a voice inside my head that said to me: "Come". (Actually it was in Spanish : "Ven") The next day I noticed that God had left me a permanent reminder of this nightly calling: a small blind spot below in my right eye.
Sunday October 18, 1998 I was baptized by full immersion in water. The next friday I was at the National Convention of the Fellowship in the hotel Camino Real in San Salvador. At the end of the evening, when most people had already left, a man prayed for me. And suddenly my body started to roll over the floor and shrieks came out of my mouth. An evil spirit came out of me, just like recorded in the Bible story in Mark 1:25-26.
In May of 1999 our second daughter was born. Our son was born in 2001 on the day the New York twin towers fell. In September 2007 our third daughter was born. My family and I moved back to Belgium in 2010.
Now I have a new life, I'm married, father of four, and trying to serve the Lord Jesus in many different ways.
Find more details of my testimony on my website.
I am a Belgian citizen born near Brussels in 1966.
I graduated as Master of Information Technology, Software Design Option, on the thesis "Functional Abstraction to Support Rapid Compiler Construction" in 1988.
I worked in Belgium from 1988 to 1996 with several companies, mostly as an Analyst Programmer. In 1990 I started working with Oracle Database and PL/SQL.
In July 1996 I moved to El Salvador where I was employed in IT functions in a bank and for 10 years in a local utilities company. While there I started to work with Oracle Forms and Reports.
I moved back to Belgium in May 2010. Since my return I have again been employed in IT jobs, working with Oracle Databases and Development Tools.
You can view my profile on LinkedIn
If you were helped by the tips or otherwise want to help me along consider buying me a coffee. Thanks in advance.
This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported (CC BY-NC-ND 3.0) License.
Bart De Wolf