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

This link has been bookmarked by 351 people and liked by 1 people. It was first bookmarked on 02 Mar 2006, by Joel Liu.

22 Dec 09

Ido Magal
programming
15 Dec 09

Andre Dickson
programming howto development reference tutorial
11 Dec 09

Tomáš Čejka
howto programmer
06 Nov 09

karthik Lakshminarayanan
programming development software toread
19 Oct 09

Andrew Pickering
dev
14 Oct 09

Al Wong
20 Sep 09

ava tarantella
programming howto tutorial programmer software
08 Sep 09

Keith Demele
programming SU Tags
15 Aug 09

skiaec04 04
Programming
03 Jun 09

amodal1
programming howto reference scripting
09 May 09

Chris OConnor
An essay

.read programming
08 Apr 09

Khalid Al-Maghaslah
01 Apr 09

John Cuthbert
Health Computers programming howto development reference software tutorial tips delicious
25 Mar 09

Tim Teufel
programming
24 Mar 09

nishu goyal
19 Mar 09

Igor Rog
programming howto development reference tutorial
18 Mar 09

Jason Nelson
programming howto development reference software tutorial tips
26 Feb 09

Jitendra Vyas
c++
06 Feb 09

Shaney Zhong
howto
05 Feb 09

jamesqq smith
23 Jan 09

Steve Crampton
SU programming StumbleUpon - gooddoogles Computers
23 Dec 08

hg ye
debug ability

programming tips debugging
16 Dec 08

Maciek T
how to be a programmer

toread programming
12 Dec 08

Jisan Agharia
tutorial lifehacks productivity programming
07 Dec 08

Javier Neira
tutorial howto
02 Dec 08

nuburo white
MUST-DO
29 Nov 08

Ashok Srinivaspur
tbd
25 Nov 08

PhilGo20
tutorials software reference programming programmer productivity management
Ognyan Kulev
programming productivity tips software
22 Nov 08

Wendy Yao
programming software reference
21 Nov 08

Sharjeel Sayed
programming programmer tutorial tutorials tips
20 Nov 08

Rob Pfeifer
programming learning toread
18 Nov 08

Dr. Yevaud
programming development howto reference tutorial programmer toread software inspirational +recommend !tree!prfogramming!articles +readlater
17 Nov 08

Dai Barnes
Annotated link http://www.diigo.com/bookmark/http%3A%2F%2Fsamizdat.mines.edu%2Fhowto%2FHowToBeAProgrammer.html

programming development tutorial programmer
- How to be a Programmer: A Short, Comprehensive, and Personal Summary
16 Nov 08

rendong yang
SU programming 标签
13 Nov 08

luo bing
Programming Basics
02 Nov 08

sdgf
programming development howto reference programmer tutorial software toread
- How to be a Programmer: A Short, Comprehensive, and Personal Summary
24 Oct 08

Uma Shankar
tips software reference programming productivity management toread
23 Oct 08

infrared
by Robert L. Read

programming tutorial
20 Oct 08

Caesar _sa
StumbleUpon Computers
25 Sep 08

blcham
programming howto
22 Sep 08

camus1988
Imported Bookmarks
19 Sep 08

Edward Mark
programming programmer software development howto reference tutorial toread
- 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
  - 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.
16 Sep 08

Sathyam Karyala
Chris Brainard
Trailfire Programming
05 Sep 08

Blue Gene
productivity personalitydev interestingstuffs
08 Jul 08

Richard Morrison
development reference
06 Jul 08

Jack Smith
programming howto tips software
12 Jun 08

Fatih Akturk
Nasıl bir programcı olunur

programming development tutorial programmer software
- 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

Kosta Kliakhandler
development howto programming software
22 May 08

Vaidyanathan AG
21 May 08

James Jolly
programming howto tutorial toread hacking
14 May 08

Ed Brannin
programming software development reference tutorial
13 May 08

lauren pressley
programming howto toread
12 May 08

Brennan Moore
programming software development reference tutorial
09 May 08

slith one
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

programming
02 May 08

Kevin Horek
Programming
28 Apr 08

Peter Smith
programming howto development tips reference tutorial software tutorials documentation education
27 Apr 08

Dmytro Goncharov
howto development tutorial
25 Apr 08

Travis Benning
programming howto development tips reference coding advice
shawn morrissey
development developer programming tutorial howto
24 Apr 08

Steve Bargelt
programming howto reference
12 Apr 08

Richard P
Computer Science Python
07 Apr 08

gaudette
toread programming
02 Apr 08

Ankit Chaturvedi
- How to be a Programmer: A Short, Comprehensive, and Personal Summary
27 Mar 08

Avdi Grimm
algorithm code communication development e-texts education engineering guide language management methodology philosophy programming project theory to-read
26 Mar 08

Mr. Neopugg
imported bookmark programming
Matthew Llewellin
Tutorial howto programming
25 Mar 08

David Worrell
programming
António Carranca
programacao
23 Mar 08

Kevin Dethlefs-Moreno
Writing
20 Mar 08

btlgs2000 btlgs2000
advice programming suggestion tips
12 Mar 08

Lu Zheng
development programming
Paweł Kruszewski
developing ebook programming programowanie tutorial
28 Feb 08

isaac Mao
Programming Tutorial
26 Feb 08

FruFru FourOne
advice article blogs book books career code coding computer computers concept content design development ebook ebooks education free hack howto interesting learning lifehacks management philosophy programming psychology Reference ruby skills software tips
24 Feb 08

Pawel Rogowicz
toread
06 Feb 08

yogeshjangam
arch del.icio.us development howto imported notinbookmarks otr_vi programming reference tutorial
28 Jan 08

Lite
programming learning tips
19 Jan 08

Nick
development howto programming toread tutorial
14 Jan 08

Sarah Lewis
geek programming read_later
30 Nov 07

ento entotto
del.icio.us programming
28 Nov 07

Clay Fenlason
software development
geekydiv
howto programmer
23 Nov 07

venkatcc
Tech Geek Programming Developers Lifestyle
06 Nov 07

Vrt
znt
05 Nov 07

Frank Colcord
Ruby
31 Oct 07

Mike taylor
795a clientproject content
23 Oct 07

avjbookmarks
programming
11 Oct 07

Jeremy Gollehon
programming
22 Sep 07

TestFirst TestLast
good howto programming
16 Sep 07

Don
General
07 Sep 07

Frances Rosàs
An exhaustive guide to what being a programmer means

highlight programming
15 Aug 07

Geraldo Medrano
A Short, Comprehensive, and Personal Summary

programming education learning
03 Aug 07

Hélène Martin
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

algorithms book programming development software toread
21 Jul 07

fdediego
curiosidades
16 Jul 07

mrmccormack McCormack
best habits imported delicious practices programmer
15 Jul 07

Stephen McLaughlin
a be how programmer to
10 Jul 07

jeff6175
05 Jul 07

crowmobe