Radar Basics by radartutorial.eu

Radar Basics

• Radar measurement of range, or distance, is made possible because of the properties of radiated electromagnetic energy.
• The electromagnetic waves are reflected if they meet an electrically leading surface. If these reflected waves are received again at the place of their origin, then that means an obstacle is in the propagation direction.
• Electromagnetic energy travels through air at a constant speed, at approximately the speed of light. This constant speed allows the determination of the distance between the reflecting objects and the radar site by measuring the running time of the transmitted pulses.
• This energy normally travels through space in a straight line, and will vary only slightly because of atmospheric and weather conditions.
• The electronic principle on which radar operates is very similar to the principle of sound-wave reflection. If you shout in the direction of a sound-reflecting object, you will hear an echo. If you know the speed of sound in air, you can then estimate the distance and general direction of the object. The time required for an echo to return can be roughly converted to distance if the speed of sound is known.
• Radar uses electromagnetic energy pulses in much the same way [as a sound echo]. The radio-frequency energy is transmitted to and reflected from the reflecting object. A small portion of the reflected energy returns to the radar set. This returned energy is called an ECHO, just as it is in sound terminology. Radar sets use the echo to determine the direction and distance of the reflecting object.
• The term RADAR is an acronym made up of the words: Radio Aim Detecting And Ranging.
• Modern radar can extract widely more information from a target's echo signal than its range. But the calculating of the range by measuring the delay time is one of its most important functions.
• The radar antenna illuminates the target with a microwave signal, which is then reflected and picked up by a receiving device. The electrical signal picked up by the receiving antenna is called echo or return. The radar signal is generated by a powerful transmitter and received by a highly sensitive receiver.
• All targets produce a diffuse reflection, i.e. it is reflected in a wide number of directions. The reflected signal is also called scattering. Back-scatter is the term given to reflections in the opposite direction to the incident rays.
• The radar transmitter produces the short duration high-power RF pulses of energy that are shot into space by the antenna.
• The duplexer alternately switches the antenna between the transmitter and receiver so that only one antenna need be used. This switching is necessary because the high-power pulses of the transmitter would destroy the receiver if energy were allowed to enter the receiver.
• The receivers amplify and demodulate the received RF-signals. The receiver provides video signals on the output.
• The antenna transfers the transmitter energy to signals in space with the required distribution and efficiency. This process is applied in an identical way on reception.
• The indicator should present to the observer a continuous, easily understandable, graphic picture of the relative position of radar targets.
• The radar transmits a short radio pulse with very high pulse power. This pulse is focused in one direction only by the directivity of the antenna, and propagates in this given direction with the speed of light.
• The actual range of a target from the radar is known as slant range. Slant range is the line of sight distance between the radar and the object illuminated. While ground range is the horizontal distance between the emitter and its target and its calculation requires knowledge of the target's elevation.
• Since the waves travel to a target and back, the round trip time is divided by two in order to obtain the time the wave took to reach the target.
• Range is the distance from the radar site to the target measured along the line of sight.
• The angular determination of the target is determined by the directivity of the antenna.
• Directivity, sometimes known as the directive gain, is the ability of the antenna to concentrate the transmitted energy in a particular direction. An antenna with high directivity is also called a directive antenna. By measuring the direction in which the antenna is pointing when the echo is received, both the azimuth and elevation angles form the radar to the object or target can be determined.
• The accuracy of angular measurement is determined by the directivity, which is a function of the size of the antenna.
• Radar units usually work with very high frequencies. Reasons for this are:
• quasi-optically propagation of these waves
• High resolution (the smaller the wavelength, the smaller the objects the radar is able to detect)
• High the frequency, smaller the antenna size at the same gain
• The antenna s of most radar systems are designed to radiate energy in a one-directional lobe or beam that can be moved in bearing simply by moving the antenna.
• In actual practice, search radar antennas move continuously; the point of maximum echo, determined by the detection circuitry or visually by the operator, is when the beam points direct at the target.
• It becomes obvious that we cannot send out another pulse until a time windows has passed, in which we expect to see a return echo.
• The maximum range at which a target can be located so as to guarantee that the leading edge of the received back-scatter from the target is received before transmission begins for the next pulse. This range is called maximum unambiguous range or the first range ambiguity.
• The pulse-repetition frequency (PRF) determines this maximum unambiguous range of a given radar before ambiguities start to occur.
• The pulse repetition time (PRT) of the radar is important when determining the maximum range because target return-times that exceed the PRT of the radar system appear at incorrect locations (ranges) on the radar screen. Returns that appear at these incorrect ranges are referred to as ambiguous returns, second-sweep echoes, or second-time around echoes.
• Mono-static pulse radar sets use the same antenna for transmitting and receiving. During the transmitting time the radar cannot receive: the radar is switched off using an electronic switch, called a duplexer.
• The minimal measuring range is the minimum distance which the target must have to be detected. Therein, it is necessary that the transmitting pulse leaves the antenna completely and the radar unit must switch on the receiver.
• The elevation angle is the angle between the horizontal plane and the line of sight, measured in the vertical plane.
• Altitude or height-finding search radars use a very narrow beam in the vertical plane. The beam is mechanically or electronically scanned in elevation to pinpoint targets. If an echo signal is detected in the receiver, then the current elevation angle is equal to the direction of the antenna pattern.
• The height of a target over the earth's surface is called height or altitude.
• If high-frequency energy is emitted by an isotropic radiator, than the energy propagates uniformly in all directions. Areas with the same power density form spheres around the radiator. The same amount of energy spread out on an incremented spherical surface at an incremented spherical radius. That means: the power density on the surface of a sphere is inversely proportional to the square of the radius of the sphere.
• [Antenna] gain is obtained by directional radiation of the power.
• The target detection isn't only dependent on the power density at the target position, but also on how much power is reflected in the direction of the radar. In order to determine the useful reflected power, it is necessary to know the radar cross section. This quantity depends on several factors, but it is true to say that a bigger area reflects more power than a smaller area.
• In order to double the range, the transmitted power would have to be increased by 16-fold!
• For every receiver there is a certain receiving power as of which the receiver can work at all. This smallest workable receive power is frequently often called MDS--Minimum Discernible Signal-- in radar technology.
• If one quadruples the antenna gain, it will double the maximum range.
• Frequency diversity typically uses two transmitters operating in tandem to illuminate the target with two separate frequencies.
• An important advantage of the multiple frequency procedure is the high jamming immunity of the procedure.
• The linear addition of the signals of different frequency components increases the probability of detection of the target. However, this brings disadvantages with regard to the jamming immunity like a radar with a single TX-frequency only.
• Accuracy is the degree of conformance between the estimated or measured position and/or the velocity of a platform at a given time and its true position or velocity.
• Accuracy should not be confused with resolution.
• The target resolution of a radar is its ability to distinguish between targets that are very close in either range or bearing.
• Weapons-control radar, which requires great precision, should be able to distinguish between targets that are only yards apart.
• Search-radar is usually less precise and only distinguishes between targets that are hundreds of yards or even miles apart.
• Resolution is usually divided into two categories: range resolution and bearing resolution.
• Range resolution is the ability of a radar system to distinguish between two or more targets on the same bearing but at different ranges. The degree of range resolution depends on the width of the transmitted pulse, the types and sizes of targets, and the efficiency of the receiver and indicator. Pulse width is the primary factor in range resolution.
• If the spacing between two aircraft is too small, then the radar "see" only one target.
• Angular resolution is the minimum angular separation at which two equal targets can be separated when at the same range.
• The smaller the beam width, the higher the directivity of the radar antenna.
• The range and angular resolutions lead to the resolution cell. The meaning of the cell is very clear: unless one can rely on eventual different Doppler shifts it is impossible to distinguish two targets which are located inside the same resolution cell.
• The broader the spectrum of the transmitted pulse and the narrower the aperture angle are, the smaller the resolution cell is and the higher the interference immunity of the radar station is.
• A radar is not designed to detect aircraft directly above the radar antenna. This gap is known as the cone of silence.
• Despite a large number of radars organized in a radar network radar, a space will always remain in extremely low altitude at which an aircraft can fly below the radar. In practice, however, this is for the pilot not as easy as it seems as he must know exactly where to fly to remain as far away from each radar.
• Most processes in pulsed radar are time-dependent.
• The time that an antenna beam spend on a target is called dwell time.
• The value of hits per scan says how many echo signals per single target during every antenna rotation are received.The hit number stands for the number of the received echo pulses of a single target per antenna turn.
• The higher the frequency of a radar system, the more it is affected by weather conditions such as rain or clouds. But the higher the transmitted frequency, the better is the accuracy of the radar system.
• The higher the frequency, the higher is the atmospheric absorption and attenuation of the waves.
• An imaging Radar forms a picture of the observed object or area.
• A pulse radar is a radar device that emits short and powerful pulses and in the silent period receives the echo signals. In contrast to the continuous wave radar the transmitter is turned off before the measurement is finished.
• Primary Surveillance Radar (PSR) works with passive echoes. The transmitted high-frequency impulses are reflected by the target and then received by the same radar unit.
• Secondary Surveillance Radar (SSR) work with active answer signals. The secondary radar units transmits and also receives high-frequency impulses. The signals aren't simply reflected, but received by the target by means of a transponder which receives and processes the pulse. After this the target answers with another frequency.
• A Continuous Wave (CW) radar transmits a high-frequency signal continuously. The echo signal is received and processed permanently. On has to resolve two problems with this principle:
• prevent a direct connection of the transmitted energy into the receiver
• assign the received echoes to a time system to be able to run time measurements
• LPI radar (Low Probability of Intercept) is a class of radar systems that possess certain performance characteristics that make them nearly undetectable by today's intercept receivers. LPI features prevent the radar from tripping off alarm systems or passive radar-detection equipment in a target.
• Synthetic Aperture Radar (SAR) is a coherent mostly airborne or space-borne side-looking radar system which utilizes the flight path of the platform to simulate an extremely large antennas or aperture electronically, and that generates high-resolution remote sensing imagery.

