Cycle Time

Entry Question: How do I reduce cycle times for products I care about?

---

Put that in your pipe

We want every action to have an impact. What is the point of hard work if you miss the target? Thus, we judge everything by its consequences. Not by the intentions, not by the worthiness of the actions, only the consequences. This is what we call Consequentialism. Or Rationality!

How do we avoid fruitless work in real life?

We want to optimize certain things in life. As terminal goals, we want to optimize our health, wealth, happiness, relationships, etc. To reach those goals, we have certain instrumental goals - get to a healthier body-fat level, create a successful company, practice various happiness habits, learn certain social skills, etc. We can think of these as Products.

There are several actions that can affect the final Products - the food we eat, the work we do, the skills we practice. We can think of these as Changes.

Here’s the nub: We want each Change to improve the Product somehow. Else, it is a pointless “Change”. However, several factors distort the flow. For one, we may think that the Change will improve the Product, but we may be wrong. Worse, the Change will actually improve the Product, but with a long delay (as with exercise and health) and so we may ditch it prematurely.

In short, we want each Change to actually cut through to the final Product and cut through fast.

Deployment Pipeline

Enter this fascinating programming book called Continuous Delivery. The authors suggest that the way to make each Change actually cut through is by automating the flow as much as possible. Ideally, the Product should start getting updated whenever you make a Change. More importantly, to cut through fast, we need to reduce the cycle time - the time it takes to go from making a Change to seeing an improvement in the Product.

In short, you have a Deployment Pipeline from Change to Product. You need to ensure that whenever you make a Change, the Pipeline quickly gets triggered and starts rebuilding the Product. You want to make sure you get high quality - that each Change really is reflected in the Product. Next, you want to minimize the cycle time - the time it takes for Changes to propagate through the Pipeline.

The question is now: how do we minimize cycle time and get high quality?

The answer from Continuous Delivery: Make frequent, automated releases and have visible feedback.

By making frequent releases, at each point, you make small changes and so you have lower risk. You always have the confidence of a working release behind you, and can experiment boldly. You get faster feedback about the Product and can “benefit from the most useful source of information available: the experience of implementing it” ¹. The more often you release, the more you get feedback and the more you can improve your Product.

By automating the release process, you have control over the way each Change affects the Product. Because computers work more reliably, you’re guaranteed that each step you take is fruitful and is actually having an impact.

Why do we need feedback? Because we don’t have an accurate model of reality. The model we have in our head is nowhere near as informative as the actual Product. We simply can’t consider all the variables and possibilities. You should be surprised if the final Product is exactly as you dreamed it would be.

So, design your feedback mechanism to tell you where you’re wrong. Feedback should change your path. If you aren’t where you want to be, you must change to get there.

---

So, frequent releases give you lower uncertainty about your next change (you don’t have to worry about the rest of the program), a working product at each point, and faster feedback. What is this “feedback”? It’s nothing but our friend “information”. Frequent releases thus give you faster information, which is what we want.

Continuous Delivery and Motivation

Short cycle time leads to low delay. As per the Motivation Equation, you feel high motivation for actions with low delay. So, you will probably only do things for which you have low cycle time. (Examples? Counter-examples?) Conversely, you won’t do things that have high cycle time. This leads to a reinforcing feedback loop - they have high cycle time, so you don’t do them frequently, which leads to even higher cycle time (because things pile up) and so on, until it goes into oblivion.

Lower risk means you feel higher value. The Continuous Delivery authors mention that by releasing frequently you lower the risk of any new change. If anything goes wrong, you can always rollback to a working state. You can thus experiment with no downside. Actions that were earlier daunting now seem attractive.

Frequent releases give you higher expectancy. Because you want to release frequently, you work in small manageable increments. And since the previous state is known to work, you can code with confidence. This means that you have higher expectancy of success and thus feel more motivated.

So, having a snappy Deployment Pipeline with low cycle time and frequent releases will give us high motivation. We will do things we had put off earlier.

Putting the Rapid in Rapid Prototyping

Once you have Rapid Prototyping going, you implement features in the time you would have taken to add it to your to-do list. There’s just no waiting period. Got an idea? Implement it right away!

PG was right. Both about the fact that once you are able to implement your ideas, you start having more of them, and about the fact that you rarely have to maintain a formal to-do list. You just implement what you want. Having a working release gives you the confidence and ability to do that.

