It is difficult to aggregate “collective wisdom from the experts” for programming languages with ever-changing landscapes. Either the advice veers strongly toward “my opinion from that experience 7 years ago” (stale) or generally accepted good practice, often obvious, like “encapsulate everything”. This is a relatively weaker book in the series. The “actionable idea density” is fairly low. About 15 of the items are generic hand waving, a similar number on low level constructs (coroutines, record, new Garbage Collection algorithm etc) and a handful meet the high standard of codifying in a book.
Some ideas, opinions and tips I got from the book -
As apps move to serverless architectures, where the deployment units can be single functions, the benefits we get from application frameworks diminish.
“We have to reinvent the wheel every once in a while, not because we need a lot of wheels; but because we need a lot of inventors”
Ergonomics of older JVMs are fooled when running inside docker containers.
Containers’ key benefit - reduce the coupling between an app and the underlying platform.
JVM ergonomics enables JVM to tune itself by looking at two env metrics - (i) number of CPUs and (ii) available memory.
Behavior is easy, state is hard - offer only a carefully designed API surface for any state mutation. Hardest bugs are caused by inconsistent state.
One of the advantages of being a job hopper is that “I’ve seen the way many different teams work”.
Developer Productivity Engineering - practice and philosophy of improving developer experience through data.
Actor model reduces the consequences of mutable state by preventing sharing, and functional programming makes the state shareable by prohibiting mutation. Functional programs can be less efficient than imperative equivalents and may place a bigger burden on GC. Functions facilitate the use of reactive programming paradigm consisting in asynchronous processing of stream of events.
Countdownlatch is a powerful tool but blocks the current thread. Different concurrency models don’t play well together.
Imperative - code explicitly telling the computer what to do. Declarative - code expressing a goal abstracting over the way in which the goal is achieved.
You aren’t paid to write code. Change your focus from writing code to delivering software. Your job is designing change, not code. Code is a detail. Designing change means feature flags
Localizing the scope of anything that is variable into a supporting method makes the top-level code predictable. Broadly, trying to lock down anything that does not vary makes you think more carefully about design and flushes out potential bugs.
Embrace SQL thinking - the biggest failing of applied OO programming is the belief that you should faithfully reproduce your domain model in code. It leads to unnecessary classes. SQL is declarative and is a data DSL.
In the early 2000s, most Java developers were actually full-stack developers - they just did not know because the phrase had not yet been coined!
Heap access is geologically slow compared to instruction processing, so modern computers use caches.
Java profilers use either byte code instrumentation or sampling. Flame graph sorts and aggregates the traces up to each stack level.
Uncertainty is when we cannot quantify the risk.
Risk = (Likelihood of Failure X Worst-case impact of Failure)
Playing the lottery is low-risk, Free solo climbing is high risk.
Large, infrequent releases are riskier. There is no way to reduce the impact of a failure - the worst case is still the ENTIRE system down and incur severe data loss, but we lower the likelihood of failure with smaller releases.
Naming is important - Orwell said - “the worst thing one can do with words is surrender to them”.
Technical classes (e.g., Hashmap) rarely have a place in the vocabulary of the domains we’re working in. The need for utility classes should be a red flag that you’re missing an abstraction.
Try to crash your JVM to learn deep stuff - e.g., try using Unsafe to get access to low-level stuff (e.g., memory management)
Cost of going to RAM, relative to registers, kept growing.Thus, cache-friendly code is a much researched area.
Fun can have different faces - Exploration (focused investigation); Play (no goal, for its own sake); Puzzles (rules with a goal); Games (rules with a winner) and Work (satisfying goal).
Kintsugi is a Japanese art where a precious broken object - rather than thrown away - is put back together using gold powder along its cracking lines. We should similarly learn how to fix legacy code that should make us similarly proud.
Package-by-layer structure (e.g., tld.domain.project.controllers, ..model, ..service etc) for your classes requires a lot of methods to be public. In order to benefit from package-private access protection, package-by-feature package hierarchy is a better organizing principle (e.g., tld.domain.project.company, ..user etc). The latter reduces coupling.
Service hedging - multiple idempotent calls to identically configured service instances on discrete nodes are launched and all but the fastest response discarded.
Boolean literals are worse than hard coded numbers - a 42 in code might look familiar, but a “false” could be anything and anything could be false.
Classes that represent Value objects don’t need getters or setters. Why Java 14 introduced a record structure.
Marginality : what is the average diminishing marginal return of adding developers to a team?
Programmers writing automated tests suffer from positive test bias. Fuzz testing is an unreasonably effective technique for negative testing that is easy to include in automated test suites.
Comment only what the code cannot say. Code says “what”, comments should say “why”.
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet or computer – no Kindle device required. Learn more
Read instantly on your browser with Kindle for Web.
Using your mobile phone camera, scan the code below and download the Kindle app.
Flip to back Flip to front
Follow the Authors
Something went wrong. Please try your request again later.
Frequently bought together
Customers who bought this item also bought
Page 1 of 1 Start overPage 1 of 1
Top reviews from other countries
Nilendu Misra
Relatively weaker book in the "97 Things" Series
Reviewed in the United States 🇺🇸 on August 20, 2020Verified Purchase
Amazon Customer
Great Book for Junior Dev Book Club
Reviewed in the United States 🇺🇸 on June 5, 2023Verified Purchase
PATRICK SWEENEY
Met expectations - diverse stories on Java for the people who love Java
Reviewed in the United States 🇺🇸 on November 21, 2020Verified Purchase
Sherman P. Winkledink
I KNOW JAVA
Reviewed in the United States 🇺🇸 on September 15, 2021Verified Purchase
Piotr Dzioba
Like collection of the blog posts
Reviewed in the United States 🇺🇸 on September 4, 2022Verified Purchase