Guide to x86 Assembly by University of Virginia

Guide to x86 Assembly

• MASM (Microsoft Macro Assembler) uses the standard Intel syntax for writing x86 assembly code.
• The full x86 instruction set is large and complex.
• Modern x86 processors have eight 32-bit general purpose registers. The register names are mostly historical.
• Whereas most of the registers have lost their special purposes in the modern instruction set, by convention, two are rese4veved for special purposes--the stack pointer (ESP) and the base pointer (EBP).
• You can declare static data regions (analogous to global variables) in x86 assembly using special assembler directives for this purpose. Data declarations should be preceded by the .DATA directive. Following this directive, the directives DB, DW, and DD can be used to declare one, two , and four byte data locations, respectively. Declared locations can be labeled with names for later reference--this is similar to declaring variable by name, but abides by some lower level rules.
• Unlike in high level languages where arrays can have many dimensions and are accessed by indices, arrays in x86 assembly language are simply a number of cells located contiguously in memory.
• The DUP directive tells the assembler to duplicate an expression a given number of times.
• Modern x86-compatible processors are capable of addressing up to 2^32 bytes of memory: memory addresses are 32-bits wide.
• In general, the intended size of the data item at a given memory address can be inferred from the assembly code instruction in which it is referenced.
• Machine instructions generally fall into three categories: data movement, arithmetic/logic, and control-flow.
• The mov instruction copies the data item referred to by its second operand into the location referred to by its first operand.
• The push instruction places its operand onto the top of the hardware supported stack in memory. Specifically, push first decrements ESP by 4, then places its operand into the contents of the 32-bit location at address [ESP].
• ESP (the stack pointer) is decremented by push since the x86 stack grows down--i.e. the stack grows from high addresses to lower addresses.
• The pop instruction removes the 4-byte data element from the top of the hardware-supported stack into the specific operand. It first moves the 4 bytes located at memory location [ESP] into the specified register or memory location, and then increments ESP by 4.
• The lea instruction places the address specified by its second operand into the register specified by its first operand. Note, the contents of the memory location are not loaded, only the effective address is computed and placed into the register.
• The add instruction adds together its two operands, storing the result in its first operand.
• The sub instruction stores in the value of its first operand the result of subtracting the value of its second operand from the value of its first operand.
• The inc instruction increments the contents of its operand by one.
• The dec instruction decrements the contents of its operand by one.
• These instructions [and, or, xor] perform the specified logical operation on their operands, placing the result in the first operand location.
• not logically negates the operand contents (that is, flips all bit values in the operand).
• neg performs the two's complement negation of the operand contents.
• This instructions [shl, shr] shift the bits in their first operand's contents left and right, padding the resulting empty bit positions with zeros.
• The x86 processor maintains an instruction pointer (EIP) register that is a 32-bit value indicating the location in memory where the current instruction starts. Normally, it increments to point to the next instruction in memory after execution of an instruction. The EIP register cannot be manipulated directly, but is updated implicitly by providing control flow instructions.
• We use the notation to refer to balled locations in the program text. Labels can be inserted anywhere in x86 assembly code text by entering a label name followed by a colon.
• jmp transfers program control flow of the instruction at the memory location indicated by the operand.
• These instructions [conditional jumps] are conditional jumps that are based on the status of a set of condition codes that are stored in a special register called the machine status word. The contents of the machine status word include information about the last arithmetic operation performed.
• cmp compares the values of the two specified operands, setting the conditions codes in the machine status word appropriately. This instruction is equivalent to the sub instruction, except the result of the subtraction is discarded instead of replacing the first operand.
• These instructions [call, ret] implement a subroutine call and return.
• The call instruction first pushed the current code location onto the hardware supported stack in memory, and then performs an unconditional jump to the code location indicated by the label operand. Unlike the simple jump instructions, the call instruction saves the location to return to when the subroutine completes.
• The ret instruction implements a subroutine return mechanism. This instruction first pops a code location off the hardware supported in-memory stack,. It then performs an unconditional jump to the retrieved code location.
• To allow separate programmers to share code and develop libraries for use by many programs, and to simplify the use of subroutines in general, programmers typically adopt a common calling convention. The calling convention is a protocol about how to call and return from routines.
• The C calling convention is based heavily on the use of the hardware-supported stack. It is based on the push, pop, call, and ret instructions. Subroutine parameters are passed on the stack. Registers are saved on the stack, and local variables used by subroutines are placed in memory on the stack. The vast majority of high-level procedural languages implemented on most processors have used similar calling conventions.
• The calling convention is broken into two sets of rules. The first set of rules is employed by the caller of the subroutine, and the second set of rules is observed by the writer of the subroutine (the callee).
• It should be emphasized that mistakes in the observance of these rules quickly result in fatal program errors since the stack will be left in an inconsistent state; thus meticulous care should be used when implementing the call convention in your own subroutines.
• To make a subroutine call, the caller should:
• Before calling a subroutine, the caller should save the contents of certain registers that are designated caller-saved. The caller-saved registers are EAX, ECX, EDX. Since the called subroutine is allowed to modify these registers, if the caller relies on their values after the subroutine returns, the caller must push the values in these registers onto the stack (so they can be restored after the subroutine returns).
• To pass parameters to the subroutine, push them onto the stack before the call. The parameters should be pushed in inverted order (i.e. last parameter first). Since the stack grows down, the first parameters will be stored at the lowest address (this inversion of parameters was historically used to allow functions to be passed a variable number of parameters).
• To call the subroutine, use the call instruction. This instruction places the return address on top of the parameters on the stack, and branches to the subroutine code. This involves the subroutine, which should follow the callee rules below.
• After the subroutine returns (immediately following the call instruction), the caller can expect to find the return value of the subroutine in the register EAX. To restore the machine state, the caller should:
• Remove the parameters from the stack. This restores the stack to its state before the call was performed.
• Restore the contents of caller-saved registers (EAX, ECX, EDX) by popping them off of the stack. The caller can assume that no other registers were modified by the subroutine.
• The base pointer is used by convention as a point of reference for finding parameters and local variables on the stack. When a subroutine is executing, the base pointer holds a copy of the stack pointer value from when the subroutine started executing. Parameters and local variables will always be located at known, constant offsets away from the base pointer value.
• We push the old base pointer value at the beginning of the subroutine so that we can later restore the appropriate base pointer value for the caller when the subroutine returns.
• Allocate local variables by making space on the stack. Recall, the stack grows down, so to make space on the top of the stack, the stack pointer should be decremented. The amount by which the stack pointer is decremented depends on the number and size of local variables needed.
• To save registers, push them onto the stack..
• Note that the callee's rules fall cleanly into two halves that are basically mirror images of one another. The first half of the rules apply to the beginning of the function, and are commonly said to define the prologue to the function. The latter half of the rules apply to the end of the function, and are thus commonly said to define the epilogue of the function.
• The subroutine prologue performs the standard actions of saving a snapshot of the stack pointer in EBP (the base pointer), allocating global variables by decrementing the stack pointer, and saving register values on the stack.
• The function epilogue is basically a mirror image of the function prologue. The caller's register values are recovered from the stack, the local variables are deallocated by resetting the stack pointer, the caller's base pointer value is recovered, and the ret instruction is used to return to the appropriate code location in the caller.

The Five Essential Phone-Screen Questions by Steve Yegge

The Five Essential Phone-Screen Questions

