Measure What Matters by John Doerr

• As much as I hate process, good ideas with great execution are how you make magic. And that’s where OKRs come in.
• Ideas are easy. Execution is everything.
• The practice that molded me at Intel and saved me at Sun--that still inspires me today--is called OKRs. Short for Objectives and Key Results. It is a collaborative goal-setting protocol for companies, teams, and individuals. Now, OKRs are not a silver bullet. They cannot substitute for sound judgement, strong leadership, or a creative workplace culture. But if those fundamentals are in place, OKRs can guide you to the mountaintop.
• An Objective is simply what is to be achieved, no more and no less. By definition, objectives are significant, concrete, action oriented, and (ideally) inspirational. When properly designed and deployed, they’re a vaccine against fuzzy thinking--and fuzzy execution.
• Key Results benchmark and monitor how we get to the objective. Effective KRs are specific and time-bound, aggressive, yet realistic. Most of all, they are measurable and verifiable. You either meet a key result’s requirements or you don’t; there is no gray area, no room for doubt.
• Where an objective can be long-lived, rolled over for a year or longer, key results evolve as the work progresses. Once they are all completed, the objective is necessarily achieved.
• OKRs surface your primary goals. They cannel efforts and coordination. They link diverse operations, lending purpose and unity to the entire organization.
• For anyone striving for high performance in the workplace, goals are very necessary things.
• In the technology sector, two out of three employees think they could find a better job inside of two months.
• An effective goal management system--an OKR system--links goals to a team’s broader mission. It respects targets and deadlines while adapting to circumstances. It promotes feedback and celebrates wins, large, and small. Most importantly, it expands our limits. It moves us to strive for what might seem beyond our reach.
• The higher the ratio of reports, the flatter the org chart--which means less top-down oversight, greater frontline autonomy, and more fertile soil for the next breakthrough. OKRs help make all of these good things possible.
• High-performance organizations home in on work that’s important, and are equally clear on what doesn’t matter. OKRs impel leaders to make hard choices. They’re a precision communication tool for departments, teams, and individual contributors. By dispelling confusion, OKRs give us the focus needed to win.
• Andy Grove’s quantum leap was to apply manufacturing production principles to the “soft professions,” the administrative, professional, and managerial ranks. He sought to “create an environment that values and emphasizes output” and to avoid what Drucker termed the “activity trap”.
• On an assembly line, it’s easy enough to distinguish output from activity. It gets trickier when employees are paid to think.
• “Bad companies,” Andy wrote, “are destroyed by crisis. Good companies survive them. Great companies are improved by them.”
• An effective goal-setting system starts with disciplined thinking at the top, with leaders who invest the time and energy to choose what counts.
• Leaders must get across the why as well as the what.
• Don’t allow the perfect to be the enemy of the good.
• Remember that an OKR can be modified or even scrapped at any point in its cycle.
• Sometimes the “right” key results surface weeks or months after a goal is put into play. OKRs are inherently works in progress, not commandments chiseled in stone.
• A few goal-setting ground rules: key results should be succinct, specific, and measurable.
• As Steve Jobs understood, “Innovation means saying no to one thousand things.”
• In most cases, the ideal number of quarterly OKRs will range between three and five.
• Too many objectives can blur our focus on what counts, or distracts us into chasing the next shiny thing.
• We learned the three watchwords for entrepreneurs:
• Solve a problem
• Build a simple product
• Talk to your users
• Research shows that public goals are more likely to be attained than goals held in private.
• One underrated virtua of OKRs is that they can be tracked--and then revised or adapted as circumstances dictate.
• Annual performance reviews are costly, exhausting, and mostly futile.
• In short, we need a new HR model for the new world of work. That transformational system, the contemporary alternative to annual reviews, is continuous performance management.
• It is implemented with an instrument called CFRs, for:
• Conversations: an authentic, richly textured exchange between manager and contributor, aimed at driving performance.
• Feedback: bidirectional or networked communication among peers to evaluate progress and guide future improvement.
• Recognition: expressions of appreciation to deserving individuals for contributors of all sizes.
• For companies moving to continuous performance management, the first step is blunt and straightforward: divorce compensation (both raises and bonuses) from OKRs. These should be two distinct conversations, with their own cadences and calendars.
• Feedback can be highly constructive--but only if it is specific.
• Continuous recognition is a powerful driver of engagement.
• Recognize people for actions and results.
• Corrective feedback is naturally difficult for people. But when done well, it’s also the greatest gift you can give to someone--because it can change people's mindset and modify their behavior in the most positive, valuable way.
• People watch what you do more than what you say.
• Ideas are easy; execution is everything.
• Poorly done/managed OKRs are a waste of time, an empty management gesture. Well done OKRs are a motivational management tool that helps make it clear to teams what’s important, what to optimize, and what tradeoffs to make during their day-to-day work.
• Objectives are the “Whats”. They:
• Express goals and intents.
• Are aggressive yet realistic.
• Must be tangible, objective, and unambiguous; should be obvious to a rational observer whether an objective has been achieved.
• The successful achievement of an objective must provide clear value for Google.
• Key results are the “Hows”. They:
• Express measurable milestones which, if achieved, will advance objectives in a useful manner to their constituents.
• Must describe outcomes, not activities.
• Must include evidence of completion.
• OKRs have two variants, and it is important to differentiate between them: commitment OKRs and aspirational OKRs.
• OKRs are often written principally based on what the team believes it can achieve without changing anything they’re currently doing, as opposed to what the team or its customers really want.
• If your objective doesn’t fit on one line, it probably isn’t crisp enough.
• Four superpowers of OKRs:
• Focus and commit to priorities.
• Align and connect for teamwork.
• Track for accountability.
• Stretch for amazing.
• Too many OKRs dilute and scatter people’s efforts.
• Expand your effective capacity by deciding what not to do, and discard, defer, or deemphasize accordingly.
• In choosing OKRs, look for objectives with the most leverage for outstanding performance.
• When leaders openly admit their missteps, contributors feel freer to take healthy risks.
• Establish an environment where individuals are free to fail without judgement.
• To get leaps in productivity or innovation, follow Google’s “Gospel of 10x” and replace incremental OKRs with exponential ones. That’s how industries get disrupted and categories reinvented.

