I am physicist by training, trade, and style of thinking ... . Programming and computers have been essential part of my work for more than thirty years, but I do not consider myself professional programmer.
It is not about the quality, it is about the approach. Making mathematical model of phenomena or process, scientist tries to be as accurate as possible he rarely thinks of computational efficiency. Mathematician designs the algorithm provided with fixed mathematical model. Programmer implements given algorithm. None of them tries to change the model. Imagine taxi driver on his day off, he drives to some place probably using all tricks of trade to do it in a most efficient way, exactly as on working day, but he has also additional options: he may decide to change destination or stay at some place for a while etc.
I do not sell software. I sell a solution to the given problem and my code is only a part of this solution. I build some mathematical model, derive equations which describe it, design the algorithm which solves these equations and implement the algorithm to get results in comprehensible way. Considering the big picture allows me not to waste efforts improving inessential parts but concentrate on real show stoppers. Suppose that a client asks for an algorithm for effective computation of matrix determinant, however he wants to do the calculations of inverse matrix, but actually needs is to solve some system of linear equations. Mathematically all three problems are equivalent but in numerical computation they are completely different unless matrix is small.
So this is SPIPS way.
- Working with real-life problems you will need the following:
- scientific and/or engineering knowledge;
- numerical analysis and programming;
- knowledge of modern computer architecture;
- source code (to have full power for optimization and tuning);
- experiment with different algorithms and implementations.
- Analyse critically what you read or hear. The complexity of modern machines and compilers is so great that theoretical estimations of algorithm complexity (bread and butter of computer scientists) may be misleading. There are too many layers of transformation from source code to hardware, so small changes in in the source code may change performance greatly. The speed of innovation in hardware and compilers is so high that well known and tuned algorithm may already become obsolete or at least suboptimal.
- See big picture!
- Your customers may have only vague understanding of computing but they are professionals in their field. Talk to them, be sure that you understand the problem, get as much information as possible concerning ranges of variables, relative probability of different scenarios and all that.
- Use the right instrument for the job!
- More complicated instruments are not necessary better. In many cases it is less work to write few tens of lines in C than to install large library and tune it properly.
- Don't copy code!
- It may be illegal.
- It may be dangerous.
- Even code written by a Great Master may be suboptimal for your specific case.
- Don't leave loose ends!
- Fix any problem as you find it. Small bug may be a symptom of serious flaw in algorithm design or understanding of the problem. Don't make quick and dirty workarounds. Find the reason and fix the problem properly.
- Don't be overprotective!
- Remember that a crash may be annoying but a wrong answer is disaster.
- Don't be a slave to the rules!
- Including those above.