This link has been bookmarked by 313 people . It was first bookmarked on 02 Mar 2006, by Joel Liu.
-
06 Nov 09
-
19 Oct 09
-
14 Oct 09
-
20 Sep 09
-
08 Sep 09
-
15 Aug 09
-
09 May 09
-
08 Apr 09
-
01 Apr 09
-
25 Mar 09
-
24 Mar 09
-
19 Mar 09
-
18 Mar 09
-
26 Feb 09
-
06 Feb 09
-
05 Feb 09
-
23 Jan 09
-
23 Dec 08
-
16 Dec 08
-
12 Dec 08
-
07 Dec 08
-
02 Dec 08
-
29 Nov 08
-
25 Nov 08
-
22 Nov 08
-
21 Nov 08
-
20 Nov 08
-
18 Nov 08
-
17 Nov 08
-
How to be a Programmer: A Short, Comprehensive, and Personal Summary
-
-
16 Nov 08
-
13 Nov 08
-
02 Nov 08
-
How to be a Programmer: A Short, Comprehensive, and Personal Summary
-
-
24 Oct 08
-
20 Oct 08
-
25 Sep 08
-
22 Sep 08
-
19 Sep 08
-
Learn to Debug
-
Using a debugging tool,
- 40 more annotations...
-
-
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 -
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.
Programmers often succumb to this because they are
eager to please and not very good at saying no.
There are four defenses against this: -
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.
-
-
-
16 Sep 08
-
05 Sep 08
-
08 Jul 08
-
06 Jul 08
-
12 Jun 08
-
The first meaning of the verb to debug is to remove errors, but
the meaning that really matters is to see into the execution of a program by examining it
-
-
02 Jun 08
-
22 May 08
-
21 May 08
-
14 May 08
-
13 May 08
-
12 May 08
-
09 May 08
slith oneTo be a good programmer is difficult and noble. The hardest part of making real a collective vision of a software project is dealing with one's coworkers and customers. Writing computer programs is important and takes great intelligence and skill. But it
-
02 May 08
-
28 Apr 08
-
27 Apr 08
-
25 Apr 08
-
24 Apr 08
-
12 Apr 08
-
07 Apr 08
-
02 Apr 08
-
How to be a Programmer: A Short, Comprehensive, and Personal Summary
-
-
27 Mar 08
-
26 Mar 08
-
25 Mar 08
-
23 Mar 08
-
20 Mar 08
-
12 Mar 08
-
28 Feb 08
-
26 Feb 08
-
24 Feb 08
-
06 Feb 08
-
28 Jan 08
-
19 Jan 08
-
14 Jan 08
-
30 Nov 07
-
28 Nov 07
-
23 Nov 07
-
06 Nov 07
-
05 Nov 07
-
31 Oct 07
-
23 Oct 07
-
11 Oct 07
-
22 Sep 07
-
16 Sep 07
-
07 Sep 07
-
03 Aug 07
Hélène MartinTo be a good programmer is difficult and noble. The hardest part of making real a collective vision of a software project is dealing with one's coworkers and customers. Writing computer programs is important and takes great intelligence and skill. But it
-
21 Jul 07
-
16 Jul 07
-
15 Jul 07
-
10 Jul 07
-
05 Jul 07
-
19 Jun 07
-
15 May 07
-
How to be a Programmer: A Short, Comprehensive, and Personal Summary
-
-
14 May 07
-
04 May 07
-
27 Apr 07
-
26 Apr 07
Page Comments
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.