What big companies do instead of implementing features is plan them. At Viaweb we sometimes ran into trouble on this account. Investors and analysts would ask us what we had planned for the future. The truthful answer would have been, we didn’t have any plans. We had general ideas about things we wanted to improve, but if we knew how we would have done it already. What were we going to do in the next six months? Whatever looked like the biggest win. I don’t know if I ever dared give this answer, but that was the truth. Plans are just another word for ideas on the shelf. When we thought of good ideas, we implemented them.

– Paul Graham, The Other Road Ahead

Another benefit of frequent releases is that your mind is empty. You don’t have to keep a huge context in your head. It’s all in the source code, and it is well-tested! You can go and do what is needed with a minimum of fuss. This provides us with a test for a good deployment pipeline: is your mind empty? Can you go forth with a clear head or do you have to keep lots of things in mind (do this, do that, then do that)?

Your cycle time should be so low that when you have a new idea, you should implement it immediately. To-do lists are a deployment smell.

Forbid

Ok. What can’t a good Deployment Pipeline do?

Have you done frequent, automated releases of something and still failed to get what you want?

Open your eyes. You’ve had several things on your Dashboard for the past week or so. What came of it? You haven’t done much about your Git stats. Or your arbtt stats (consciously).

Your Dashboard is feedback. What has it made you change? You can maintain a count of how many times you changed because of the feedback.

Predict what you expect to see (no, not insane improvement) and check it against what actually happened.

Taboo the word Dashboard. What do you really expect to see? I expect that I will act immediately upon its feedback, that I will not let any warning stay there for more than a day. But, what happened? Well, I haven’t really taken too much action on the stuff there. I’ve ignored it’s warnings about the unstaged git changes or my time usage or about my practice hours. Worst of all, I’ve just gone and done whatever I wanted. The dashboard doesn’t write my bottom line, something else does.

What went wrong? Well, I don’t use the dashboard to decide what to do.

New prediction: If I make the dashboard useful enough and only use it to decide what to do, I will get things done.

In short, the feedback that the dashboard displays must be something you can actually affect. The shorter the cycle time the better, but it must be something you can affect directly.

What should feedback do? It should test if your product has the features you want. For an essay, it should test if there are a number of surprising ideas in there, etc.

---

Actually, feedback is nothing but evidence. So if your dashboard is to be useful, it should provide evidence about your overall hypothesis. You’re trying to get a good hypothesis about your project domain - aka “what kind of project would get me the result I want?”. So, to get experimental evidence, you need to intervene by changing your project and then observe the result on your dashboard. So, your dashboard stats must ideally display the key variables you’re trying to affect.

For example, if your project is about implementing eight features in a program, your dashboard should at least display how many of those eight features have been implemented. This way, you get strong evidence about whether your hypothesis is accurate. If you thought your new change would add a feature but it didn’t, then it means your hypothesis was wrong.

Consequentialism

What makes a good pipeline? You should have pressure on you to keep improving the product over time. The quality of the product (the features in a program, the number of ideas in an essay, etc.) is all that matters. And it must go up.

In fact, in a good pipeline, it will be obvious if you aren’t actually improving the product. For example, in a program, you must increase the number of features over time. Even speeding it up or using less space is a feature. Programmers are in the business of producing features, their clients or bosses demand those features, so they have to keep doing whatever improves the features, nothing else. Similarly, for essay-writing; the number of surprising ideas must go up or the quality of your prose must improve. You cannot let it stagnate - readers will notice.

As an example of a bad pipeline, look at that of building an accurate model of the world around us. The aim is obviously to increase our predictive power. The better we can predict the world, the more we can achieve what we want. But, there doesn’t seem to be direct pressure on us to increase our predictive power. So, we do pointless things, actions that don’t really matter.

We should design our pipeline so that it is immediately obvious when we aren’t actually making progress.

A corollary of consequentialism is that if you’ve decided what products really matter, you must do them as much as possible, to the exclusion of others things if necessary. Do only what matters. Don’t waste time on nonsense.

So far, we’ve talked about decreasing the cycle time and increasing quality. Now, focus on practicing the skill of doing whatever it takes to optimize the product. This is what we call intent to kill. Ignore conventions; ignore the rules. How can you maximize your goal? Think of wacky solutions. Blast through cached thoughts.

Fundamental Questions of Deployment

How can we diagnose a Product we want to optimize?

• When was your last release?

• How frequently do you release?

• How do you get feedback?

• When did you last change your path because of feedback?

