Edward Mark's List: programming

• Learn to Debug
• Using a debugging tool,
• Logging --- Creating a permanent window into the programs  execution in the form of a log.
• Logging is the practice of writing a system so that it produces a sequence of informative records, called a log. Printlining is just producing a simple, usually temporary, log. Absolute beginners must understand and use logs because their knowledge of the programming is limited; system architects must  understand and use logs because of the complexity of the system. The amount of information that is provided by the log should be configurable, ideally while the program is running. In general, logs offer three basic advantages:

• • Logs can provide useful information about bugs that are hard  to reproduce (such as those that occur in the production environment but  that cannot be reproduced in the test environment). 

  •  Logs can provide statistics and data relevant to  performance, such as the time passing between statements. 

  •  When configurable, logs allow general information to be  captured in order to debug unanticipated specific problems  without having to modify and/or redeploy the code just to deal with those specific problems. 
• Before you try to make it faster,  you must build a mental model of why it is slow.
• There is a famous dictum that 90% of the time will be  spent in 10% of the code.  I would add to that the importance  of input/output expense (I/O) to performance issues.  Often most of the time is spent in I/O in one way or another.  Finding the expensive I/O and the expensive 10% of  the code is a good first step to building your mental model.
• Under time-to-market pressure,  it is both wise and effective to choose a solution that gets the job done simply and quickly, but less efficiently than some other solution.
• find the   bottlenecks
• As a rule of thumb you should think carefully before doing  anything unless you think it is going to make the system or a significant part of it at least twice as fast
• much better to have a few big changes.
• before you argue for the redesign  of a subsystem, you should ask yourself  whether or not your proposal will  make it five to ten time better.

• • Remove floating point operations. 

  •  Don't allocate new memory blocks unnecessarily. 

  •  Fold constants together. 

  •  Move I/O into a buffer. 

  •  Try not to divide. 

  •  Try not to do expensive typecasts. 

  •  Move a pointer rather than recomputing indices. 
• Clear, efficient code is better than code that requires an understanding of a particular platform.
• building a fast system is often more a question of improving I/O than improving the code in some tight loop
• There are two very fundamental techniques to improving I/O: caching and representation. Caching is avoiding I/O (generally avoiding  the reading of some abstract value) by storing a copy of that value locally so no I/O is performed to get the value.  The first key to caching is to make it crystal clear which data is the master and which are copies. There is only one master---period. Caching brings with it the danger that the copy is sometimes can't reflect changes to the master instantaneously.
• Garbage collection is wonderful:
• look for and fix memory leaks early
• reference counting
• Try, try, try to reproduce the bug in a controlled way.  If you can't reproduce it, set a trap for it by building a logging system, a special one if you have to,  that can log what you guess you need when it really does occur.

• To learn how to design software, study the action of a mentor by being physically present when they are designing. Then study  well-written pieces of software. After that, you can read some books on the latest design techniques. 

    Then you must do it yourself. Start with a small project.  When you are finally done, consider how the design failed or  succeeded and how you diverged from your original conception. They move on to larger projects, hopefully in conjunction with  other people. Design is a matter of judgment that takes years  to acquire. A smart programmer can learn the basics adequately in two months and can improve from there.
• When asked to provide an estimate of something big,  the most honest thing to do is to stall.
• Restate that meaning as the first and  last part of your written estimate. Prepare a written  estimate by deconstructing the task into progressively smaller  subtasks until each small task is no more than a day; ideally at most in length.  The most important thing is not to leave anything out. For instance, documentation,  testing, time for planning, time for communicating with other groups, and vacation time are all very important.
• I know good engineers who pad estimates implicitly, but I recommend that you do not. One of the results of padding is trust in you may be depleted.
• Pad explicitly instead. If a task will probably take one  day---but might take ten days if your approach doesn't  work---note this somehow in the estimate if you can; if not, at least do an average weighted by your estimates of the probabilities.  Any risk factor that you can identify and assign an  estimate to should go into the schedule.
• There are of course, unknown unknowns, or unk-unks.  Unk-unks by definition cannot be estimated individually. You can try to create a global line item for all unk-unks, or handle them in some other way that you communicate to your boss.
• Extreme Programming
• a little good documentation is best
• Golden Rule is all you really need: ``Do unto others as you would have them do unto you.''
• documenting code itself, as opposed  to producing documents that can actually be read by non-programmers, the best programmers I've ever known hold a universal sentiment: write self-explanatory code and only document code in the places that you cannot make it clear by writing the code itself.

• •  Writing code knowing that someone will have to read it; 

  •  Applying the golden rule; 

  •  Choosing a solution that is straightforward,  even if you could get by with another solution faster; 

  •  Sacrificing small optimizations that obfuscate the code; 

  •  Thinking about the reader and spending some of your precious time to make it easier on her; and 
• Not ever using a function name like ``foo'',``bar'', or ``doIt''!
• you can try to wall off the parts that are particularly bad so that they may be redesigned independently.
• Use Source Code Control
• they encourage thinking about the code as a growing, organic system.  Since each change is marked as a  new revision with a new name or number, one begins to think of the  software as a visibly progressive series of improvements.
• Committing a mistake that slows down your teammates is a serious error; it is often taboo.
• Use assertion checking and test drivers whenever possible.
• Take Breaks when Stumped
• 60 hours a week is common, and 50 is pretty  much a minimum

• Programmers often succumb to this because they are  eager to please and not very good at saying no.  There are four defenses against this:  

  •  Communicate as much as possible with everyone in the company so that  no one can mislead the executives about what is going on,  

  •  Learn to estimate and schedule defensively and explicitly and give everyone visibility into what the schedule is and where it stands, 

  •  Learn to say no, and say no as a team when necessary, and 

  •  Quit if you have to. 
• You should go home if you are thinking suicidal thoughts. You should take a break or go home if you think homicidal thoughts for more than a  few seconds. You should send someone home if they show serious mental malfunctioning or signs of mental illness beyond mild depression. If you are tempted to be dishonest or deceptive in a way that you normally are not due to fatigue, you should take a break. Don't use cocaine or amphetamines to combat fatigue. Don't abuse caffeine.
• Difficult people  are often extremely intelligent and have something very useful to say.  It is critical that you listen and understand the difficult person without prejudice caused by the person.

40 more annotations...