Skip to main content
Short URL(SRL) : http://srl.diigo.com/12c7

How to be a Programmer: A Short, Comprehensive, and Personal ...

Popularity Report

Total Popularity Score: 0
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Rank

Related Lists

Bookmark History

Saved by 242 people (-72 private), first by anonymouse user on 2006-03-02


Public Comment

on 2006-07-02 by secretgeek

This really is very good!

on 2006-07-04 by noondesertsky

How to be a Programmer: A Short, Comprehensive, and Personal Summary

on 2006-08-02 by inetguy

How to be a Programmer: A Short, Comprehensive, and Personal Summary

on 2006-08-03 by freality

How to be a Programmer: A Short, Comprehensive, and Personal Summary

on 2006-08-12 by rogerkondrat

A great summary of skills and techniques for the everyday.

on 2006-10-23 by tsangal

In this essay I attempt to summarize as concisely as possible those things that I wish someone had explained to me when I was twenty-one.

on 2006-10-25 by slackorama

A Short, Comprehensive, and Personal Summary By Robert L. Read. Things he wishes that he was told when he was 21.

on 2006-11-26 by electracool

programming tips

Public Sticky notes

How to be a Programmer: A Short, Comprehensive, and Personal Summary

Highlighted by shingonoide

Often this visibility can only be gained by experimentation, that is, debugging.

Highlighted by paulswartz

Debugging is about the running of programs

Highlighted by paulswartz

The common ways of looking into the ‘innards’ of an executing program can be categorized as:

  • Using a debugging tool,

  • Printlining --- Making a temporary modification to the program, typically adding lines that print information out, and

  • Logging --- Creating a permanent window into the programs execution in the form of a log.

Highlighted by paulswartz

If there is a single key to debugging is to use the divide and conquer technique on the mystery.

Highlighted by paulswartz

The key to divide and conquer as a debugging technique is the same as it is for algorithm design: as long as you do a good job splitting the mystery in the middle, you won't have to split it too many times, and you will be debugging quickly.

Highlighted by paulswartz

I've intentionally separated the act of examining a program's execution from the act of fixing an error.

Highlighted by paulswartz

In fixing a bug, you want to make the smallest change that fixes the bug.

Highlighted by paulswartz

To 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 is really child's play compared to everything else that a good programmer must do to make a software system that succeeds for both the customer and myriad colleagues for whom she is partially responsible. In this essay I attempt to summarize as concisely as possible those things that I wish someone had explained to me when I was twenty-one.

Highlighted by turbotom

Before you try to make it faster, you must build a mental model of why it is slow.

Highlighted by paulswartz

design is an art, not a science.

Highlighted by paulswartz

The late, great Edsger Dijkstra has eloquently explained that Computer Science is not an experimental science[ExpCS] and doesn't depend on electronic computers. As he puts it referring to the 1960s[Knife],

...the harm was done: the topic became known as “computer science”---which, actually, is like referring to surgery as “knife science” --- and it was firmly implanted in people's minds that computing science is about machines and their peripheral equipment.

Highlighted by paulswartz

How to be a Programmer

Highlighted by quarkonics

assign your own meaning to the code

Highlighted by paulswartz

How to be a Programmer: A Short, Comprehensive, and Personal Summary

Highlighted by alpachino

How to be a Programmer: A Short, Comprehensive, and Personal Summary

Highlighted by daibarnes

How to be a Programmer: A Short, Comprehensive, and Personal Summary

Highlighted by buzzart

How to be a Programmer: A Short, Comprehensive, and Personal Summary

Highlighted by hunter107

Learn to Debug

Highlighted by gokukiller

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

Highlighted by fakturk

Using a debugging tool,

Highlighted by gokukiller

Logging --- Creating a permanent window into the programs execution in the form of a log.

Highlighted by gokukiller

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:

Highlighted by gokukiller

  • 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.

    • Highlighted by gokukiller

    Before you try to make it faster, you must build a mental model of why it is slow.

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    find the bottlenecks

    Highlighted by gokukiller

    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

    Highlighted by gokukiller

    much better to have a few big changes.

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

  • 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.

    • Highlighted by gokukiller

    Clear, efficient code is better than code that requires an understanding of a particular platform.

    Highlighted by gokukiller

    building a fast system is often more a question of improving I/O than improving the code in some tight loop

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    Garbage collection is wonderful:

    Highlighted by gokukiller

    look for and fix memory leaks early

    Highlighted by gokukiller

    reference counting

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    When asked to provide an estimate of something big, the most honest thing to do is to stall.

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    Extreme Programming

    Highlighted by gokukiller

    a little good documentation is best

    Highlighted by gokukiller

    Golden Rule is all you really need: ``Do unto others as you would have them do unto you.''

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

  • 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

    • Highlighted by gokukiller

    Not ever using a function name like ``foo'',``bar'', or ``doIt''!

    Highlighted by gokukiller

    you can try to wall off the parts that are particularly bad so that they may be redesigned independently.

    Highlighted by gokukiller

    Use Source Code Control

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    Committing a mistake that slows down your teammates is a serious error; it is often taboo.

    Highlighted by gokukiller

    Use assertion checking and test drivers whenever possible.

    Highlighted by gokukiller

    Take Breaks when Stumped

    Highlighted by gokukiller

    60 hours a week is common, and 50 is pretty much a minimum

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller

    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.

    Highlighted by gokukiller