• It's usually pretty obvious when the candidate should have been eliminated during the phone screens.
• The first pattern is that for most failed phone screens, the candidate did most of the talking.
• The right way to do a phone screen is to do most of the talking, or at least the driving. You look for specific answers, and you guide the conversation along until you've got the answer or you've decided the candidate doesn't know it.
• The second pattern is that one-trick ponies only know one trick. Candidates who have programmed mostly in a single language, platform, or framework usually have major, gaping holes in their skills lineup.
• If you only asks the candidate about what they know, you've got a fairly narrow view of their abilities.
• These five areas are litmus tests--very good ones. I've chosen them based on the following criteria:
• They're universal--every programmer needs to know them.
• They're quick--they're areas that you can probe very quickly, without eating too much into your phone-screen time.
• They're predictors--there are certain common "SDE profiles" that are easy to spot because they tend to fail (and I mean really fail) in one or more of these five areas.
• You have to probe all five areas; you can't skip any of them. Each area is a proxy for a huge body of knowledge, and failing it very likely means failing the interviews, even though the candidate did fine in the other areas.
• The Five Essential Questions for the first phone-screen with an SDE candidate:
• Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java.
• OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple program.
• Scripting and regexes. The candidate has to describe how to find the phone numbers in 50K HTML pages.
• Data structures. The candidate has to demonstrate basic working knowledge of the most common data structures.
•  Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers.
• What I'm looking for here is a total vacuum in one of these areas. What you're looking for is candidates who are utterly clueless, or horribly confused, about the area in question.
• When a candidate is totally incompetent in one of these Big Five areas, the chances are very high that they'll bomb horribly when presented with our typical interview questions.
• The candidate has to write some code. Give them a coding problem that requires writing a short, straightforward function. They can write it in whatever language they like, as long as they don't just call a library function that does it for them.
• I've decided that candidates need to be able to code their answers in C, C++, or Java.
• Some properties of a good weeder phone-screen coding question are:
• It's simple.
• You've solved it.
• It has loops or recursion.
• It has formatted output.
• It has text-file I/O.
• You shouldn't ask a question unless you've solved it yourself recently, so you know it's a reasonable question, and you can evaluate their answer to it.
• Being able to reason recursively or inductively is important for many areas of computing, including using hierarchical data representation, distributed computing, searching, and sorting.
• Many candidates simply can't think recursively, and this often goes undetected until interview-time.
• This [formatted output] is a basic skill, useful for debugging, simple report generation, and lots of other things. "printf" is a universal standard; it exists in C, C++, Java, Perl, Ruby, Python, and virtually every other mainstream language, at least as a library call.
• Candidates who have worked in frameworks for too long often become unable to function as programmers outside that framework. Not being able to do simple file I/O is a common indicator that they've grown overly dependent on a particular framework.
• We shouldn't hire SDEs who aren't at least somewhat proficient with OOP. I'm not claiming that OOP is good or bad; I'm just saying you have to know it, just like you have to know the things you can and can't do at an airport security checkpoint.
• OO has been popular/mainstream for more than 20 years. Virtually every programming language supports OOP in some way. You can't work on a big code base without running into it.
• OO concepts are an important building block for creating good service interfaces. They represent a shared understanding and a common vocabulary that are sometimes useful when talking about architecture.
• I draw a distinction between "knows it" and "is smart enough to learn it". Normally I allow people through for interviews if they've got a gap in their knowledge, as long as I think they're smart enough to make it up on the job.
• Candidates who've only studied the terminology without every doing any OOP often don't really get it. When they go to produce classes or code, they don't understand the difference between a static member and an instance member, and they'll use them interchangeably.
• Many C/C++/Java candidates, even some with 10+ years of experience, would happily spend a week writing a 2,500-line program to do something you could do in 30 seconds with a simple Unix command.
• In my experience, a programmer who only knows one language is usually completely lost in one of these Five Essential Areas.
• SDE candidates need to demonstrate a basic understanding of the most common data structures, and of the fundamentals of "big-O" algorithmic complexity analysis.
• Here's what they need to know about big-O. They need to know that algorithms usually fall into the following performance classes: constant-time, logarithmic, linear, polynomial, exponential, and factorial.
• Nobody likes to admit they don't know something you need to know.
• All programmers should be able to count in hexadecimal, and should be able to convert between the binary, octal, and hex representations of a number.

The Guerrilla Guide to Interviewing by Joel Spolsky

The Guerrilla Guide to Interviewing

• Everybody gives lip service to the idea that people are the most important part of a software project, but nobody is quite sure what you can do about it.
• The very first thing you have to do right if you want to have good programmers is to hire the right programmers, and that means you have to be able to figure out who the right programmers are, and this is usually done in the interview process.
• You should always try to have at least six people interview each candidate that gets hired, including at least five who would be peers of that candidate.
• It's to easy to fake out one interview, especially when a non-programmer interviews a programmer.
• If even two of the six interviewers thinks that a person is not worth hiring, don't hire them.
• Don't try to interview a bunch of people at the same time. It's just not fair.
• Each interview should consist of one interviewer and one interviewee, in a room with a door that closes and a whiteboard.
• The trick is telling the difference between the superstars and the maybes, because the secret is that you don't want to hire any of the maybes. Ever.
• At the end of the interview, you must be prepared to make a sharp decision about the candidate. There are only two possible outcomes to this decision: Hire or No Hire. There is no other possible answer.
• Even if you have a candidate that would be brilliant at doing your particular task, but wouldn't be very good in another team, that's a No Hire. In software, things change so often and so rapidly that you need people that can succeed at just about any programming task that you throw at them.
• Never say "Maybe, I can't tell". If you can't tell, that means No Hire. It's really easier than you'd think.
• It is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs.
• Bad employees demoralize the good employees.
• Don't lower your standards no matter how hard it seems to find those great candidates.
• You're looking for people who are: Smart, and Get things done.
• People who are Smart but don't Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because the4y love to point out the theoretical similarity between two widely divergent concepts.
• People who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. This makes them liabilities to the company because not only do they fail to contribute, but they soak up good people's time.
• How do you detect smart in an interview? The first good sign is that you don't have to explain things over and over again. The conversation just flow.
• There is no possible, imaginable correlation between people that know [...] trivia and people that you want to hire.
• Remember, smart does not mean "knows the answer to trivia questions."
• Software teams want to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it's better to hire people that are going to be able to learn any new technology rather than people who happen to know how to make JDBC talk to a MySQL database right this minute.
• In general, the way to learn the most about a person is to let them do the talking. Give them open-ended questions and problems.
• Here's a typical plan for interviewing a programmer:
• Introduction
• Question about recent project candidate worked on
• Easy Programming Question
• Pointer/Recursion Question
• Are you satisfied?
• Do you have any questions?
• I am very, very careful to avoid anything that might give me some preconceived notions about the candidate.
• Don't listen to recruiters; don't ask around about the person before you interview them; and never, ever talk to the other interviewers about the candidate until you've both made your decisions independently.
• I always reassure candidates that we are interested in how they go about solving problems, not the actual answer.
• For interviewing college kids, ask them about their senior thesis, if they had one, or about a course they took that involved a long project that they really enjoyed.
• When interviewing experienced candidates, you can talk about their most recent assignment from their previous job.
• Look for passion. Smart people are passionate about the projects they work on. They get very excited about the subject. They talk quickly, and get animated. Being passionately negative can be just as good a sign.
• Bad candidates just don't care and will not get enthusiastic at all during the interview.
• Good candidates are careful to explain things well, at whatever level.
• Look for signs that they took a leadership role.
• The only way you're going to be able to tell if somebody Gets Things Done is to see if historically they have tended to get things done in the past. IN fact, you can ask them directly to give you an example from their recent past when they took a leadership role and got something done.
• What I discovered was that everybody solved the problem, but there was a lot of variation in how long it took them to solve.
• If the basic concepts aren't so easy that you don't even have to think about them, you're not going to get the big concepts.
• You see, if you can't whiz through the easy stuff at 100 m.p.h, you're never gonna get the advanced stuff.
• 15 years of experience interviewing programmers has convinced me that the best programmers all have an easy aptitude for dealing with multiple levels of abstraction simultaneously. In programming, that means specifically that they have no problem with recursion or complex pointer-based algorithms.
• I've come to realize that understanding pointers in C is not a skill, it's an aptitude.
• For some reason most people seem to be born without the part of the brain that understands pointers. Pointers require a complex form of doubly-indirect thinking that some people just can't do, and it's pretty crucial to good programming.
• A lot of programmers that you might interview these days are apt to consider recursion, pointers, and even data structures to be a silly implementation detail which has been abstracted away by today's many happy programming languages.
• I don't really mind giving programming problems that are too hard, as long as the candidate has some chance of starting out, and then I'm happy to dole out little hints along the way, little toeholds, so to speak.
• All programmer's make mistakes, there's nothing wrong with that, they just have to be able to find them.
• Remember, even though you're interviewing them, the good candidates have lots of choices about where to work and they're using this day to figure out if they want to work for you.
• Stick to questions which are completely relevant to the job for which they are interviewing.
• Avoid brain teaser questions.
• A good back-of-the-envelope question allows you to have a conversation with the candidate what helps you form an opinion about whether they are smart.
• If, at the end of the interview, you've convinced yourself that this person is smart and gets things done, and four or five other interviewers agree, you probably won't go wrong in hiring them. But if you have any doubts, you're better off waiting for someone better.
• The optimal time to make a decision about the candidate is about three minutes after the end of the interview.
• I ask interviewers to write immediate feedback after the interview, either a "hire" or "no hire", followed by a one or two paragraph justification. It's due 15 minutes after the interview ends.
• If you're having trouble deciding, there's a very simple solution. NO HIRE. Just don't hire people that you aren't sure about.