We want to minimize the cycle time. However, simply aiming to do that may not be good enough. I procrastinate by saying that I will only work when the cycle time is super-short. That’s why you need to aim to release something, yesterday. Even if it is something crappy, you’re making progress. You can correct course with feedback.

To paraphrase HPMOR, a flat metal plate on a door affords pushing, and a handle on a door affords pulling, and the thing to do with a project is to go and release it.

---

Let’s go through some of the important Products in my life and optimize their Deployment Pipelines.

Low Cycle Time implies High Rate of Valuable Information

What happens in each cycle? We get information from our feedback mechanism. We get a message, like from a coach: “slightly faster”, “more to the left”, or “correct”. Why do we want to minimize cycle time? So that we maximize our rate of information (technically, our rate of uncertainty reduction). We want to get messages as fast as we can.

Woah! It’s not just that you get a very high rate of expected information. You get a very high rate of expected valuable information!

That means having a low cycle time is the most efficient way to do things! That is how you maximize expected value of information and who doesn’t want that. That is how you should run a business. (I note that startups, especially from YC, seem to already be running on these principles. Who said the world is irrational?)

This means that the idea of rapid prototyping, with fast iterations and thus low cycle time, is really the optimal way to do things. Of course, people may not be following it perfectly, but every step you take along that direction will pay dividends. Note that each iteration must give you valuable information, i.e., something that can change your decisions in a major way. Otherwise, there’s no point in iterating rapidly.

What does it mean to “release”?

To release a product is to run your tests. A successful release means either that your failing tests now pass or that your existing tests still pass but your code is better designed.

So, it’s not necessary to keep “releasing” your product again and again. If you haven’t made any changes in a while, you’re sure that your tests still pass and therefore you gain no information by “releasing” aka running your tests.

In the case of an essay, the tests are run in the mind of the reader. Does he find the lead tempting? Does he get confused by your explanation of a concept? This is why you need to physically release your essay to others.

In the case of a program, however, the tests are run on your own computer. You basically add a test for every feature you want your program to have and then write code till the tests run (and then refactor in the next cycle).

Regression Testing

Hypothesis: Continuous delivery = do you have a quick and satisfying response to each scenario?

When programming, do you pass the unit and integration tests? Do you have unit tests for each function?

When essay writing, do you have a good lead and end for the essay, good lead and end for each paragraph, logical flow among paragraphs, examples for each concept, surprising ideas, and evidence for each assertion? Does the essay read well?

When practicing a skill, do you have a quick response for each of the scenarios? I need to collect categories and some of their key scenarios, and see if I can produce the correct response. For example, when practicing the scientific method, I need to… uh… damn. Take a more concrete skill, like chess. Do you know how to recognize a board state when you need to move your queen forward (or whatever)? When expressing a sentence, do you save the bang for the very end?

So, that’s another type of test.

Hypothesis: Given a scenario, check if your response satisfies certain properties.

I believe they call this regression testing - making sure that you haven’t lost any of your old features. This helps when you don’t have a particular correct answer in mind, but know some of the properties you want your answer to satisfy. For example, you might want the running time of your program to decrease (or remain steady) with each new version. Ditto for the memory used.

For example, for essay writing, your sentence must branch to the right, maintain parallelism when possible, and among others end with a bang.

When releasing a plan, check if you have a clear deadline and a succession of small problems instead of a monolithic goal.

Similarly, for the scientific method, when solving a problem, did you use the Baconian method? Did you toggle variables quickly? Did you use the evidence efficiently or were you trying things at random?

Corollary: One major property is speed. You want your speed to increase over time, even when your answer is the same.

For example, you want to toggle variables and hit upon the correct hypothesis within minutes. Any fool can do it in a week of hard work.

Similarly, you want to write programs within a fraction of an hour. If you currently take an hour to write a toy program, try to cut it down to thirty minutes.

Hypothesis: The hard part is handling change. You have to make sure that your product meets your criteria even after you’ve changed it.

For example, whether your essay still flows and still has examples for each concept, whether your problem-solving speed has improved, and whether your plan still has fine-grained goals with feedback.

Releasing Skills

Hypothesis: Releasing your list of skills = measuring your current speed for each of them on representative problems so that you can judge whether you’re growing or slipping.

Remember, it’s not a binary question of having the skill vs not having it. It’s a matter of degree. How good are you?