Smart & Gets Things Done by Joel Spolsky

• The process of hiring great technical talent is an elimination course.
• But there’s a silver lining, if you will: a bright side to all this meandering mathematical moroseness. And that is this: if you can eliminate one obstacle--just one!--you can double the number of people you hire. Eliminate two obstacles, and you quadruple the number that make it past the remaining obstacles. And so on, and so forth.
• But there is no silver bullet. There is no magical single thing you can do to solve all your hiring problems and get great developers working for you tomorrow.
• What you have to do is look at the whole process as an obstacle course and start to think about how to eliminate as many obstacles as possible.
• Duplication of software is free. That means the cost of programmers is spread out over all the copies of the software you sell. With software, you can improve quality without adding to the incremental cost of each unit sold.
• Essentially, design adds value faster than it adds cost.
• The quality of the work and the amount of time spent are simply uncorrelated.
• A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on the same task must coordinate and communicate. That takes a lot of time.
• The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.
• The mediocre talent just never hits the high notes that the top talent hits all the time.
• People like to feel in control. It makes people happy to feel in control.
• It’s not just a matter of “10 times more productive”. It’s that the “average productive” developer never hits the high notes that make great software.
• The software marketplace, these days, is something of a winner-take-all system.
• The great software developers, indeed, the best people in every field, are quite simply never on the market.
• The average great software developer will apply for, in total, maybe four jobs in their entire career.
• The great college graduates get pulled into an internship by a professor with a connection to industry, then they get early offers from that company and never bother applying for any other jobs.
• The corollary of that rule--the rule that the great people are never on the market--is that the bad people--the seriously unqualified--are on the market quite a lot. They get fired all the time, because they can’t do their job.
• Numerically, great people are pretty rare, and they’re never on the job market, while incompetent people, even though they are just as rare, apply to thousands of jobs throughout their career.
• Think about where the people you want to hire are hanging out.
• The corollary of this rule is to avoid advertising on general-purpose, large job boards.
• One good way to snag great people who are never on the job market is to get them before they even realize there is a job market: when they’re in college.
• Even though only about one in three applications who make it to the in-person interview stage passes all our interviews, it’s really important that the ones who do pass have a positive experience.
• An internship program creates a pipeline for great employees, but it’s a pretty long pipeline, and a lot of people get lost along the way.
• We basically calculate that we’re going to have to hire two interns for every full-time employee that we get out of it, and if you hire interns with one year left in school, there’s still a two-year pipeline between when you start hiring and when they show up for their first day of full time work.
• That means we hire just about as many interns as we can physically fit in our offices each summer.
• No programmer in their right mind should ever sign a non-compete agreement, but most of them do because they can never imagine that it would be enforced, or because they are not in the habit of reading contracts, or because they already accepted the employment offer and moved their families across the country and the first day of work is the first time they’ve seen this agreement and it’s a little bit too late to try to negotiate it. So they sign, but this is one of the slimiest practices of employers, and they are often enforceable and enforced.
• [...] if the great programmers don't want to work for you, they ain’t gonna come work for you.
• Peopleware is a great book.
• There’s a strong culture in Silicon Valley that requires you to jam a lot of programmers into a big open space, despite a preponderance of evidence that giving them private offices is far more productive.
• No matter what you think about productivity, and no matter what you think about egalitarian workspaces, two things are incontrovertible:
• Private offices have higher status.
• Cubicles and other shared space can be socially awkward.
• A lot of tech people are remarkably unaware of the general condition of their office.
• There is simply no reason not to get your developers top-of-the-line computers, at least two large (21”) LCD screens (or one 30” screen), and give them free rein on Amazon to order any technical book they want.
• These are obvious productivity gains, but more importantly to our discussion here, they’re crucial recruiting tools, especially in a world where most companies treat programmers as interchangeable cogs, typists. Really, why do you need such a big monitor and what’s wrong with 15” CRTs?
• Software developers are not really all that different from regular people.
• All else being equal, developers are going to prefer an organization that treats them like stars.
• Keep reminding yourself that when your candidate goes home and has to make a decision about where to work, if everyone they met was glum, they are not going to have such a positive memory of your company.
• By the way, the original hiring rule for Fog Creek, stolen from Microsoft, was “smart, and gets things done.” Even before we started the company, we realized that we should add a third rule: “Not a jerk.”
• Who wants to work at a company where jerks are tolerated?
• Basically, if you’re going to hire smart people, you’re going to have to let them apply their skills to their work.
• Developers want to be hired for their skills, and treated as experts, and allowed to make decisions within their own realm of experience.
• Actually, politics happens everywhere that three or more people congregate, and it can be completely harmless.
• Programmers have very well-honed senses of justice. Code either works, or it doesn’t.
• And this is the kind of environment you have to create to attract programmers.
• When a programmer complains about “politics”, they mean--very precisely--any situation in which personal considerations outweigh technical considerations.
• Nothing is more infuriating than when a developer is told to use a certain programming language, not the best one for the task at hand, because the boss likes it.
• Nothing is more maddening than when people are promoted because of their ability to network rather than being promoted strictly on merit.
• Nothing is more aggravating to a developer than being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it.
• All in all, focusing on the social dynamics of your organizations is crucial to making a healthy, pleasant place to work that will retain programmers and attract programmers.
• To some extent, one of the best ways you can attract developers is to let them work on something interesting.
• If you can find ways for developers to get experience with newer languages, frameworks, and technologies, they’ll be happier.
• As a recruiter, your job is to identify the idealistic aspects of your company, and make sure candidates are aware of them.
• The real point of this section is to think of what your company stands for, how it’s perceived, and how it could be perceived. Managing your corporate brand is just as important for recruiting as it is for marketing.
• They don’t care about money, actually, unless you’re screwing up on the other things. If you start to hear complaints about salaries where you never heard them before, that’s usually a sign that people aren’t really loving their job.
• You do have to pay competitively, but all said, of all the things that programmers look at in deciding where to work, as long as the salaries are basically fair, they will be surprisingly low on their list of considerations, and offering high salaries is a surprisingly ineffective tool in overcoming problems like the fact that programmers get 15” monitors and salespeople yell at them all the time and the job involves making nuclear weapons out of baby seals.
• Sometimes a resume gives pretty strong negative clues that allow you to screen out applicants without going much further.
• We try to be selective about how we advertise our jobs, so as to limit the amount of noise in the resume pile.
• We look for evidence that the applicant is passionate about computers and really loves programming.
• That said, years of experience working with programmers have taught me that programmers who can communicate their ideas clearly are going to be far, far more effective than programmers who can only really communicate well with the compiler.
• Brilliant programmers who have trouble explaining their ideas just can’t make as much of a contribution.
• Another thing we look for on resumes is evidence that someone has gone through some highly selective process in the past.
• Our company criterion for selectivity is usually getting into a school or program that accepts less than 30% of its applications, or working for a company that is known to have a difficult application process, like a whole day of interviews. Getting into highly selective courses in the military or getting into highly selective units like the Marines, indicates someone who has made it through some kind of difficult application/selection procedure, and all in all this is a positive sign.
• People who have worked on operating systems or compilers are more hardcore than  people who have worked on simple database front-ends.
• Remember angina that I said that resume are a very weak way of judging programmers, and you only get the faintest signals from them; that said, some technologies are just harder than other technologies, and if you happened to have worked with them successfully, there’s a smidgen more evidence that you might be the right person to hire, so for the purposes of sorting resumes, difficult technologies tend to float you to the top, while claiming competence in say, Microsoft Word tends to float you toward the bottom.
• To top programmers, the most maddening thing about recruiters is their almost morbid fascination with keywords and buzzwords. The entire industry of professional headhunters and recruiters is bizarrely fixated on the simple algorithm of matching candidates to positions by looking for candidates who have the complete list of technology acronyms that the employer happens to be looking for.
• It becomes especially infuriating to realize that most of these recruiters have no idea what any of these technologies are.
• The reason recruiters do this is because it’s easy, it can be computerized, and it’s the only way they know how to judge developers. For almost all software development positions, though, it is the worst possible way to hire.
• Don’t start a new project without at least one architect with several years of solid experience in the language, classes, APIs, and platforms you’re building on.
• A phone screen has distinct advantages over a normal in-person interview. First, it’s cheap. [...] More importantly, it’s more fair.
• The bottom line in my interviewing technique is that smart people can generally tell if they’re talking to other smart people by having a conversation with them on a difficult or highly technical subject so that the interviewer’s judgement can form an opinion on whether this is a smart person or not.
• 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, including at least five who would be peers of that candidate (that is, other programmers, not managers).
• It’s too easy to fake out one interview, especially when a non-programmer interviews a programmer.
• If even two of the six interviewers think 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.
• In software, things change so often and so rapidly that you need people who can succeed at just about any programming task that you throw at them.
• Just say no! If you are on the fence, that means no hire.
• Don’t lower your standards no matter how hard it seems to find those great candidates.
• In principle, it’s simple. 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 than ship on time.
• 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 net liabilities to the company because not only do they fail to contribute, but they soak up good people’s time.
• How do you detect smartness in an interview? The first good thing is that you don’t have to explain things over and over again. The conversation just flows.
• Remember, smart does not mean “knows the answer to trivia questions.” Anyway, 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 who are going to be able to learn any new technology rather than people who happen to now how to make JDBC talk to a MySQL database right this minute.
• 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?
• Look for passion. Smart people are passionate about the projects they work on. They get very excited talking 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. I often reject candidates because when they talked about their previous project, they couldn’t explain it in terms that a normal person could understand.
• If the project was a team project, look for signs 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.
• Most of the time in the interview, though, should be spent letting the candidate prove that they can write code.
• If the basic concepts aren’t so easy that you don't have to think about them, you’re not going to get the big concepts.
• 15 years of experience interviewing programmers has convinced me that the best programmers all have aptitude for dealing with multiple levels of abstraction simultaneously.
• I’ve come to realize that understanding pointers in C is not a skill, it’s an aptitude.
• The optimal time to make a decision about the candidate is about three minutes after the end of the interview. Far too many companies allow interviewers to wait days or weeks before turning in their feedback. Unfortunately, the more time that passes, the less you’ll remember.
• 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.
• Remember: most normal recruiting in our society is structured as if the company has something precious (a job) that the individual wants. But when you’re recruiting top developers, the situation is completely reversed. Pay very, very close attention to the details of the entire recruiting, interviewing, and hiring process to make sure there are no accidental parts of the procedure that send any message other than “We’re not worthy!” to your star candidates.
• Great people are much, much more valuable than average people. In programming, they are three to ten times as productive, while only costing 20% to 30% more. And they hit high notes that nobody else can hit.
• An extremely people and seemingly scientific way to improve a team is with performance measurements and incentives. [...] This is a common management technique, and it’s devastatingly ineffective.
• In software development teams, everybody is working on something else, so attempts to micromanage turn into hit-and-run micromanagement. That’s where you micromanage one developer in a spurt of activity and then suddenly disappear from that developer’s life for a couple of weeks while you run around micromanaging another developer.
• The Econ 101 manager assumes that everyone is motivated by money, and that the best way to get people to do what you want them to do is to give them financial rewards and punishments to create incentives.
• Intrinsic motivation is your own, natural desire to do things well. People usually start out with a lot of intrinsic motivation. They want to do a good job.
• Extrinsic motivation is a motivation that comes from outside, like when you’re paid to achieve something specific.
• Intrinsic motivation is much stronger than extrinsic motivation. People work much harder at things they actually want to do. That’s not very controversial.
• When you use Econ 101 management, you’re encouraging developers to game the system.
• Developers are clever this way. Whatever you try to measure, they’ll find a way to maximize, and you’ll never quite get what you want.
• The biggest problem with Econ 101 management is that it’s not management at all: it’s an abdication of management. A deliberate refusal to figure out how things can be made better.
• Management, in general, needs to set up the system so that people can get things done, it needs to avoid displacing intrinsic motivation with extrinsic motivation, and it won’t get very far using fear and barking out specific orders.
• The real trick to management is to try to make people identify with the goals you’re trying to achieve.
• To be an Identify Method manager, you have to summon all the social skills you have to make your employees identify with the goals of the organization, so that they are highly motivated, then you need to give them the information they need to steer in the right direction.
• In general, Identify Management requires you to create a cohesive, gelled team that feels like a family, so that people have a sense of loyalty and commitment to their coworkers. The secondary part, though, is to give people the information they need to steer the organization in the right direction.
• The Joel Test
• Do you use source control?
• Can you make a build in one step?
• Do you make daily builds?
• Do you have a bug database?
• Do you fix bugs before writing new code?
• Do you have an up to date schedule?
• Do you have a spec?
• Do programmers have quiet working conditions?
• Do you use the best tools money can buy?
• Do you have testers?
• Do new candidates write code during their interview?
• Do you do hallway usability testing?
• If the [build] process takes any more than one step, it is prone to errors.
• Breaking the build is so bad (and so common) that it helps to make daily builds, to ensure that no breakage goes unnoticed.
• You absolutely have to keep track of bugs formally.
• “Zero defects” means that at any given time, the highest priority is to eliminate bugs before writing any new code.
• In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.
• There are extensively documented productivity gains provided by giving knowledge worker space, quiet, and privacy.
• Productivity depends on being able to juggle a lot of little details in short-term memory all at once. Any kind of interruption can cause these details to come crashing down.
• Top-notch development teams don't torture their programmers.
• Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer.
• To add to all this...programmers are easily bribed by giving them the coolest, latest stuff. This is a far cheaper way to get them to work for you than actually paying them competitive salaries!
• Do whatever you want during interviews, but make the candidate write some code.
• A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you unjustly wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.
• Good user interface design is not as hard as you would think, and it’s crucial if you want customers to love and buy your product.