Forth: The Hacker's Language by Hackaday

Forth: The Hacker's Language

• Forth is the hacker's programming language.
• Coding in Forth is a little bit like writing assembly language, interactively, for a strange CPU architecture that doesn't exist.
• Forth is a virtual machine, an interpreted command-line, and a compiler all in one. And all of this is simple enough that it's easily capable of running in a few kilobytes of memory.
• If C gives you enough rope to hang yourself, Forth is a flamethrower crawling with cobras. There is no type checking, no scope, and no separation of data and code.
• Forth is about simplicity and flexibility.
• Almost nothing is included with most Forth systems by default.
• Forth is the simplest language after assembly language.
• Forth is procedural in the extreme--a Forth program is really just a chain of subroutines, called "words" in Forth jargon. There's no syntax, and all words are separated by a space and are parsed left to right. With a few exceptions for compiling, all words run right now so the Forth interpreter doesn't have to look ahead to the next word.
• The corollary of this simple setup is that Forth uses the so-called Reverse Polish Notation (RPN).
• The way that you think of as "natural" to write down math is crazy, in the sense that the look-ahead nature of the '+' operator requires either parentheses of an "order of operations" to be unambiguous.
• A computer doesn't want to know about "order" of operations", it just wants to add two numbers, preferably ones that are already sitting in ALU registers.
• New words are defined and compiled with a ':' to enter compilation mode and a ';' to exit. Compilation, such as it is, takes place immediately.
• Under the hood, the Forth interpreter is looking up each word that you use in the definition and simply stringing them together.
• All programming is about breaking complicated tasks down into reasonable-sized chunks. What constitutes "reasonable" depends a bit on the language, a bit on the programmer's own style, and a bit on the cultural zeitgeist.
• The heart and soul of Forth is the data stack, henceforth "the stack".
• Forth is a stack-based language, and until you've coded in Forth for a while, you can't appreciate what this really means and how thoughts about the stack come to dominate your coding life.
• Forth words don't take arguments or return values, instead they operate on whatever data is on the stack when they're called.
• The gimmick in Forth programming is figuring out what's needed on the stack by one word, and making sure that the word used just beforehand leaves that on the stack. In this sense, the Forth programmer defines words, but needs to think in phrases, where the contents of the stack start out empty and end that way again.
• The absolutely worst part of Forth is the stack manipulations.
• Words like swap, drop, and dup let you move items around on the stack, but too many "stack juggling" manipulations in a given word is probably a sign of bad Forth code, rather than good.

The Tao of IETF

The Tao of IETF

• BCPs make recommendations for Best Current Practices in the Internet.
• RFCs are the IETF's main technical documentation series, politely known as "Requests for Comments".
• STDs are RFCs identified as "standards".
• So, why "the Tao"? Pronounced "dow", Tao is the basic principle behind the teachings of Lao-tse, a Chinese master. Its familiar symbol is the black-and-white yin-yang circle. Taoism conceives the universe as a single organism, and human beings as interdependent parts of a cosmic whole. Tao is sometimes translated "the way", but according to Taoist philosophy the true meaning of the word cannot be expressed in words.
• The IETF is a loosely self-organized group of people who contribute to the engineering and evolution of Internet technologies. It is the principle body engaged in the development of new Internet standard specifications. The IETF is unusual in that it exists as a collection of happenings, but is not a corporation and has no board of directors, no members, and no dues.
• In many ways, the IETF runs on the beliefs of its participants. One of the "founding beliefs" is embodies in an early quote about the IETF from David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code". Another early quote that has become a commonly-held belief in the IETF comes from Jon Postel: "Be conservative in what you send and liberal in what you accept".
• The IETF makes voluntary standards that are often adopted by Internet users, but it does not control, or even patrol, the Internet.
• The vast majority of the IETF's work is done in many working groups.
• A working group is really just a mailing list with a bit of adult supervision. You "join" the working group by subscribing to the mailing list; all mailing lists are open to anyone.
• Another aspect of Working Groups that confounds many people is that fact that there is no formal voting. The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree.
• The most important thing that everyone (newcomers and seasoned experts) should do before coming to a face-to-face meeting is to read the Internet-Drafts and RFCs ahead of time.
• The biggest reason some people do not want their documents put on the IETF standards track is that they must give up change control of the protocol. That is, as soon as you propose that your protocol become an IETF standard, you must fully relinquish control of the protocol. If there is general agreement, parts of the protocol can be completely changes, whole sections can be ripped out, new things can be added, and the name can be changed.
• IETF standards exist so that people will use them to write Internet programs that inter-operate.
• Every document that ends up in the RFC repository starts life as an Internet-Draft.
• Internet-Drafts are tentative documents--they're meant for readers to comment on, so authors can mull over those comments and decide which ones to incorporate in the draft.
• One way to make it more likely that developers will create inter-operable implementations of standards is to be clear about what's being mandated in a specification.

Agile Software Development

Manifesto for Agile Software Development

• We are uncovering better ways of developing software by doing it and helping others do it.
• Through this work we have come to value:
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.
• This is, while there is value in the item on the right, we value the items on the left more.

Twelve Principles of Agile Software

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, form a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily through the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

How Software is Eating the World by Venkatesh Rao

How Software is Eating the World