TODO: Check if speed is the only property that matters for your list of skills and habits. What about habits? Maybe it’s about the number of times you’ve done them in the last month. You want that number to not slide.

Test: Skills - Is speed what I care about?

Variable: speed.

Categorizing situations - I want to do it more often. For example, I want to trigger the category “shallow work” when I sit around watching YouTube videos or movies.

Observation: I care about actually applying “continuous delivery” to my programming or essay writing. It’s not the speed; it’s the mere application.

Variable: last time you used that skill. For example, the last time you recognized “deep work”.

Variable: number of times you’ve used that skill in the last week or last project. For example, the number of times you recognized “low expectancy”. Or the number of times you’ve used a writing tip from the 50 tips book.

Variable: % of times you’ve used that skill when you needed to. (Eventually this should tend to 100%. At that point, what you care about is your speed.)

Variable: quality of your output.

For example, the “quality” of the metaphors you use. Or the size of your comfort zone.

---

Hypothesis: Variables for skill feedback: application, quality, speed.

Releasing Habits

What are the variables I care about?

Variables: application

example: don’t accept adjectives from others; read books every week.

Hypothesis: Variables for habit feedback: application.

All about Tests

Hypothesis: To get costly information cheaply, use continuous delivery - frequent, automated releases. That way you can reduce your uncertainty about your plan without releasing it to production.

Hypothesis: Iterate = increase the scope of your tests.

For example, test whether your program can handle simple inputs. Then test for more complex inputs, and so on.

Hypothesis: Goal = test for success. That is, victory condition.

Hypothesis: Aim for something less than perfect -> less anxiety. Basically, use a ladder to work your way towards your ultimate goal.

Hypothesis: A technique can be used as a test if you know that the only way to pass that test is by using the technique.

For example, the only way to not feel bad after talking to others is by not allowing them to talk about stuff outside your identity. So, use that as your test.

Practical Continuous Delivery: Makefiles

Hypothesis: Use can use a Makefile to represent the dependency tree for your deployment pipeline. And it already caches intermediate stages.

Old Ideas

Website

The Product here is a collection of surprising, informative essays on my website. My website should reflect the ideas in my head, and thus reflect their Changes. I get ideas by writing notes in my diary, Org files, phone (when I’m on the go), reading books (whether or not I make notes), and discussing with friends.

Now, I release my website every night through a script. So, I do in fact have frequent, automated releases here. However, the problem isn’t with releasing the essays I’ve written up inside my website directory. It’s with the ideas I haven’t written down, the drafts I haven’t cleaned up, and the old essays I haven’t updated yet. That is where my cycle time skyrockets.

When was the last time I released an idea from my diaries? A long time ago. I’m routinely surprised when I flip through the pages - I’ve forgotten much of it. Similarly, I can’t remember the last draft I turned into an essay, or the last essay I updated. Worst of all, I have this file called “Website-Notes.org” burgeoning with all kinds of “great” ideas. None of them have seen the light of day.

I need feedback about the ideas I haven’t implemented (perhaps by looking at the index of my diaries), about the number of drafts (should ideally be zero), and about essays that are out of date. I need to calculate some of them manually - for example, going through my essays regularly and seeing which ones need updating.

Delay Times?

To reduce cycle time from idea to website, I have to eliminate my Org notes. Right now, they’re an intermediary, a buffer. Hence, a delay between an idea and its explanation. Maybe Next-Actions can stay. But everything else would have to go on the website.

Plus, now that we have nightly builds, we can just add stuff to the various Notes pages and get them reflected to the website automatically. No extra hassle. No more excuses. That’s what you get with automation!

Hmmm… One way to keep my Website synced with my Notes is to use only the Website as my View. No direct viewing of the notes files. That way, I lengthen the cycle time of mere “notes” lying around on my computer And shorten the cycle time of stuff that is part of my website.

No reading of Org notes. No reading of Diary notes. No reading of Phone notes. They are all just inputs, not outputs. The Model to my website’s View.

Release Frequently

For each essay, when was the last time I polished or updated it?

For feedback, I should look at the website from the eyes of a smart reader who’s never seen it before. It should make sense. Just having a bunch of essays, up there somewhere, is not good enough.

Principles

Every time you change an Org notes file, create a Website notes page instead.

Website Notes - Avoid a “Notes” section. That’s just a loophole for disorganized crap.