Complexity: A Guided Tour by Melanie Mitchell

• Reductionism is the most natural thing in the world to grasp. It’s simply the belief that “a whole can be understood completely if you understand its parts, and the nature of their ‘sum’.”
• Reductionism has been the dominant approach to science since the 1600s.
• Since the time of Descartes, Newton, and other founders of the modern scientific method until the beginning of the twentieth century, a chief goal of science has been a reductionist explanation of all phenomena in terms of fundamental physics.
• In complex systems, many simple parts are irreducibly entwined, and the field of complexity is itself an entwining of many different fields.
• Common properties of complex systems
• Complex collective behavior
• Signaling and information processing
• Adaptation
• Now I can propose a definition of the term complex system: a system in which large networks of components with no central control and simple rules of operation give rise to complex collective behavior, sophisticated information processing, and adaptation via learning or evolution.
• Systems in which organized behavior arises without an internal or external controller or leaders are sometimes called self-organization.
• Since simple rules produce complex behavior in hard-to-predict ways, the macroscopic behavior of such systems is sometimes called emergent.
• Here is an alternative definition of a complex system: a system that exhibits nontrivial emergent and self-organizing behavior.
• The central question of the sciences of complexity is how this emergent self-organized behavior comes about.
• It was the understanding of chaos that eventually laid to rest the hope of perfect prediction of all complex systems, quantum or otherwise. The defining idea of chaos is that there are some systems--chaotic systems---in which even minuscule uncertainties in measurements of initial position and momentum can result in huge errors in long-term predictions of these quantities. This is known as “sensitive dependence on initial conditions”.
• A linear system is one you can understand by understanding its parts individually and then putting them together.
• A nonlinear system is one in which the whole is different from the sum of the parts.
• Seemingly random behavior can emerge from deterministic systems, with no external source of randomness.
• The behavior of some simple, deterministic systems can be impossible, even in principle, to predict in the long term, due to sensitive dependence on initial conditions.
• In summary, changing, hard-to-predict macroscopic behavior is a hallmark of complex systems.
• Dynamical systems there provide a mathematical vocabulary for characterizing such behavior in terms of bifurcations, attractors, and universal properties of the ways systems can change.
• In short, classical mechanics attempts to say something about every single microscopic entity by using Newton’s laws. Thermodynamics gives laws of macroscopic entities--heat, energy, and entropy--without acknowledging that any microscopic molecules are the source of these macroscopic entities. Statistical mechanics is a bridge between these two extremes, in that it explains how the behavior of the macroscopic entities arise from statistics of large ensembles of microscopic entities.
• Shannon’s definition of information involves a source that sends a message to a receiver.
• The second law of thermodynamics states that the total entropy of an isolated system will always increase until it reaches its maximum value.
• To summarize the major ideas of Darwin’s theory:
• Evolution has occurred; that is, all species descended from a common ancestor. The history of life is a branching tree of species.
• Natural selection occurs when the number of births is greater than existing resources can support so that individuals undergo competition for resources.
• Traits of organisms are inherited with variation. The variation is in some sense random--that is, there is no force or bias leading to variations that increase fitness. Variations that turn out to be adaptive in the current environment are likely to be selected, meaning that organisms with those variations are more likely to survive and thus pass on the new traits to their offspring, causing the number of organisms with those traits to increase over subsequent generations.
• Evolutionary change is constant and gradual via the accumulation of small, favorable variations.
• The collection of all of an organism’s physical traits--its phenotype--comes largely due to the character of interactions between proteins in cells. Proteins are long chains of molecules called amino acids.
• Subsequences of DNA from genes. Roughly, each gene codes for a particular protein. It does that by coding for each of the amino acids that make up the protein. The way amino acids are coded is called the genetic code. The code is the same for almost every organism on Earth.
• Each amino acid corresponds to a triplet of nucleotide bases.
• One simple measure of complexity is size. By this measure, humans are about 250 times as complex as yeast if we compare the number of base pairs, but only about four times as complex if we count genes.
• Another proposed measure of the complexity of an object is simply its Shannon entropy, defined [...] to be the average information content or “amount of surprise” a message source has for a receiver.
• An important missing piece for current day computers is the ability to make analogies.
• Perceiving abstract similarities is something computers are notoriously bad at. That’s why I can’t simply show the computer a picture, say, of a dog swimming in a pool, and ask it to find “other pictures like this” in my online photo collection.
• A model, in the context of science, is a simplified representation of some “real” phenomenon. Scientists supposedly study nature, but in reality much of what they do is construct and study models of nature.
• Models are ways for our minds to make sense of observed phenomena in terms of concepts that are familiar to us, concepts that we can get our heads around.
• Models are also a means for predicting the future [...].
• Network thinking means focusing on relationships between entities rather than entities themselves.