D. Chris Rayner
github • linkedin • google scholar
Hi! I'm a computing scientist interested in software quality and all sorts of problems in optimization and search. I completed my PhD in 2014 at the University of Alberta, where I machine-learned pathfinding heuristics. Since then I worked with a great team on advancing the search engine at Dissolve, and today I lead a team in Applied AI/ML at the IBM Global Chief Data Office… (see portfolio)
2023.10.28 # "Using sophisticated statistical scaffolding clouds our judgement. We end up using statistical methods as a crutch, not to dig signals out of noise, but to convince ourselves of signals when there are none." (Effect size is significantly more important than statistical significance)
2023.10.22 # "Raw data do not uniquely give rise to a single data set for analysis but rather to multiple alternatively processed data sets depending on the specific combination of choices… researchers should perform a multiverse analysis." (Increasing Transparency Through a Multiverse Analysis)
2023.10.21 # "It is unacceptably easy to publish 'statistically significant' evidence consistent with any hypothesis. The culprit is a construct we refer to as researcher degrees of freedom, [for example] (a) choosing among dependent variables, (b) choosing sample size, (c) using covariates, and (d) reporting subsets of experimental conditions." (False-Positive Psychology: Undisclosed Flexibility…)
2023.09.03 # "A history in which every particular incident may be true, may on the whole be false" – "a little exaggeration, a little suppression, a judicious use of epithets, a watchful and searching skepticism with respect to the evidence on one side, a convenient credulity with respect to every report or tradition on the other." (The Task of the Modern Historian)
2023.07.16 # "Proving an algorithm correct does not mean its implementation on a real system will necessarily always behave correctly [but] can uncover problems in an algorithm that might remain hidden for a long time in a real system." (Designing Data-Intensive Applications)
2023.07.07 # "It works! It does exactly what it's supposed to do… However it's also possible that if you refactor it you'll find something that you didn't know is true." (SOLID Object-Oriented Design)
2023.06.25 # "Code paths that handle failures are rarely tested/executed (for a reason). This makes them a good candidate for bugs." (39 Best Kept Secrets of Great Programmers)
2023.06.04 # "Experience is what you get when you didn't get what you wanted." (The Last Lecture)
2023.05.29 # "The greatest enemy of learning is what you think you know. When you think you know something, learning something new means you might have to change your mind, so it's easy to think there's no room for new ideas." (Accelerated Learning: Learn Faster and Remember More)
2023.04.29 # "Software performance today is not about learning to hand-write assembly language. It's more about learning to read things like assembly language, so you can understand how much actual work you are generating for the hardware." (Performance Excuses Debunked)
2023.04.28 # "Bottlenecks do exist. We should hunt them down and optimize them. But that's not what the [performance] hotspot model predicts: it predicts that it is all you need to do to get performance… Sadly, it does not work." (Hotspot Performance Engineering Fails)
2023.04.25 # "A [readability] hotspot is code with high development activity and frequent churn. It's code that's worked on often, and hence code that has to be read and understood frequently… often just 1-3% of the total code size." (Why I Write Dirty Code: Code Quality in Context)
2023.04.24 # "'Desk checking' (proof reading) is almost a lost art in 1993. Too bad. You should desk check your code before even compiling it, and desk-check it again periodically to keep it fresh in mind and find new errors. If you have someone in your group whose ONLY job it is to desk-check other people's code, that person will find and fix more bugs than everyone else combined. (merc's hacker.txt)
2022.11.27 # "While old code is likely to be good code in the sense that it has low maintenance costs and low defect risk, the same reasoning doesn't apply to test cases. Test cases tend to grow old in the sense that they become less likely to identify failures." (Your Best Bug Fix is Time)
2022.10.30 # "There is value in having consistency across the whole codebase, even if locally it means something is written sub-optimally. An inconsistent codebase is harder to read and understand (see point #1), write, and improve using automated tools." (Quora's principles for code quality)
2022.10.15 # "We do programmers a disservice when we act as if the conversation about the growing threat of legacy code begins and ends with COBOL… The real horseman of the legacy apocalypse is the depth of the dependency tree." (Old Code Gets Younger Every Year)
2022.09.08 # "If it's a core business function – do it yourself, no matter what. Pick your core business competencies and goals, and do those in house." (In Defense of Not-Invented-Here Syndrome)
2022.09.05 # Destructive decoupling "leads to a situation where the code is indeed decoupled but at the same time doesn't have a clear focus. Its parts are separated from each other so much that it becomes hard or even impossible to grasp their meaning." (Cohesion and Coupling: the difference)
2022.09.04 # "A module that you have designed to be easy to change can be made difficult to change by someone else who simply hangs a dependency on it… I metrics [instability scores ranging from 0–1] should decrease in the direction of dependency." (Stable Dependencies Principle)
2022.08.21 # "The stuff below you is huge at higher levels; the stuff below you is broken; everybody thinks high-level is easy, on the grounds that it's visibly faster; when you do something 'easy', too many people will tell you how it sucks, and you have to just live with that." (Low-level is easy)
2022.07.31 # "Being able to offload repetitive tasks to a program is one of the best things about knowing how to code. However, sometimes problems can't be solved by automation. If you're willing to embrace the grind you'll look like a magician." (Embrace the Grind)
2022.07.29 # Before automating the work, do it manually: "Opportunity to discover shortcuts before making a psychological commitment; task may turn out not to be worth automating; chance to discover which cases are common, which are rare; discovery is easier when done separately from automation; manual experience makes automation go more smoothly." (#nocode: Do the work)
2022.07.24 # "When we see advice telling us to do something small consistently, we usually scoff. After all, we are serious about what we do; we want to dedicate an hour, not five minutes to it. And we will definitely never skip a day. That's until you realize that it's not you talking, it's the highly motivated version of you." (The Value of Doing a Little)
2022.07.23 # "When I have a to-do list, I follow it more reliably if it's on a sheet of paper, rather than in a notebook with a cover… You want to design your life for the least effective, least intelligent, least conscientious version of yourself." (Minor Barriers Aren't Minor)
2022.07.20 # "Inexperienced users of statistics tend to take for granted the link between data and scientific issues and, as a result, may jump directly to a technique based on data structure rather than scientific goal… the key to principled statistical analysis is to bring analytic methods into close correspondence with scientific questions." (Ten Simple Rules for Effective Statistical Practice)
2022.07.17 # "Solving the equation Ax=b is faster than finding A-1 [and] you're still better off solving Ax=b than multiplying by A-1, even if the computation of A-1 came for free." (Don't invert that matrix)
2022.06.19 # When selecting subsets with a submodular monotonic objective, "in the worst case the greedy algorithm will be (1-1/e)≈0.63 away from the optimal solution. However, in practice it tends to perform much better than that [because] the algorithm is actually optimal for linear functions, and decays towards the worst-case bounds for nonlinear ones." (Submodular Maximization)
2022.03.23 # "A guess accurate to the nearest order of magnitude, i.e. rounded to the nearest power of 10 [is] bigger or smaller than the true answer by a factor of 3"; for "subestimates which are then multiplied together … the variance (random variability) of subestimates adds up." (Fermi Estimates)
2022.02.17 # "There is a 93.75% chance that the median of a population is between the smallest and largest values in any random sample of five from that population." (Rule of Five)
2022.01.28 # "If you've observed 8 ravens and they've all been black, how certain should you be the next raven you see will also be black? … In general, the probability is (k+1)/(n+2) that the next observation will be positive, given k positive observations out of n total." (Laplace's Rule of Succession)
2022.01.27 # "[Make] performance comparisons based on the distribution of performance results obtained by Monte Carlo sampling of a small area of the space of possible configurations around each benchmark input… To reproduce a result, another researcher need not set up an identical experiment, but only a similar one." (Applications of Randomness in System Performance Measurement)
2022.01.25 # "Uncertainties [uncorrelated, random] add in quadrature… the more certain quantity contributes essentially nothing to the uncertainty of the sum." (A Summary of Error Propagation)
2022.01.24 # "This 'rule of three' states that if none of n patients shows the event about which we are concerned, we can be 95% confident that the chance of this event is at most three in n (ie, 3/n). In other words, the upper 95% confidence limit of a 0/n rate is approximately 3/n." (Zero Numerators)
2022.01.23 # "The code can be copied once, but when the same code is used three times, it should be extracted into a new procedure." (Rule of three)
2022.01.21 # "Early abstractions are often not quite right, and therefore they create a catch-22. You can't create the right abstraction until you fully understand the code, but the existence of the wrong abstraction may prevent you from ever doing so." (99 Bottles of OOP)
2022.01.14 # "We all make latency/throughput tradeoffs every day. We bias these decisions towards throughput (I blame Taylorism). High cost of delay, high chance of learning, and high rate of change all point towards prioritizing latency instead." (Inefficient Efficiency)
2022.01.08 # "Avoiding writing code at all is especially important when we're navigating a new complex idea… The fewer lines of code we write, the better chance we have of changing the feature later into what we discover it actually needs to do." (Your code is a liability)
2022.01.04 # "Almost any slog can be turned into a do-nothing script… It feeds the user a step at a time and waits for them to complete each step manually… It lowers the activation energy for automating tasks, which allows the team to eliminate toil over time." (Do-nothing scripting)
2022.01.01 # "Whenever two [aspects] must compose differently and yet be coordinated, we say that they cross-cut each other. Because [purely OOP/functional] languages provide only one composition mechanism, the programmer must do the co-composition manually." (Aspect-Oriented Programming)
2021.12.10 # "Rows are types, columns are operations. [OOP] makes it easy to extend the table by adding new rows [types with n methods]. A functional language instead encourages you to lump each column's worth of code together into a function [over d types]. The Visitor pattern is really about approximating the functional style within an OOP language." (The Expression Problem)
2021.11.26 # "The crucial but unappreciated methodology driving predictive modeling's success… the Common Task Framework (CTF)." It is "a publicly available training dataset [plus] competitors whose common task is to infer a class prediction rule [plus] a testing dataset." (50 Years of Data Science)
2021.11.24 # "It's common for people to use fixtures and factory libraries in order to reduce the tedium of setting up their data over and over again. This causes the tests to depend (in subtle and unintentional ways) on the details of the fixture data." (In praise of property-based testing)
2021.11.14 # "Group these functional sections, separated by blank lines: 1. Arrange all necessary preconditions and inputs. 2. Act on the object or method under test. 3. Assert that the expected results have occurred." (3A: Arrange Act Assert)
2021.09.06 # "Encapsulation can help hide bugs and makes test harder; inheritance requires extensive retesting of inherited code; and polymorphism and dynamic binding call for new coverage models." (Software Testing Research: Achievements, Challenges, Dreams)
2021.08.21 # "The only way information can be lost is by inputs leading to the same output (collisions)": "if the function is one to one there are no collisions and the Squeeziness [information loss] of the function is 0" and "if there were no possible collisions then fault masking would not be possible." (Squeeziness: An Information Theoretic Measure for Avoiding Fault Masking)
2021.08.05 # "Two programs can compute the same function but may have different testabilities [probability of failure given a fault]… a program with low testability is unlikely to reveal faults through random black-box testing." (Predicting Where Faults Can Hide from Testing)
2021.07.05 # "Glue is quadratic. If you have N features that interact with each other, you have O(N²) pieces of glue to get them to talk to each other." (Glue: the Dark Matter of Software)
2021.05.18 # "The cost of delay is one cost that a successful presumptive feature imposes, but another is the cost of carry. The code for the presumptive feature adds some complexity to the software, this complexity makes it harder to modify and debug that software, thus increasing the cost of other features… A lot of small yagni decisions add up to significant reductions in complexity." (Yagni)
2021.05.15 # "We moved away from 'pile of code' [goto, global-everything] to structured programming, and that additional structure gave us more flexibility, it gave us invariants that allowed local reasoning. But now the higher-level structures have taken those invariants and spread them through your whole codebase." (Maintainability and Refactoring Impact of Higher-Level Design Features)
2021.04.04 # "Expressing constraints, relationships and processing instructions in less powerful languages increases the flexibility with which information can be reused: the less powerful the language, the more you can do with the data stored in that language." (Rule of Least Power)
2021.03.31 # "Much of the logic in [an object-oriented] app exists in the messages, and the messages don't actually happen until you reconstitute it all and put it in memory [or] construct an imaginary mental model and supply the messages yourself in order to understand what's going on." (Rules)
2021.03.15 # Legacy software "is a knowledge base which has accumulated 25 years of various different people's ideas about how to get this or that problem solved. And migrating to a new thing isn't just about building the new thing, it's an archaeology expedition." (Build Systems)
2021.01.19 # "Automation frees us from certain kinds of work [but] obliges us to know more than ever… Reasons for system failure may not be as commonplace as before, but they are less predictable and require both more time and higher levels of expertise to remedy." (The Automation Paradox)
2020.12.28 # "A large system is in a state of partial failure almost continuously; the math is against you… as soon as your program becomes part of a system, these error modes [uncorrelated, distributed] are going to go right through your program." (The Language of the System)
2020.12.17 # "In some systems, a failure in one area can negate great effort in all other areas… fixing the 'zero' often has a much greater effect than does trying to enlarge the other areas" (Multiplying by Zero). Or "avoiding problems can be more important than scoring wins." (Inversion)
2020.11.26 # "When numbers of different magnitudes are [added/subtracted], digits of the smaller-magnitude number are lost… when numbers very close to each other are subtracted, the result's less significant digits consist mostly of rounding errors." (The Floating-Point Guide - Error Propagation)
2020.11.15 # "Production versions of the hypot function … are much more complex than you might imagine." (Hypot – A story of a 'simple' function). "Floating-point math has a reputation for producing results that are unpredictably wrong [but] IEEE floating-point math is designed to, whenever practical, give the best possible answer." (There are Only Four Billion Floats – So Test Them All!)
2020.10.31 # "Timid code is kind of like a poorly told story" – "it's uncertain, it's constantly second-guessing itself, it's filled with digressions and provisos… It's constantly mixing together input handling and business logic and error handling." (Confident Code)
2020.10.25 # In pursuit of coverage, "splitting up functions [destroyed] system architecture and code comprehension along with it": "functions no longer encapsulated algorithms. It was no longer possible to reason about the execution context of a line of code." (Why Most Unit Testing is Waste)
2020.10.24 # "A solid systems's approach should not be based on but it works" (Theo de Raadt Responds) but "contracts enforced by the compiler are usually better than contracts enforced by runtime checks, or worse, documentation-only contracts." (Make Interfaces Hard to Misuse)
2020.10.22 # "Throw exceptions only to indicate exceptional conditions" and "avoid return values that demand exceptional processing. Clients will forget to write the specialcase code, leading to bugs. For example, return zero-length arrays or collections rather than nulls." (Bumper-Sticker API Design)
2020.10.18 # "It's simpler to delete the code inside a function than it is to delete a function" (ibid). Compare with Hyrum's Law: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."
2020.10.17 # "Copy-paste code … to get a handle on how it will be used"; "keep the hard-to-delete parts as far away as possible from the easy-to-delete parts"; "[minimize] responsibilities of library code, even if we have to write boilerplate." (Write code that is easy to delete, not easy to extend)
2020.10.10 # "Don't include a sentence in documentation if its negation is obviously false." (Test of Negation)
2020.10.04 # "Get better at copy editing the hard way: by practicing. Start by acquiring a half-baked piece of writing from someone else and trying to improve it" – "since you won't be attached to it, your editing can be merciless." (You Might as Well Be a Great Copy Editor)
2020.09.13 # Minimize cognitive load: "Naming consistency means both internal naming consistency (don't call 'dim' what is called 'axis' in other places) and consistency with established conventions for the problem domain." (Notes to Myself on Software Engineering)
2020.08.21 # "Complex: state, objects, methods, syntax, inheritance, switch, vars, imperative loops, actors, ORM, conditionals. Simpler: values, functions, namespaces, data, polymorphism, managed refs, set functions, queues, declarative data manipulation, rules, consistency." (Simple != Easy)
2020.08.13 # Performance is underrated – it is both "a feature [that] fundamentally alters how a tool is used" and can "simplify architecture [since] attempts to add performance to a slow system often add complexity." (Reflections on software performance)
2020.08.12 # "Original ideas are rarely born in full generality [and] their communication is not always a simple or straightforward task." E.g. "van Wijngaarden said that goto's were unnecessary [but] Dijkstra stretched the point to say that goto's were inconvenient." (Discoveries of Continuations)
2020.08.11 # "The choice of the name 'computing science' instead of the more common 'computer science' was deliberate in order to indicate that computing rather than computers was to be the foundation of the discipline." (Computing Science at the University of Alberta)
2020.08.09 # Assert configuration: "Configurations are by their nature ephemeral and less well tested. Assertions about configuration invariants can be critical to prevent mistakes." Aim to be able "to present visual side-by-side differences (diffs) of two configurations." (Configuration Debt)
2020.08.08 # "Neither unit tests nor assertions find all bugs, so we should use both." Assert math (e.g. "problems that are inherently much more difficult to solve than to verify"), preconditions, postconditions, invariants, and the spec. (Use of Assertions)
2020.05.25 # "Deliberately change notation in order to 'escape from the formalism' [and] highlight different aspects of a problem or solution." (Insights from Expert Software Design Practice)
2020.05.19 # Externalize infrastructure using layers: "code cannot depend on layers further out from the core [i.e.] the Domain Model is the very center [and] the outer layer is reserved for things that change often. [Since] the application core needs implementation… we need some mechanism for injecting that code" (abstract interfaces, dependency injection). (Onion Architecture)
2020.04.27 # A complicated system — software or otherwise — "not only makes our lives difficult in the present, but it accelerates the loss of knowledge over time… Each individual person knows a smaller percent… it's harder for them to transmit their knowledge onto people in the future… and deep knowledge becomes replaced by trivia." (Preventing the Collapse of Civilization)
2020.03.08 # "Anything that isn't crystal clear to a static analysis tool probably isn't clear to your fellow programmers, either", so "favor indexing over pointer arithmetic, try to keep your call graph inside a single source file, use explicit annotations, etc. " (Static Code Analysis)
2020.01.26 # "An increase in the score produced by a base model should not decrease the score of the ensemble"; "each model should either be an ensemble [or a base model] but not both"; "[calibrate the base models] so that changes [don't] confuse the ensemble." (Keep Ensembles Simple)
2020.01.19 # "It can be tempting to add a new feature to a model that improves accuracy, even when the accuracy gain is very small… Research solutions that provide a tiny accuracy benefit at the cost of massive increases in system complexity are rarely wise practice." (Epsilon Features)
2020.01.11 # Better survival characteristics: "The design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface … Completeness must be sacrificed whenever implementation simplicity is jeopardized." (Worse is Better)
2020.01.04 # "It is especially common in a research setting to evaluate a new idea with partial or primitive implementations of other parts of the system … it can be very difficult to assess whether the benefits the system claims will still manifest once the fat is removed." (Scalability! But at what COST?)
2019.12.31 # Limited to averages: "the average time between earthquakes [is] approximately normal [but] not everything we study is an average"; in fact, "the [raw] time between earthquakes is usually modeled by an exponential distribution." (The Central Limit Theorem and its misuse)
2019.12.28 # "Since tests don't have tests, it should be easy for humans to manually inspect them for correctness, even at the expense of greater code duplication. This means that the DRY principle often isn't a good fit for unit tests." (Tests Too Dry? Make Them Damp!)
2019.12.27 # Two identical functions can still be DRY when "the knowledge they represent is different. [For example] when two functions validate two separate things that just happen to have the same rules. That's a coincidence, not a duplication." (The Evils of Duplication)
2019.12.24 # "Once you have encapsulated some task in automation, anyone can execute the task. Therefore, the time savings apply across anyone who would plausibly use the automation. Decoupling operator from operation is very powerful." (Site Reliability Engineering)
2019.12.23 # Data rollup "summarizes old, high-granularity data into a reduced granularity format for long-term storage" (Elasticsearch Reference). Spike erosion: "the single spike is averaged with an increasing number of 'normal' samples and hence decreases in height." (Statistics for Engineers)
2019.12.07 # Data abstraction "easily leads to inappropriate reuse [and] will often cause un-needed, irrelevant data to be supplied to a function." "The data which does get used (and hence influences the result of a function) is hidden at the function call site." (Out of the Tar Pit)
2019.12.04 # Not so regimented: "Abstract Factory, Builder, and Prototype [all] involve creating a new 'factory object' whose responsibility is to create… The 'factory object' and the prototype are the same object, because the prototype is responsible for returning the product." (Design Patterns)
2019.12.02 # The fourth type of factory (2009) is a simple factory: "move [creation code] into another object that is only going to be concerned with creating." The 2008 factory might be viewed as "defining a simple factory as a static method." (Head-First Design Patterns)
2019.12.01 # The third type of factory with "no direct equivalent in Design Patterns": "where a class seems to require multiple constructors with the same signature, replace the constructors with static factory methods and carefully chosen names." (Creating and Destroying Java Objects)
2019.11.29 # "The syntax for functional languages tends to be verb then noun: f(x), whereas the syntax for object oriented languages tends to be noun then verb: x.f()"; "There's a big difference in usability though: auto-complete … Knowing the type of x narrows down the list." (Verb-noun vs noun-verb)
2019.11.23 # "Objects are state data with attached behavior; Closures are behaviors with attached state data and without the overhead of classes." (Design Patterns in Dynamic Programming)
2019.11.06 # "Exceptions eliminate collocation. You have to look somewhere else to answer a question of whether code is doing the right thing, so you're not able to take advantage of your eye's built-in ability to learn to see wrong code, because there's nothing to see." (Making Wrong Code Look Wrong)
2019.10.27 # "Suboptimally optimizing a sensible objective function is a more viable approach than optimizing a convex objective function that contains obvious flaws." (Dimensionality Reduction)
2019.10.23 # "A 25-dollar term for a 5-cent concept": "use the [variable/function, i.e. dependency] that we were given rather than the one we [created, imported, etc]." (Dependency Injection)
2019.10.20 # "Sometimes you pass data to a routine or class merely so that it can be passed to another routine or class… Use of global variables can eliminate tramp data." (Code Complete/Global Data)
2019.10.08 # "If I look at any small part of it, I can see what is going on … like a fractal, in which every level of detail is as locally coherent and as well thought out as any other" (The Quality Without a Name). "If a method call is not separately understandable, the reader of the code will have to jump to the implementation of the method in order to see what's going on." (Separate Understandability)
2019.10.05 # "Building unit tests is itself an interesting test of orthogonality. What does it take to build and link a unit test? Do you have to drag in a large percentage of the rest of the system just to get a test to compile or link?" (Orthogonality)
2019.10.02 # "Compression" in object-oriented code can hide context: "the primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it." (Reuse Versus Compression)
2019.09.29 # "There is a continuum of value in how pure a function is, and the value step from almost-pure to completely-pure is smaller than that from spaghetti-state to mostly-pure. Moving a function towards purity improves the code." (Functional programming in C++)
2019.09.28 # "The act of writing software is the act of naming, repeated over and over again. It's likely that software engineers create more names than any other profession. Given this, it's curious how little time is spent discussing names in a typical computer science education." (Elements of Clojure)
2019.09.22 # "Implement new ideas in parallel with the old ones, rather than mutating the existing code"; "If the task you are working on can be expressed as a pure function that simply processes input parameters into a return structure, it is easy to switch it out." (Parallel Implementations)
2019.09.21 # Bad physical design: "A few innocent #includes sometimes expand to megabytes of header data once all the recursive inclusion is resolved"; "really easy to screw up, but requires concentrated effort and hard work to fix." Prevent with levelizing, e.g. "header files (.h) cannot include other header files." (Physical Design of the Machinery)
2019.09.18 # "Minimize control flow complexity and 'area under ifs', favoring consistent execution paths and times over 'optimally' avoiding unnecessary work": "[this] usually takes more absolute time, but it reduces the variability in frame times, and eliminates a class of bugs." (Inlined Code)
2019.09.15 # "When dealing with the wrong abstraction, the fastest way forward is back … re-introduce duplication by inlining the abstracted code back into every caller; within each caller, use the parameters being passed to determine the subset of the inlined code that this specific caller executes; delete the bits that aren't needed for this particular caller." (The Wrong Abstraction)
2019.09.11 # "A design principle devised by Bertrand Meyer … every method should either be a command that performs an action (changes state), or a query that returns answer to the caller (without changing the state or causing side-effects), but not both." (Command-Query Separation)
2019.09.09 # One level of indentation per method; don't use the ELSE keyword; wrap all primitives and strings; first class collections; one dot per line; don't abbreviate; keep all entities small; no classes with more than two instance variables; no getters/setters/properties (Object Calisthenics).
2019.09.07 # "Choose your return type based on what you need to continue fluent action … the problems of methods in a fluent interface is that they don't make much sense on their own" (Fluent Interfaces). "Always return self"; "Remove any getter methods [instead] create a command which will apply the data to the thing (East-Oriented Code).
2019.09.05 # "Create the object using a parameter-less constructor and then you set only fields which you want using mutators … [but then] fields cannot be declared final". Consider a Builder: "to make things more convenient, the builder returns itself, so you can chain the method calls (fluent interface)" (Telescoping Constructor Pattern alternatives).
2019.08.31 # "Work with percentiles rather than the mean (arithmetic average) of a set of values. Doing so makes it possible to consider the long tail of data points, which often have significantly different (and more interesting) characteristics than the average." (Site Reliability Engineering)
2019.08.25 # "No clear map or schedule for continuing to learn … while you tackle more immediate challenges; not creating many small katas, exercises, and projects while learning; not seeking one-on-one mentorship" (28 Pitfalls When Learning to Program).
2019.08.24 # Experimenting with notes ("a collection without order").