Also, eliminate the Notes directory. You have essentially created another development branch, which violates the continuous delivery principle of having one master branch and always checking into that. The Notes directory simply won’t get as much TLC as the main branch (my main essays) because I won’t expect anybody to read them. They will rot over time, is what I’m saying.

Your essays are going to be with you forever. No hurry. Don’t create crap just because you have to “get it done” soon. Get it right. Focus on a few essays and really optimize them. Expect to collect evidence over time. Design for it: your thoughts will change. Keep your essays open to change.

---

Writing an Essay

The Product here is a surprising and well-written essay. The ideas in my head are the Changes that can affect the final Product.

For each idea, I need to ask when I last released it. More generally, how frequently do I release it? I haven’t even released a bare-bones version of any of them. No wonder it’s daunting to think of adding them.

Feedback for an essay could be a bunch of tests. For example, does it flow from premises to conclusions for a neutral, smart reader? Have you specified everything needed? This is not trivial. Most of the time, the change I make before releasing an essay is to make sure it flows, i.e., it doesn’t quite flow before that. So, each time you want to release, actually read the essay from start to finish and change what doesn’t flow.

For each section of an essay, ask yourself: when was the last time you released it? It’s ok if it isn’t perfect yet, just release it and keep iterating. Take it one section at a time.

Don’t expect to set aside time for improving essays. That will probably never happen. Go through your essays once in a while, and if you see something that can be improved, just do it. That’s how things get done, one little bit here and there. Aim to improve at least one section each day or so, for some essay on your website. It adds up.

Rationality Techniques

Product: Actually benefiting from those techniques

Changes: Acquiring, Learning, and Applying them (as per the Technique Trap).

Feedback: How will I know that I have got the Product (i.e., benefited from the techniques)?

I need Feedback Mechanisms for those techniques. I don’t have these right now. However, the excellent book How to Measure Anything should help.

Cycle Time: How long does it take to actually start getting benefits from a technique?

Say I acquire a new technique or hear of a variation on an existing one. How long till I can start learning it? If I start learning a technique, how long till I can start to apply it? And if I start applying a technique, how long till I can see the results?

Concrete examples:

• Empiricism - searching for empirical evidence to back or oppose some claim
• Anticipation-Constraints - Asking what a theory forbids
• Bayes Theorem - Generating hypotheses, looking at Differing Predictions, running hypothesis tests, and updating on evidence.

To reduce cycle time and get high quality, we need to have frequent, automated releases.

Empiricism

What would it mean to have frequent, automated releases of the technique of Empiricism?

We need to release frequently to get quicker feedback and reduce the risk of new actions. If anything goes wrong, we can always rollback to a version that worked.

So, right now, I’m trying to be empirical in my essays. I plan to go through my old essays and add citations and such for the important assertions.

Ok. So, how do you know you’re really making progress, as opposed to just doing busywork? Why is it so important to be “empirical” in your essays? How does that produce value?

Taboo the word “Empiricism”. What do you really want to do more of?

Regarding beliefs, I want to believe only those things that are backed by evidence. I want to notice when I’m making unsupported claims. I want to be able to get quality empirical evidence, say by studying good textbooks or scientific papers.

Regarding techniques, I want to acquire only those techniques that are backed by solid empirical evidence. I want to purge my mind of techniques that don’t work but that I think they do. I also want to get rid of Affective Death Spirals about techniques - places where I believe something is an “Epic Awesome” technique when it is just an ordinary one.

Next, I want to actually learn the techniques using accurate instructions. I want to actually look at the instructions from an authoritative source instead of just going by my own impression. I need to enumerate the various scenarios for the particular technique, and build my skill in each of them.

Finally, I want to actually apply my techniques. A lot. I need to have empirical evidence saying that I have indeed applied so-and-so technique hundreds of times.

So, what is the Deployment Pipeline here? What are the changes and what are the products that must reflect those changes promptly?

For beliefs, the product is a belief with empirical evidence. Whenever I get a new belief or remember an unquestioned belief or come across new evidence, I need to update the product.

For acquiring techniques, the product is (the name of) a technique backed by empirical evidence. I need to update it whenever I get new evidence or come across new techniques.

For learning techniques, the product consists of the instructions, the Feedback Mechanism, the various scenarios the technique deals with, and lots of practice handling these scenarios using these instructions correctly as per the feedback. As each of those components changes, I need to change my routine. If my understanding of the instructions changes, or if I improve the Feedback Mechanism, or come up with different scenarios, I need to learn again - I need to practice with the new configuration. That is the only empirical way to know that I’ve learned the technique.