• A great deal of product development is based on the assumption that products must adapt to unchanging human needs or risk being rejected. Yet, time and again, people adapt in unpredictable ways to get the most out of new tech.
• People change, then forget that they changed, and act as though they always behaved a certain way and could never change again. Because of this, unexpected changes in human behavior are often dismissed as regressive rather than as potentially intelligent adaptations.
• To "break smart" is to adapt intelligently to new technological possibilities.
• After written language and money, software is only the third major soft technology to appear in human civilization.
• Only a handful of general-purpose technologies--electricity, steam power, precision clocks, written language, token currencies, iron metallurgy, and agriculture among them--have impacted our world in the sort of deeply transformative way that deserves the description eating. And only two of these, written language and money, were soft technologies: seemingly ephemeral, but capable of being embodied in a variety of specific physical forms.
• Software has the same relationship to any specific sort of computing hardware as money does to coins or credit cards or writing to clay tables and paper books.
• This is breaking smart: an economic actor using early mastery of emerging technological leverage to wield disproportionate influence on the emerging future.
• Software eating the world is a story of the seen and the unseen: small, measurable effects that seem underwhelming or even negative, and large invisible and positive effects that are easy to miss, unless you know where to look.
• To traditionalists, particularly in the United States, the car is a motif for an entire way of life, and the smartphone just an accessory. To early adopters who have integrated ride-sharing deeply into their lives, the smartphone is the lifestyle motif, and the care is the accessory. To generations of Americans, owning a car represented freedom. To the next generation, not owning a car will represent freedom.
• Every aspect of the global industrial social order is being transformed by the impact of software.
• Partly as a consequence of how rarely soft, world-eating technologies erupt into human life, we have been systematically underestimating the magnitude of the forces being unleashed by software. While is might seem like software is constantly in the news, what we have already seen is dwarfed by what still remains unseen.
• The opportunities presented by software are expanding, and the risks of being caught on the wrong side of the transformation are dramatically increasing.
• Software-fueled victories in the past decade have tended to be overwhelming and irreversible faits accompli.
• We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.
• Technological change unfolds exponentially, like compound interest, and we humans seem wired to think about exponential phenomena in flawed ways.
• Change that often looks trivial or banal on the surface, but turns out to have been profound once the dust settles.
• We have shifted gears from what economic historian Carlota Perez called the installation phase of the software revolution, focused on basic infrastructure such as operating systems and networking protocols, to a deployment phase focused on consumer application such as social networks, ride-sharing and eBooks.
• In her landmark study of the history of technology, Perez demonstrates that the shift from installation to deployment phase for every major technology is marked by a chaotic transitional phase of wars, financial scandals and deep anxieties about civilization collapse. One consequence of the chaos is that attention is absorbed by transient crises in economic, political and military affairs, and the apocalyptic fears and Utopian dreams they provoke. As a result, momentous but quiet change passes unnoticed.
• A great deal of the impact of software today appears in a disguised form.
• The fourth reason we underestimate software, however, is a unique one: it is a revolution that is being led, in large measure, by brash young kinds rather than sober adults.
• This is perhaps the single most important thing to understand about the revolution that we have labeled software eating the world: it is being led by young people, and proceeding largely without adult supervision.
• But unlike most periods in history, young people today do not have to either "wait their turn" or directly confront a social order that is systematically stacked against them. Operating in the margins by a hacker ethos--a problem solving sensibility based on rapid trail-and-error and creative improvisation--they are able to use software leverage and loose digital forms of organization to create new economic, social and political wealth. In the process, young people are indirectly disrupting politics and economics and creating a new parallel social order. In stead of vying for control of venerable institutions that have already weathered several generational wars, young people are creating new institutions based on the new software and new wealth.
• Chris Dixon captured this guerrilla pattern of the ongoing shift in political power with a succinct observation: what the smartest people do on the weekend is what everyone else will do during the week in ten years.
• Software-driven transformations directly disrupt the middle-class life script, upon which the entire industrial social order is based.
• In its typical aspirational form, the traditional script is based on 12 years of regimented industrial schooling, and additional 4 years devoted to economic specialization, lifetime employment with predictable seniority-based promotions, and middle-class lifestyles.
• Instead of software, the traditional script runs on what we might call paper-ware: bureaucratic processes constructed from the older soft technologies of writing and money. Instead of the hacker ethos of flexible and creative improvisation, it is based on the credentialist ethos of degrees, certifications, licenses and regulations. Instead of being based on achieving financial autonomy early, it is based on taking on significant dept (for college and home ownership) early.
• One way to understand the shift from credentialist to hacker modes of social organization, via young people acquiring technological leverage, is through the mythological tale of Prometheus stealing fire from the heavens form human use.
• Technologies capable of eating the world typically have a Promethean character: they emerge within a mature social order, but their true potential is unreleased by an emerging one, which gains relative power as a result.
• As a result of a Promethean technology being unleashed, younger and older face a similar dilemma: should I abandon some of my investments in the industrial social order and join the dynamic new social order, or hold on to the status quo as long as possible?
• The decision is obviously easier if you are younger, with much less to lose. If you are an adult over 30, especially one encumbered with significant family obligations or debt, the decision is harder.
• Those with a Promethean mindset and an aggressive approach to pursuing a new path can break out of the credentialist life script at any age. Those who are unwilling or unable to do so are holding on to it more tenaciously than ever.
• Young or old, those who are unable to adopt the Promethean mindset end up defaulting to what we call a pastoral mindset: one marked by yearning for lost or unattained utopias.
• Breaking smart at the level of individual sis what leads to organizations and nations breaking smart, which in turn leads to societies succeeding or failing.
• Thanks to virtuous cycles already gaining in power, I believe almost all effective responses to the problems and opportunities of the coming decades will emerge out of the hacker ethos, despite its apparent peripheral role today. The credentialist ethos of extensive planning and scripting towards deterministic futures will play a minor supporting role at best.
• The nature of problem-solving in the hacker mode, based on trial-and-error, iterative improvement, testing and adaptation (both automated and human-driven) allows us to identify four characteristic of how the future will emerge.
• Despite current pessimism about the continued global leadership of the United States, the US remains the single largest culture that embodies the pragmatic hacker ethos, nowhere more so than in Silicon Valley. The United States in general, and Silicon Valley in particular, will therefore continue to serve as the global exemplar of Promethean technology-driven change.
• The future will unfold through very small groups having very large impacts.
• One piece of wisdom in Silicon Valley today is that the core of the best software is nearly always written by teams of fewer than a dozen people, not by huge committee-driven development teams.
• The future will unfold through a gradual and continuous improvement of well-being and qualify of life across the world, not through sudden emergence of a utopian software-enabled world (or sudden collapse into a dystopian world).
• The future will unfold through rapid declines in the costs of solutions to problems, including in heavily regulated sectors historically resistant to cost-saving innovations, such as healthcare and higher education.
• In improvements wrought by software, poor and expensive solutions have generally been replaced by superior and cheaper (often free) solutions, and these substitution effects will accelerate.
• A big implication is immediately clear: the asymptotic condition represents a consumer utopia. As consumers, we will enjoy far more for far less. This means that the biggest unknown today is our future as producers, which brings us to what many view as the central question today: the future of work.
• Purist approached, which rely on alluring visions, are like precious "good" china: mostly for display, and reserved exclusively for narrow uses like formal dinners. Damage through careless use can drastically lower the value of a piece. Broken or missing pieces must be replaced for the collection to retain its full display value. To purists, mixing an matching, either with humbler everyday tableware, or with different china patterns, is a kind of sacrilege.
• The pragmatic approach on the other hand, is like unrestricted and frequent use of hardier everyday dinnerware. damage through careless play does not affect value as much. Broken pieces may still be useful, and missing pieces need not be replaced if they are not actually needed. For pragmatists, mixing and matching available resources, far from being sacrilege, is something to be encourage, especially for collaborations such as neighborhood potlucks.
• To pragmatists, the [web] browser represented important software evolving as it should: in a pluralistic way, embodying many contending ideas, through what the Internet Engineering Task Force (IETF) calls "rough consensus and running code".
• Increasingly, the pragmatic, agile approach to building things has spread to other kinds of engineering and beyond, to business and politics.
• Agile philosophies are eating all kinds of building philosophies.
• Every field eaten by software experiences a migration of the creative part from visioning activities to hands-on activities, disrupting the social structure of all professions.
• The cost of this agility is a seemingly anarchic pattern of progress.
• Adopting agile models leads individuals an organizations to gradually increase their tolerance for anxiety in the face of apparent chaos. As a result, agile models can get more agile over time.
• Once a field become hacker-friendly, software beings to eat it.
• The IETF slogan of rough consensus and running code (RCRC) has emerged as the only workable doctrine for both technological development and associated economic models under these conditions.
• Software possesses an extremely strange property: it is possible to create high-value software products with effectively zero capital outlay. As Mozilla engineer Sam Penrose put it, software programming is labor that creates capital.
• Software though, is a medium that not only can, but must be approached with an abundance mindset. Without a level of extensive trail-and-error and apparent waste that would bankrupt both traditional engineering and art, good software does not take shape.
• Purist visions tend to arise when authoritarian architects attempt to concentrate and use scarce resources optimally, in ways they often sincerely believe is best for all. By contrast, tinkering is focused on steady progress rather than optimal end-states that realize a totalizing vision. It is usually driven by individual interests and not obsessively concerned with grand and paternalistic "best for all" objectives.
• Devoting skills and resources to playful tinkering still seems "wrong", when there are obvious and serious problems desperately waiting for skilled attention.
• Software engineers must unlearn habits born of scarcity before they can be productive in their medium.
• The principle of rough consensus and running code is perhaps the essence of the abundance mindset in software.
• Consensus in traditional organizations tends to be brokered by harmony-seeking individuals  attuned to the needs of others, sensitive to constraints, and good at creating "alignment" among competing autocrats.
• By contrast, software development favors individuals with an autocratic streak, driven by an uncompromising sense of how things ought to be designed and built which at first blush appears to contradict the idea of consensus.
• Conflicts are not sorted out through compromises that leave everybody unhappy. Instead they are sorted out through the principle futurist Bob Sutton identified as critical for navigating uncertainty: strong views, weakly held.
• Rough consensus favors people who, in traditional organizations, would be considered disruptive and stubborn: these are exactly the people prone to "breaking smart".
• In its most powerful form, rough consensus is about finding the most fertile directions in which to proceed rather than uncovering constraints.
• In a process reminiscent of the "rule of agreement" in improv theater, ideas that unleash the strongest flood of follow-on builds tend to be recognized as the most fertile and adopted as the consensus.
• Leaving more decisions for the future also leads to devolving authority to those who come later.
• It is generally smarter to assume that problems that seem difficult and important today might become trivial or be rendered moot in the future.
• Traditional processes of consensus-seeking drive towards clarity tin long-term visions but are usually fuzzy on immediate next steps. By contrast, rough consensus in software deliberately seeks ambiguity in long-term outcomes and extreme clarity in immediate next steps.
• At an ethical level, rough consensus is deeply anti-authoritarian, since it avoids constraining the freedoms of future stakeholders simply to allay present anxieties.
• In other words, true north in software is often the direction that combines ambiguity and evidence of fertility in the most alluring way: the direction of maximal interestingness.
• A pivot allows the direction of development to change rapidly, without a detailed long-term plan. It is enough to figure out experimental next steps. This ability to reorient and adopt new mental models quickly (what military strategists call a fast transient) is at the heart of agility.
• In software, waterfall processes fail in predictable ways, like classic Greek tragedies. Agile processes on the other hand, can lead to snowballing serendipity, getting luckier and luckier, and succeeding in unexpected ways. The reason is simple: waterfall plans constrain the freedom of future participants, leading them to resent and rebel against the grand plan in predictable ways. By contrast, agile models empower future participants in a project, catalyzing creativity and unpredictable new value.
• The best products use perpetual beta as a way to lead their users towards richer, more empowered behaviors, instead of following them through customer-driven processes. Backward compatibility is limited to situations of pragmatic need, rather than being treated as a religious imperative.
• Most software failures do not have life-threatening consequences. As a result, it is usually faster and cheaper to learn from failure than to attempt to anticipate and accommodate it via detailed planning (which is why the RERO principle is often restated in terms of failure as fail fast).
• Perhaps the most counter-intuitive consequence of the RERO principle is this: where engineers in other disciplines attempt to minimize the number of releases, software engineers today strive to maximize the frequency of releases.
• The only way for execution to track the changing direction of the rough consensus as it pivots is to increase the frequency of releases.
• If creating great software takes very little capital, copying great software takes even less.
• Where democratic processes would lead to gridlock and stalled development, conflicts under rough consensus and running code and release early, release often leads to competing, divergent paths of development that explore many possible worlds in parallel.
• Working code that prioritizes visible simplicity, catalyzing effective collaboration and rapid experimentation, tends to spread rapidly and unpredictably. Overwrought code that prioritizes authoritarian, purist concerns such as formal correctness, consistency, and completeness tends to die out.
• In the real world, teams form through self-selection around great code written by one or two linchpin programmers rather than contest challenges.
• While the precise size of an optimal team is debatable, Jeff Bezos' two-pizza rule suggests that the number is no more than about a dozen.
• In stark contrast to the quality code developed by "worse is better" processes, software developed by teams of anonymous, interchangeable programmers, with bureaucratic top-down staffing, tends to be of terrible quality.
• Today, its underlying concepts like rough consensus, pivot, fast failure, perpetual beta, promiscuous forking, opt-in, and worse is better are carrying over to domains beyond software and regions beyond Silicon Valley. Wherever they spread, limiting authoritarian visions and purist ideologies retreat.
• Internally, the software-eaten economy is even more driven by disruption: the time it takes for a disruptor to become a disruptee has been radically shrinking in the last decade--and startups today are highly aware of that risk. That awareness helps explain the raw aggressiveness that they exhibit.
• The Promethean force of technology is today, and always has been, the force that has rescued humanity from its worst problems just when it seemed impossible to avert civilizational collapse.
• A basic divide in the world of technology is between those who believe humans are capable of significant change, and those who believe they are not. Prometheanism is the philosophy of technology that follows from the idea that humans can, do, and should change. Pastoralism, on the other hand is the philosophy that change is profane. The tension between these two philosophies leads to a technology diffusion process characterized by a colloquial phrase popular in the startup world: first they ignore you, then they laugh at you, then they fight you, then you win.
• Science fiction writer Douglas Adams reduced the phenomena to a set of three sardonic rules from the point of view of users of technology:
• Anything that is in the world when you're born is normal and ordinary and is just a natural part of the way the world work.s
• Anything that's invented between when you're fifteen and thrifty-five is new and exciting and revolutionary and you can probably get a career in it.
• Anything invented after you're thirty-five is against the natural order of things.
• Technological evolution is path-dependent in the short term, but not in the long term.
• New technologies change our sense of proportions.
• The path-dependent phase of evolution of a technology can take centuries. But once it enters a collective invention phase, surplus and spillover effects gather momentum and further evolution becomes simultaneously unpredictable and inevitable. Once the inevitability is recognized, it is possible to bet on follow-on ideas without waiting for details to become clear.
• We get attached to pastorals because they offer a present condition of certainty and stability and a utopian future promise of absolutely perfected certainty and stability. Arrival at the utopia seems like a well-deserved reward for hard-won Promethean victories.
• When pastoral fantasies start to collapse under the weight of their own internal contradictions, long-repressed energies are unleashed. The result is a societal condition marked by widespread lifestyle experimentation based on previously repressed values.
• Because they serve as stewards of dominant pastoral visions, cultural elites are most prone to viewing unexpected developments as degeneracy.
• Viewed through any given pastoral lens, any unplanned development is more likely to subtract rather than add value.
• When more people speak a language or accept a currency, the potential of that language or currency increases in a non-zero-sum way. Shared languages and currencies allow more people to harmoniously co-exist, despite conflicting values, by allowing disputes to be settled through words or trade rather than violence.
• Even if one inventor chooses not to pursue a possibility, chances are, others will. As a result, all pastoralist forms of resistance are eventually overwhelmed.
• Prometheans who discover high-leverage unexpected possibilities enter a zone of serendipity. The universe seems to conspire to magnify their agency to superhuman levels. Pastoralists who reject change altogether as profanity turn lack of agency into a self-fulfilling prophecy, and enter a zone of zemblanity. The universe seems to conspire to diminish whatever agency they do have, resulting in the perception that technology diminishes agency.
• Power, unlike capability, is zero-sum, since it is defined in terms of control over other human beings.
• The broader lesson of the principle of generative pluralism is this: through technology, societies become intellectually capable of handling progressively more complex value-based conflicts. As societies gradually awaken to resolution mechanisms that do not require authoritarian control over the lives of others, they gradually substitute intelligence and information for power and coercion.
• Perhaps most important part of the change is that we are experiencing a systematic substitution of intelligence for brute authoritarian power in problem solving, allow a condition of vastly increased pluralism to emerge.
• Much of our collective sense of looming chaos and paradises being lost is in fact a clear and unambiguous sign of positive change in the world.
• Innovation can in fact be defined as ongoing moral progress achieved by driving directly towards the regimes of greatest moral ambiguity, where our collective demons lurk.
• Genuine progress feels like onrushing obscenity and profanity, and also requires new technological capabilities to drive it.
• We see the world through a rear-view mirror. We march backwards into the future.
• Our aesthetic and moral sensibilities are oriented by default towards romanticized memories of paradises lost. Indeed, this is the only way we can enter the future.
• The paradox of progress is that what seems like the path forward is in fact the reactionary path of retreat. What seems like the direction of decline is in fact the path forward.
• The politician's syllogism: Something must be done. This is something. This must be done.
• We may not be satisfied with the answers we find to timeless questions, but simply by asking the questions and attempting to answer them, we are bootstrapping our way to a more advanced society.
• The story of software eating the world is also the story of networks eating geography.
• Crashing storage costs and continuously upgraded data-center hardware allows corporations to indefinitely save all the data they generate. This turning out to be cheaper than deciding what to do with it in real time, resulting in the Big Data approach to business.
• Most code today, unlike fifty years ago, is in hardware-independent high-level programming languages rather than hardware-specific machine code.
• What we are living through today is a hardware and software upgrade for all of civilization.
• And of all the ways we are adapting, the single most important one is the adaption in our problem-solving behaviors.
• Acquiring resources means engaging in zero-sum competition to bring them into your boundary, as captive resources.
• In the last century, the most common outcome of goal-directed problem solving in complex cases has been failure.
• Goal-driven problem solving:
• Problem selection: Choose a clear and important problem.
• Resourcing: Capture resources by promising to solve it.
• Solution: Solve the problem within promised constraints.
• Tinkering-driven problem solving:
• Immersion in relevant streams of ideas, people and free capabilities.
• Experimentation to uncover new possibilities through trial and error.
• Leverage to double down on whatever works unexpectedly well.
• Tinkering is a process of serendipity-seeking that does not just tolerate uncertainty and ambiguity, it requires it. When conditions for it are right, the result is a snowballing effect where pleasant surprises lead to more pleasant surprises.
• From the inside, serendipitous problem solving feels like the most natural thing in the world. From the perspective of goal-driven problem solvers, however, it can look indistinguishable from waste and immoral priorities.
• Gall's Law: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched to make it work. You have to start over with a working simple system.
• The idea that a new, simpler system can revitalize a complex system in a state of terminal crises is the essence of Promethean thinking.
• Free people and ideas can associate in arbitrary ways, creating interesting new combinations and exploring open-ended possibilities. They can make up their own minds about whether problems declared urgent by authoritarian leaders are actually the right focus for their talents. Free ideas are even more powerful, since unlike the talents of free individuals, they are not restricted to one use at a time.
• Free people and free ideas formed the "working simple system" that drove two centuries of disruptive industrial age innovation.
• Tinkering--the steady operation of this working simple system--is a much more subversive force than we usually recognize, since it poses an implicit challenge to authoritarian priorities.
• Tinkering is becoming much more than a minority activity pursued by the lucky few with access to well-stocked garages and junkyards. It is becoming the driver of a global mass flourishing.
• A stream is simply a life context formed by all the information flowing towards you via a set of trusted connections--to free people, ideas, and resources--from multiple networks.
• If the three most desirable things in a world defined by organizations are location, location, and location, in the networked world they are connections, connections, and connections.
• What makes streams ideal contexts for open-ended innovation through tinkering is that they constantly present interrelated people, ideas and resources in unexpected juxtapositions. This happens because streams emerge as the intersection of multiple networks.
• As a result of such unexpected juxtapositions, you might "solve" problems you didn't realize existed and do things that nobody realized were worth doing.
• People, ideas and things can have multiple, fluid meanings depending on what else appears in juxtaposition with them. Creative possibilities rapidly multiply, with every new network feeding into the stream.
• The most interesting place to be is usually the very edge, rather than the innermost sanctums.
• What we do not understand as instinctively is that streams are problem-solving and wealth-creation engines. We view streams as zones of play and entertainment, through the lens of the geographic-dualist assumption that play cannot also be work.
•  The first sustainable socioeconomic order of the networked world is just beginning to emerge, and the experience of being part of a system that is growing smarter at an exponential rate is deeply unsettling to pastoralists and immensely exciting to Prometheans.
• For Prometheans, the challenge is to explore how to navigate and live in this world. A growing non-geographic-dualist understanding of it is leading to a network culture view of the human condition. If the networked world is a planet-sized distributed computer, network culture is its operating system.

