This link has been bookmarked by 1057 people and liked by 4 people. It was first bookmarked on 06 Jul 2010, by someone privately.
Sultan Al-Sadaka , Nwecksler , Andre Dickson , Oleg Krymchakov
-
18 Jun 17
kevinoempty
-
29 Jul 15
-
22 Jul 15
-
14 May 15
-
13 May 15
-
12 May 15
-
25 Feb 15
-
04 Dec 14
-
How to be a Programmer: A Short, Comprehensive, and Personal Summary
-
-
23 Oct 14
-
10 Sep 14
-
The excellent books: The Pragmatic Programmer [Prag99], Code Complete [CodeC93], Rapid Development [RDev96], and Extreme Programming Explained [XP99] all teach computer programming and the larger issues of being a good programmer.
-
The common ways of looking into the ‘innards’ of an executing program can be categorized as:
-
If there is a single key to debugging is to use the divide and conquer technique on the mystery.
-
But what is the middle of a mystery? There is where true creativity and experience comes in.
-
To a true beginner, the space of all possible errors looks like every line in the source code. You don't have the vision you will later develop to see the other dimensions of the program, such as the space of executed lines, the data structure, the memory management, the interaction with foreign code, the code that is risky, and the code that is simple. For the experience programmer, these other dimensions form an imperfect but very useful mental model of all the things that can go wrong. Having that mental model is what helps one find the middle of the mystery effectively.
-
Attempt to employ the scientific method of changing one thing and only one thing at a time.
-
Logging is the practice of writing a system so that it produces a sequence of informative records, called a log.
-
In general, logs offer three basic advantages:
-
making what is output configurable is very useful. Typically, each record in the log will identify its position in the source code, the thread that executed it if applicable, the precise time of execution, and, commonly, an additional useful piece of information, such as the value of some variable, the amount of free memory, the number of data objects, etc. These log statements are sprinkled throughout the source code but are particularly at major functionality points and around risky code. Each statement can be assigned a level and will only output a record if the system is currently configured to output that level. You should design the log statements to address problems that you anticipate. Anticipate the need to measure performance.
-
-
02 Sep 14
-
14 Aug 14
-
04 Aug 14
-
17 Jul 14
-
07 Jul 14
-
11 Jun 14
-
08 Feb 14
-
25 Jan 14
-
Other examples include doing unnecessary I/O in inner loops, leaving in debugging statements that are no longer needed, unnecessary memory allocation, and, in particular, inexpert use of libraries and other subsystems that are often poorly documented with respect to performance. This kind of improvement is sometimes called low-hanging fruit, meaning that it can be easily picked to provide some benefit.
-
-
20 Dec 13
-
Attempt to employ the scientific method of changing one thing and only one thing at a time. The best process for this is to be able to easily reproduce the bug, then put your fix in place, and then rerun the program and observe that the bug no longer exists.
-
Deadlock is the inability to proceed because of improper synchronization or resource demands. Starvation is the failure to schedule a component properly.
-
Often, the bottlenecks in performance will be an example of counting cows by counting legs and dividing by four, instead of counting heads.
-
If you can't find away around it, then you can optimize the loop. This is simple; move stuff out. In the end, this will require not only ingenuity but also an understanding of the expense of each kind of statement and expression.
-
A classic mistake is to use a hash table as a cache and forget to remove the references in the hash table. Since the reference remains, the referent is noncollectable but useless. This is called a memory leak
-
define an upper bound on the number of objects you will need at one time.
-
The objects you need can be allocated and released inside this buffer in a set rotation pattern, so it is sometimes called a ring buffer. This is usually faster than heap allocation.
-
study the action of a mentor by being physically present when they are designing. Then study well-written pieces of software.
-
First, try to be very clear about your hypothesis, or the assertion that you are trying to test. It also helps to write the hypothesis down, especially if you find yourself confused or are working with others.
-
unknown unknowns, or unk-unks
-
You should ask people for a little bit of their wisdom and judgment whenever you honestly believe they have something to say.
-
you can't be a good intermediate programmer without knowing basic computational complexity theory.
-
Embedding a programming language into a system has an almost erotic fascination to a programmer.
-
-
13 Nov 13
-
12 Nov 13
-
04 Nov 13
-
03 Nov 13
-
29 Oct 13
-
28 Oct 13
-
27 Oct 13
-
Lyall Hamiltonhttps://news.ycombinator.com/item?id=6620536
-
The excellent books: The Pragmatic Programmer [Prag99], Code Complete [CodeC93], Rapid Development [RDev96], and Extreme Programming Explained [XP99] all teach computer programming and the larger issues of being a good programmer. The essays of Paul Graham[PGSite] and Eric Raymond[Hacker] should certainly be read before or along with this arti
-
-
-
Assume responsibility in excess of your authority
-
If you want to become a better programmer, ask someone you admire how you can become like them. You can also ask your boss, who will know less but have a greater impact on your career.
-
Good people want to be hired for their skills, not where they worked last or what school they went to or some other inessential characteristic.
-
Is it well encapsulated so that the risk to other systems is low and the overall increase in complexity and maintenance cost is low?
Is the benefit startling (for example, a factor of two in a mature system or a factor of ten in a new system)?
Will you be able to test and evaluate it effectively?
The three most important considerations for the potential computer science technique are:
-
If all else fails, apologize to those who have to do the boring task, but under no circumstances allow them to do it alone. At a minimum assign a team of two to do the work and promote healthy teamwork to get the task done.
-
-
21 Oct 13
-
19 Aug 13
-
10 Jul 13
-
02 Jul 13
-
29 Jun 13
-
15 Jun 13
-
05 May 13
-
24 Apr 13
-
Learn to Debug
-
Debugging is the cornerstone of being a programmer. 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. A programmer that cannot debug effectively is blind
-
To get visibility into the execution of a program you must be able to execute the code and observe something about it. Sometimes this is visible, like what is being displayed on a screen, or the delay between two events. In many other cases, it involves things that are not meant to be visible, like the state of some variables inside the code, which lines of code are actually being executed, or whether certain assertions hold across a complicated data structure. These hidden things must be revealed.
-
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.
The common ways of looking into the ‘innards’ of an executing program can be categorized as:
-
Debugging tools are wonderful when they are stable and available, but the printlining and logging are even more important. Debugging tools often lag behind language development, so at any point in time they may not be available. In addition, because the debugging tool may subtly change the way the program executes it may not always be practical. Finally, there are some kinds of debugging, such as checking an assertion against a large data structure, that require writing code and changing the execution of the program. It is good to know how to use debugging tools when they are stable, but it is critical to be able to employ the other two methods.
-
How to Debug by Splitting the Problem Space
-
If there is a single key to debugging is to use the divide and conquer technique on the mystery.
-
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. But what is the middle of a mystery? There is where true creativity and experience comes in.
-
You don't have the vision you will later develop to see the other dimensions of the program, such as the space of executed lines, the data structure, the memory management, the interaction with foreign code, the code that is risky, and the code that is simple.
-
To a true beginner, the space of all possible errors looks like every line in the source code.
-
For the experience programmer, these other dimensions form an imperfect but very useful mental model of all the things that can go wrong. Having that mental model is what helps one find the middle of the mystery effectively.
-
Once you have evenly subdivided the space of all that can go wrong, you must try to decide in which space the error lies
-
How to Remove an Error
-
In fixing a bug, you want to make the smallest change that fixes the bug. You may see other things that need improvement; but don't fix those at the same time. Attempt to employ the scientific method of changing one thing and only one thing at a time
-
The best process for this is to be able to easily reproduce the bug, then put your fix in place, and then rerun the program and observe that the bug no longer exists.
-
How to Debug Using a Log
-
-
20 Apr 13
-
01 Apr 13
Andrey KarpovTo 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.
-
21 Feb 13
-
23 Jan 13
-
16 Jan 13
-
15 Jan 13
-
13 Jan 13
-
11 Jan 13
-
23 Nov 12
-
19 Nov 12
-
13 Nov 12
-
30 Sep 12
Valentin BoraTo 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.
-
06 Aug 12
Konstantinos" 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."
-
29 Jul 12
-
01 Jun 12
-
23 May 12
-
18 May 12
-
vvrbancSAS survival guide za programere. Tehnički i socijalni aspekt. Kratko i jezgrovito.
-
17 May 12
-
16 May 12
-
15 May 12
-
09 May 12
-
08 May 12
-
Y A"renumeration"
-
18 Apr 12
-
17 Apr 12
Jayanti Srivastva"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"
-
16 Apr 12
-
The excellent books: The Pragmatic Programmer [Prag99], Code Complete [CodeC93], Rapid Development [RDev96], and Extreme Programming Explained [XP99]
-
The essays of Paul Graham[PGSite] and Eric Raymond[Hacker
-
by emphasizing social problems and comprehensively summarizing the entire set of necessary skills as I see them.
-
I use the words business, company, and tribe, synonymously
-
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
-
A programmer that cannot debug effectively is blind
-
Idealists that think design, or analysis, or complexity theory, or whatnot, are more fundamental are not working programmers.
-
Often this visibility can only be gained by experimentation, that is, debugging.
-
But there will still arise places where the code does not conform to the documentatio
-
Inevitably, this means some assumption you are making is not quite correct, or some condition arises that you did not anticipate
-
debugging tool
-
Printlining
-
Logging
-
Debugging tools are wonderful when they are stable and available, but the printlining and logging are even more important
-
Debugging requires creativity and ingenuity
-
s to use the divide and conquer technique on the mystery
-
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,
-
But what is the middle of a mystery?
-
You don't have the vision you will later develop to see the other dimensions of the program
-
For the experience programmer, these other dimensions form an imperfect but very useful mental model of all the things that can go wrong
-
Once you have evenly subdivided the space of all that can go wrong, you must try to decide in which space the error lies.
-
‘Which single unknown line makes my program crash?’
-
Usually you will not be so lucky as to know that the error exists in a single line, or even a single block
-
Attempt to employ the scientific method of changing one thing and only one thing at a time.
-
Of course, sometimes more than one line must be changed, but you should still conceptually apply a single atomic change to fix the bug.
-
Logging is the practice of writing a system so that it produces a sequence of informative records, called a log. Pri
-
Absolute beginners must understand and use logs
-
system architects must understand and use
-
Logs can provide useful information about bugs that are hard to reproduce
-
Logs can provide statistics and data relevant to performance
-
in order to debug unanticipated specific problems
-
The amount to output into the log is always a compromise between information and brevity
-
Each statement can be assigned a level and will only output a record if the system is currently configured to output that level
-
Learning
-
in practice performance problems are a little different and a little easier than debugging in general.
-
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
-
Often most of the time is spent in I/O in one way or another
-
wall--clock time
-
There are many dimensions to the performance of a computer system, and many resources consumed
-
memory, network bandwidth, database
-
Deadlock
-
Contention for shared resources that are synchronized can cause deadlock and starvation
-
Starvation
-
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. However, performance is a part of usability, and often it must eventually be considered more carefully.
-
Most software projects can be made with relatively little effort 10 to 100 times faster than they are at the they are first released
-
bottlenecks
-
The key to improving the performance of a very complicated system is to analyze it well enough to find the
-
After you've made a two-fold improvement in something, you need to at least rethink and perhaps reanalyze to discover the next-most-expensive bottleneck in the system, and attack that to get another two-fold improvement.
-
doing unnecessary I/O in inner loops
-
inexpert use of libraries and other subsystems that are often poorly documented with respect to performance
-
low-hanging fruit
-
What do you do when you start to run out of low-hanging fruit? Well, you can reach higher, or chop the tree down
-
How to Optimize Loops
-
Here are some suggestions:
-
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.
-
How to Deal with I/O Expense
-
Therefore building a fast system is often more a question of improving I/O than improving the code in some tight loop, or even improving an algorithm
-
Caching is avoiding I/O
-
There are two very fundamental techniques to improving I/O: caching and representation
-
The first key to caching is to make it crystal clear which data is the master and which are copies
-
Representation is the approach of making I/O cheaper by representing data more efficiently
-
A third technique that is sometimes possible is to improve the locality of reference by pushing the computation closer to the data
-
ow to Recognize When to Go Home
-
Computer programming is an activity that is also a culture. The unfortunate fact is that it is not a culture that values mental or physical health very much
-
I don't think you can trust all the stories you hear, but I think 60 hours a week is common, and 50 is pretty much a minimum. This means that often much more than that is required
-
You have to recognize when to go home, and sometimes when to suggest that other people go home
-
Beyond 60 hours a week is an extraordinary effort for me
-
I am sure, however, that it is stupid to work so much that you are getting little out of that extra hour you work
-
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.
-
here is a certain amount of mental inertia associated with getting warmed-up to a problem and deeply involved in it
-
ach programmer needs to do whatever it takes to procure efficient work periods, such as reserving certain days in which you will attend only the most critical meetings.
-
Since I have children, I try to spend evenings with them sometimes. The rhythm that works best for me is to work a very long day, sleep in the office or near the office
-
hen go home early enough the next day to spend time with my children before they go to bed.
-
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
-
-
14 Mar 12
-
03 Feb 12
-
02 Feb 12
-
30 Jan 12
-
19 Jan 12
-
11 Jan 12
-
08 Jan 12
-
15 Dec 11
-
15 Nov 11
-
16 Oct 11
-
27 Sep 11
-
22 Sep 11
-
20 Sep 11
-
12 Sep 11
-
05 Sep 11
-
24 Aug 11
-
21 Aug 11
-
06 Aug 11
-
23 Jul 11
-
18 Jul 11
-
10 May 11
-
29 Apr 11
-
12 Apr 11
-
06 Apr 11
-
02 Apr 11
Fernando Bernall" divide and conquer"
-
11 Mar 11
-
16 Feb 11
-
15 Feb 11
Page Comments
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.