For applying techniques, the product is the benefit I get from the technique. I observe the benefit using a Feedback Mechanism. I need to apply each technique several times, maybe hundreds of times.

Cool. So, that is what Empiricism actually means to me.

For each of the above pipelines, we need to minimize the cycle time (reflect changes as soon as possible) and also get high quality (actually get the results). For that, the authors of Continuous Delivery recommend doing frequent, automated releases. Note that if I haven’t run the pipeline at all, the belief or technique has a cycle time of infinity. Bad.

Now, how do I create frequent, automated releases of the above pipelines?

At first, I need to get to Hello World - a Minimum Viable Product, if you will - and then take it from there. A belief with bare minimum empirical evidence; a technique with the same; a technique with simple instructions, a simple Feedback Mechanism, and one scenario. So, I will have a working pipeline for each of the above. From now, it’s a matter of iterating.

For beliefs, I need to accumulate evidence incrementally and update the product (belief + some empirical evidence). I need to do this nearly automatically after I come across new beliefs or evidence. Not quite sure how to do that. Maintaining a queue of beliefs and evidence might help. I can also forbid myself from using any beliefs other than the empirically-backed ones I’ve maintained on my website.

For acquiring techniques, I can do frequent releases by adding evidence incrementally.

For learning techniques, I can do frequent releases by keeping track of the components of each technique on my website. If one of them changes, say I discover some more scenarios for a technique, I can immediately practice handling them. To this end, I can maintain a Counter list of how many times I’ve practiced each scenario.

For applying techniques, I can again maintain a Counter for how many times I’ve applied a technique.

The common idea is that I need to reduce the cycle time by whatever means, and releasing frequently forces me to do so. I will start finding all kinds of ways to get it done. The key to making the pipeline nearly automatic might be to forbid myself from using a belief or technique unless I’ve updated it through the pipeline.

Worthiness and Embracing Vulnerability

Fat loss and muscle gain

Changes Healthy or unhealthy food Cardio Weight-lifting Sleep Supplements Feedback Weight Body Fat level Muscles Delay Times?

Eye sight

Changes Wearing or not wearing glasses Looking outside frequently

Sleep

Stress

My coding projects

Maintaining them

Worthiness and Embracing Vulnerability Practice

Skills

My skill is the product here, and the my understanding of the technique is the change that it should reflect. Over time, my skill should reflect the technique. When I find a new technique or update my knowledge of an existing one, I should practice it and burn it immediately into my brain. Even if it just means practicing for five minutes.

Right now, I haven’t practiced my existing techniques at all. Their cycle time is infinity. I should do them at least a little bit. Instead of trying to do the state-of-the-art technique in a perfect manner, do some of the rudimentary ones in a quick and dirty way. Be ridiculously inefficient at first and take it from there.

Prediction Book

When was the last time you added a prediction there? Just do one prediction, for now. Just release.

Long Projects

Need to crack upon my list of long-term projects and start releasing them frequently.

Possessions - Cleaning and Maintenance

Cycle: Dirt on the floor -> Clean floor

Drills

When was the last time you added to your drills? Do it more frequently, even if it is just a couple of drills at a time. It adds up.

Friends?

When was the last time you spoke to a particular friend? Perhaps you should reduce the time between contact.

Washing the Dishes

When was the last time I washed the dishes? A day ago. The cycle time for dishes seems to be on the order of days, when I want it to be exactly one day. I still don’t know if I can do that everyday, though.

Waking up early

When was the last time I woke up early? Blank. When was the last time I went to bed by 11pm? Blank. When was the last time I didn’t watch Youtube videos on my tablet for hours before falling asleep? Blank.

I need to release at least one version - i.e., wake up early once, by whatever means. After that, I can continue doing so more easily.

Book List

When was the last time I read each book (or marked them as “no longer interesting”)?

The same goes for my movie list or song list or TV show list.

Science

In science, the deployment pipeline is from evidence to hypotheses. Whenever you see new evidence (change), you need to update your hypotheses (product). We want to minimize the cycle time between seeing new evidence and updating on it. We never update on much of what we see, making the cycle time infinity by default.

Actually, the product is the predictive power of your causal model. And it should increase over time, else all your effort is in vain. So, there’s constant pressure on you to keep improving your model and make it handle more states more accurately.

comments powered by Disqus

Site proudly generated by Hakyll