Realm of Racket by Matthias Felleisen

• Racket allows functional programming and other different paradigms that even hard-core programmers have never seen before.
• Lisp is a highly expressive language.
• Lisp will change your mind.
• Lisp is worth learning for a different reason--the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.
• A compiler can take something that looks like plain arithmetic and convert it automatically into a format that the computer can execute.
• An interpreter is similar, although it performs the actions described in a human written program directly; there is no intermediate step that converts it all the way down to a computer format.
• For many functions, it makes a lot of sense to supply a lot of arguments at once, and with prefix notation, doing so is easy.
• Loops are just abbreviations for recursive functions.
• Computers are dumb pieces of hardware.
• Programmers use programming languages to turn computers into useful and entertaining gadgets.
• Racket is a programming language for making programming languages.
• Cutting the number of possibilities in half at each step is called a binary search.
• Binary search is frequently used in programming because it is remarkably effective at finding answers quickly.
• The define keyword is quite important for understanding Racket programs, as it is used to define variables and functions.
• Racket ignores spaces and line breaks when it reads code.
• The final value calculated in the function is returned automatically.
• The purpose of set!, pronounced "set bang", is to evaluate the expression and set the variable to the resulting value.
• It is practical to have one main function that starts--or restarts--the whole application.
• To understand any language--be it a human language or language for programming--requires two concepts from the field of linguistics. Computer scientists refer to them as "syntax" and "semantics". You should know that these are just fancy words for "grammar" and "meaning".
• Syntax is the collection of rules that a phrase must follow to qualify as a valid sentence.
• The actions that a computer performs in response to a program make up its semantics.
• Most programming languages have similar semantic powers.
• Having a simple syntax is a defining feature of the Lisp family of languages, including Racket.
• So keep in mind that Racket has only one way of organizing bits of code: parentheses. The organization of a program is made completely clear only from the parentheses it uses. And that's all.
• Symbols are another common type of data in Racket. A symbol in Racket is a stand-alone word proceeded by a single quote or "tick" mark (').
• Lists are a crucial form of data in Racket.
• Lists in Racket are held together with cons cells.
• A cons cell is made of two little connected boxes, each of which can point to any other piece of data, such as a string or a number.
• If x is the name for a cons cell, car extracts the left piece of data from x and cdr extracts the right one.
• There are three basic functions for manipulating lists in Racket: cons, first, and rest.
• When you call cons, Racket allocates a small chunk of memory, the cons cell, to hold references to the objects being linked.
• Structures, like lists, are yet another means of packaging multiple pieces of data together in Racket.
• To access the information in a structure field, we call the appropriate accessor function.
• In Racket, it is common practice to store data as lists of structures.
• A Racket predicate is just a function that returns either true or false.
• The basic idea behind a conditional expression is that some code is evaluated only under some condition.
• The cond expression is the classic way to do branching in Racket.
• When you write programs, you should create tests for almost all the functions in your code. As a matter of fact, you should write tests before you even write the function.
• Defining a constant and referencing it throughout the program is highly preferable to using literal constants everywhere. Once you have done so, you can change the value where it is defined, and then everything else that references the constant will use the new value as well. This provides a single point of control.
• A well-chosen data representation makes all the difference, because it almost always dictates how the code will be organized.
• Tick handlers are functions that step a world from one moment to the next.
• In Racket, graphical shapes are values just like numbers in other languages.
• As in physics, we think about any object as a point in the plane. With this representation, a check for collisions becomes especially easy. Objects collide when they both occupy the same point. We do pay a price for this simplicity, however.
• Functions in Racket are values, just like numbers, strings, and images.
• Since functions are treated as values, we can pass them into other functions as arguments. We can also return a function from a function.
• A function that consumes or produces another function is called a higher-order function, and it can compute all kinds of nifty things.
• With lambda, we can create nameless functions on the fly when we need them.
• The apply function takes a function and a list and applies the given procedure to the elements of the list.
• In Racket you can define a struct as a "child" of another struct.
• void is a function that produces nothing.
• Mutators make programming complex. We use them because they are powerful; they make changes to structs look concise. But this power is also difficult to control.
• Structures are good for representing objects with a fixed number of parts.
• You should get to know Racket's for loops because they are far more powerful than what you may have encountered. Racketeers are keenly aware of the advantages of lambda, map, andmap, filter, and friends, and therefore Racket provides many more kinds of for loops than you have ever seen. If you can wrap your head around them, you will write compact yet highly readable code.
• There are several variants of for loops. Each combines its results in a different way.
• As every college student knows, being lazy is on occasion a remarkably effective way to get work done. What we mean, of course, is that some work just goes away if you wait long enough.
• Lazy evaluation allows your program to delay computations until absolutely necessary. By doing so, it avoids a bunch of work that isn't needed in the first place.
• The simplest way to make a suspended computation is by wrapping a no-arguments lambda around an expression.
• Memoization is the technique of saving the result of a suspended computation in a hidden variable. If the result is needed again, it is enough to look at this hidden variable instead of rerunning the computation.
• A lambda in Racket creates a closure, which captures all the bindings in the lambda's context. This way, whenever a closure flows to a different scope, it can still reference all of its original bindings.
• Memoization eliminates the need to call any time-consuming thunk more than once.
• Fortunately, Racket has two built-in mechanisms to make your program lazy without you needing to write a lot of code. One of them is an entire language called Lazy Racket. To use it, change the #lang racket at the head of your program to #lang lazy. The idea behind lazy is that absolutely every computation is a lazy computation. Nothing is ever computed until it's needed, and everything is memoized.
• A promise represents a suspended computation that can be evaluated at a later date with force.
• Laziness procrastinates work until necessary.
• Memoization remembers the value of computations to avoid recomputing them.
• The strategy of search and evaluate is one idea behind John McCarthy's notion of AI. For games, this idea works amazingly well and truly invokes the perception of intelligence.
• The principle behind the minimax algorithm is "what is good for me is bad for my opponent", and vice versa. Hence, the algorithm minimizes the maximum damage an opponent can inflict during a turn. Roughly speaking, the algorithm proceeds in two steps. First, it assigns a value to each move in the tree, up to a certain level. Second, it determines the minimum of the maximal damage at each level of the tree, from the perspective of the current player. At the root of the game tree, the AI picks the move that results in the best possible outcome as far out as the algorithm can see.
• We do not want the AI to make an evaluation beyond a certain depth in the game tree. Otherwise, the AI forces every single level in the game tree, and we lose all the advantages of going lazy.
• The depth limit reduces the AI's intelligence but without it the program would run too slowly.
• Distributed programming requires a planned-out communication protocol.
• Designing a good protocol can save you a lot of work. Spend time on it.
• All members of the Lisp family come with incredibly powerful ways to add new syntax to the language. For better or worse, pedestrian programmers call this idea metaparogramming, and Lispers say macro programming. Regardless of what you call them, macros allow you to expand the vocabulary of your language.
• Many computational problems require substantial knowledge about the problem area, also known as the domain.
• Experts would much prefer to articulate solutions in a language that they understand, even if the language is just a special purpose programming language from our perspective.
• Racket makes it particularly easy to create new programming languages, including special-purpose languages.
• Like a compiler, the macros translate programs from the new language to plain Racket.

WARRIOR POLITICS by Robert D. Kaplan

• The original sin of any writer is to see the world only from his or her point of view. Objectivity is illusory.
• Often, what passes for analysis is merely an expression of one’s life experiences applied to a specific issue.
• The evils of the twentieth century arose from populist movements that were monstrously exploited in the name of utopian ideals, and had their power amplified by new technologies.
• Thus, the evils of the twenty-first century may also arise from populist movements, taking advantage of democratization, motivated this time by religious and sectarian beliefs, and empowered by a post–Industrial Revolution: particularly information technology.
• Populist rage is fueled by social and economic tensions, aggravated often by population growth and resource scarcity in an increasingly urbanized planet.
• The benefits of capitalism are not distributed equitably, so the more dynamic the capitalist expansion, the more unequal the distribution of wealth that usually results.
• The spread of information will not necessarily encourage stability.
• The spread of information in the coming decades will lead not just to new social compacts, but to new divisions as people discover new and complex issues over which to disagree.
• There is nothing more volatile and more in need of disciplined, enlightened direction than vast populations of underpaid, underemployed, and badly educated workers divided by ethnicity and beliefs.
• Democratization is a long and uneven process: it will generate weak and uncertain rulers before it generates stable organizations.
• The twentieth century was the last in history when humankind was mostly rural. The battlefields of the future will be highly complex urban terrains. If our soldiers cannot fight and kill at close range, our status as a superpower is in question.
• But the post–Industrial Revolution empowers anyone with a cellular phone and a bag of explosives.
• America’s military superiority guarantees that such new adversaries will not fight according to our notions of fairness: they will come at us by surprise, asymmetrically, at our weakest points, as they often have in the past.
• Asymmetry gives terrorists and cybercriminals their strength, since such adversaries operate beyond accepted international norms and value systems on a plane where atrocity is a legitimate form of war.
• Biological weapons will become increasingly available to terrorist groups.
• New devices will provide new opportunities, as they always have, for human mischief.
• Conflict and community are both inherent in the human condition.
• It takes a shallow grasp of history to believe that solutions exist to most international problems. Often there are no solutions, only confusion and unsatisfactory choices.
• The realist may have the same goals as the idealist, but he understands that action must sometimes be delayed to ensure success.
• human passions and motivations have changed little over the millennia.
• To listen to public discourse in America, one would think that morality is entirely a Judeo-Christian invention. But it was the pagan writer Plutarch’s main theme in his profiles of great men.
• Times have changed less than we think.
• Foreign policy is the opposite of comprehensive knowledge: even with the best spies, area experts, and satellite surveillance, a critical area of darkness remains, caused not only by the absence of information but also by its surfeit, and the confusion it can lead to. Instinctive judgment is vital.
• If literature is the quiet resource of statesmen, then no literature is more relevant for our purposes than the ancient classics on war and politics, which provide an emotional distance from the present that is especially valuable in a media age, when too many of us have become creatures of the moment—obsessed with the latest news event or opinion survey to the degree that it seems as if the past and all its lessons have ceased to exist.
• The greater the disregard of history, the greater the delusions regarding the future.
• To read the eminent thinkers of pagan antiquity is to find an unusual coherence, clarity of analysis, and unanimity of convictions, variously expressed.
• There is arguably no work of philosophy in which knowledge and experience are so pungently condensed as Sun-Tzu’s The Art of Warfare
• Sun-Tzu explains that in war the “highest excellence” is never having to fight, for the commencement of battle signifies a political failure.
• The strategic pursuit of self-interest is not a cold and amoral pseudo-science, but the moral act of those who know the horrors of battle and seek to avoid them.
• Good spies prevent bloodshed, according to Sun-Tzu.
• Intelligence gathering was a fundamental ingredient in the West’s victory in the Cold War.
• Whatever we may think or profess, human behavior is guided by fear (phobos), self-interest (kerdos), and honor (doxa). These aspects of human nature cause war and instability, accounting for anthropinon, the “human condition.” The human condition, in turn, leads to political crises: when physis (pure instinct) triumphs over nomoi (laws), politics fails and is replaced by anarchy. The solution to anarchy is not to deny fear, self-interest, and honor but to manage them for the sake of a moral outcome.
• one must be careful with Machiavelli. Because he often reduces politics to mere technique and cunning, it is easy to find justification in his writing for almost any policy.
• followers helped bring down the Roman empire? One must always keep in mind that ideas do matter, for better and worse, and to reduce the world merely to power struggles is to make cynical use of Machiavelli. But some academics and intellectuals go too far in the other direction: they try to reduce the world only to ideas, and to neglect power.
• Values—good or bad—Machiavelli says, are useless without arms to back them up: even a civil society requires police and a credible judiciary to enforce its laws. Therefore, for policymakers, projecting power comes first; values come second.
• Men who live in conditions where there is not sufficient food, warmth, shelter, and the minimum degree of security can scarcely be expected to concern themselves with freedom of contract or of the press.
• We will, and should, intervene whenever an overwhelming strategic interest intersects with a moral one,
• The emergence of an authentic global constabulary force will widen the scope for involvement, but not infinitely.
• The realization that we cannot always have our way is the basis of a mature outlook that rests on an ancient sensibility, for tragedy is not the triumph of evil over good so much as the triumph of one good over another that causes suffering.
• A man’s greatest fear, Hobbes tells us, is of violent death: death at the hands of a fellow man.
• Because its founding purpose is to keep men from killing each other, the Leviathan is a monopolizer of force.
• Freedom becomes an issue only after order has been established.
• “The most important political distinction among countries concerns not their form of government but their degree of government. The differences between democracy and dictatorship are less than the differences between those countries whose politics embodies consensus, community, legitimacy, organization, effectiveness, stability, and those countries whose politics is deficient in those qualities.”
• Fear of violent death is a deep and farsighted fear that allows men to comprehend fully the tragedy of life.
• Good government—and, likewise, good foreign policy—will always depend on an understanding of men’s passions, which issue from our elemental fears.
• Where food is scarce, whether because of prices, maldistribution, political malfeasance, or drought, conflict or disease has often resulted.
• Without evil there can be no virtue.
• Vast oceans have given Americans the protection necessary to advance universalist principles.
• Whether in antiquity or in the post–Cold War world, the central question of foreign affairs remains: Who can do what to whom? The phrase “balance of power” is less a theory of international relations than a description of it.
• Historically, democracies have been as prone to war as other regimes.
• Consequently, realists believe that while human rights are, in theory, advanced by democracy and economic integration, in practice they are advanced by resolving power relationships in ways that allow for more predictable punishment of the Unjust. Of course, that often involves both democratization and free trade, but not always. For in human affairs, moral questions are often linked to questions of power.
• To act with goodwill means seeing each man or woman as “an end in itself,” and not merely a “means.”
• A free man acts according to his principles rather than according to his fears or appetites, for it is such fears and appetites that are the external forces constricting our freedom.
• Statesmanship demands a morality of consequence. A statesman must be able to think the unthinkable. If he has to operate in an insane environment,
• The separation of private ethics from politics, begun by Machiavelli among others, and completed by Hobbes, laid the foundation for a diplomacy free from the otherworldly absolutism of the medieval church. We must be careful not to return to such absolutism, for if there is such a thing as progress in politics, it has been the evolution from religious virtue to secular self-interest.
• Groups that refuse to play by our rules will constantly be committing outrages.
• The split between civilian and military commands emerged only in the nineteenth century with the professionalization of modern European armies.
• Collaboration between the Pentagon and corporate America is necessary, and will grow. Going to war will be less and less a democratic decision.
• Today’s warriors come often from the hundreds of millions of unemployed young males in the developing world, angered by the income disparities that accompany globalization.
• Globalization is Darwinian. It means economic survival of the fittest—those groups and individuals that are disciplined, dynamic, and ingenious will float to the top, while cultures that do not compete well technologically will produce an inordinate number of warriors.
• An economy-of-scale is no longer necessary to produce weapons of mass destruction.
• Precisely because we are militarily superior to any group or nation, we should expect to be attacked at our weakest points, beyond the boundaries of international law.
• In the hands of the media, the language of human rights—the highest level of altruism—becomes a powerful weapon that can lead us into wars that perhaps we should not fight.
• Prudence dictates that we approach casualty-free war as a myth, despite technological advances such as bullets that incapacitate without injuring.
• As more information accumulates, the difference between information and real knowledge could widen.
• Exclusive reliance on technology, at once naïve and arrogant, takes little account of local history, traditions, terrain, and other factors that are essential for making wise judgments.
• The media is no longer simply the fourth estate, without which the other three branches of government could not operate honestly and effectively. Because of technology and the consolidation of news organizations—similar to the consolidation of airline and automobile alliances—the media is becoming a world power in its own right. The power of the media is willful and dangerous because it dramatically affects Western policy while bearing no responsibility for the outcome. Indeed, the media’s moral perfectionism is possible only because it is politically unaccountable.
• States and other entities—whether the United States or the Tamil Tigers—will go to war when they decide it is in their interests (strategic, moral, or both) and will, consequently, be unconcerned if others view their aggression as unjust.
• In places where the rule of law does prevail, one is expected to suffer insults without resorting to violence. But in a lawless society, a willingness to suffer insults indicates weakness that, in turn, may invite attack.
• Systems in which two great powers confront each other in a ritualized struggle, as in the Cold War, tend to be more stable than the present one, in which there are many secondary powers while the primary power is still not a Leviathan.
• Social theories tend to be linear. They describe a series of incidents and processes leading toward some definable end. But the world is characterized by simultaneity: many different kinds of incidents and processes happening at the same time leading toward different ends. Thus at best, a social theory is a useful failure; rather than prove its point, it gives people a new perspective on events, making them see the familiar in an unfamiliar light. Because all of these theories—optimistic and pessimistic—capture some important trend in a world going in different directions at once, they can be synthesized into a composite global picture that for all its complexity and contradictions has a concrete theme.
• Only through stealth and anxious foresight can America create a secure international system.
• The larger the scope of our imperium, the more complex our civilization becomes—with its rapidly expanding technical and scientific mandarinate—the more comfortable a statesman must be with loneliness.
• Because the very size and complexity of our political and military establishments are what make them so vulnerable, our salvation will lie with generalists who are not intimidated by the specialists under their command.
• True bravery and independence of thought are best anchored by examples from the past, culled from the pages of the great books.
• Effective leadership will always reside within the mystery of character.
• The more successful our foreign policy, the more leverage America will have in the world.
• The more respect we have for the truths of the past, the more certain our journey away from it.