Kartones Blog

Be the change you want to see in this world

Book Review: 97 Things Every Java Programmer Should Know


97 Things Every Java Programmer Should Know book cover

Title: 97 Things Every Java Programmer Should Know

Author(s): Kevlin Henney, Trisha Gee & others

Creating a very direct association with an existing book or line of books is a good marketing technique, but doesn't guarantees quality. This book does it, and kind of exemplifies why I sometimes prefer quality over quantity.

The book follows the same 97 Things Every Programmer Should Know pattern: 97 tips, each 2-3 pages long, from very varied topics, not only focused on Java itself. A sample of the topics included are language features, testing, documentation, pragmatism, JVM tuning & optimizations, architecture, tools, teamwork, CI, concurrency and parallelism, debugging, interop, Kotlin and Groovy...

Some of the content is overly generic... and in those cases, often not even Java specific, which is not bad on itself, but I wanted Java tips, I already read the "generic programmer" version book. And when I say "some" I mean as a rough estimate half of the tips. Also a few tips are so similar they feel repeated. And my final complaint is that some topics that appear to be really interesting (like the actor model, concurrency or Groovy) are so briefly touched that feel a mere mention more than a tip.

That said, the actual Java tips are good, at least to somebody like me with not much experience with the language. I took quite a few notes and got topics to now study in depth, so the main goal of of waking up my curiosity was achieved. But I would have preferred a "50 tips" version, all of them focused on the language.

Course Review: Java Memory Management (LinkedIn Learning)

I had read that LinkedIn Learning was an acquisition and rebranding of the famous Lynda.com platform, but hadn't given it a try (nor have I taken any Lynda course in the past). But yesterday I saw that I had "free access" to some courses, and one of them looked interesting. Being an opportunity to a) see how the learning platform works and b) actually learn or at least refresh some Java concepts, I gave it a go.

On with the small review:

Java Memory Management It's a 3h course, roughly half of it code examples and exercise walkthroughs. We'll learn how Java keeps variables in memory, from basic stack-heap concepts to the final keyword or String specifics, basic JVM optimizations we can apply and, most important, an introduction to finding and debugging memory leaks and memory usage potential problems. I liked the introduction to a few tools, attaching to running applications and checking how memory grows (or keeps steady on well behaving programs) but also how to grab and afterwards load heap dumps.

Explanations are clear, diagrams simple and abundant, code examples to the point and easy to follow, and in general my only complaint is that the course is old, as mentions Java 8 being "recently released", which in 2021 is not the case anymore 🤓 Still, worth watching.


  • primitives and object references go to the stack, objects to the heap
  • one stack per thread
  • one heap per application (shared between stack)
  • object references are passed by value when passing objects as method parameters
  • final does not apply const correctness
  • Easy to have escaping references, so return immutable objects (e.g. unmodifiableMap or ImmutableMap) and build readonly versions of objects
  • JVMs optimize and create objects in the stack if detects they are local scoped only
  • Java does string interning, that's why it's important to use .equals() instead of == when comparing them
  • PermGen heap existed until JDK7, Since JDK8 is MetaSpace
  • Java VisualVM tool and the Visual GC plugin for memory analysis
  • Memory Analyzer (MAT) (from eclipse.org) tool for heap dumps

Book Review: Rocket Jump


Rocket Jump book cover

Title: Rocket Jump: Quake and the Golden Age of First-Person Shooters

Author(s): David L. Craddock

I read Masters of Doom in 2010 but the book was written in 2004. Still, it stopped its tale after the first Quake, and we could say that it is a mostly positive story. Rocket Jump spends a brief time talking about Wolfenstein 3D, more about Doom I and II, but the majority of time goes from 1995 onwards, through the Quake series but also including Doom 3 and mentioning most modern entries (like Rage, Doom 2016 and Quake 4), up until 2018. As such, it is a great complement to get a broader picture of id Software, and of course their games and the id Tech engine evolution.

Some of the content is narrated, but mostly consists of interviews, with author notes and remarks where deemed fit. While the chapters are in chronological order, during the interviews content goes back and forth a lot, so for example we'll learn a dozen times how hyped id were about the NiN band, or we'll read a triple interview about (theoretically) one topic switching interviewee each sentence, even if they are not talking about that topic, making it weird to read, at least to me. But despite the occasional offtopic drifts all of the interviews add value.

At first I thought I was going to read mostly generic and high-level technical details of the Quake games, but I'm happy to inform that some interviews go into specifics and narrow but great detail. Quake not only brought one of the first true 3D engines, but also spawned a new era of modding, so we learn about QuakeC, mapping, the creation of quake movies (so called machinima, using the game engine), and a few highlights of memorable and amazing mods, like Quake Rally, CTF, Team Fortress and the first Quake bots.

The second half of the book (approximately) contains interviews with people from closely related companies to either Quake or in general First Person Shooters: 3D Realms, Valve (the folks behind Team Fortress mods and games), Rare (because of Goldeneye), LucasArts (creators of Dark Forces), a member of Nine-Inch Nails band (Quake's soundtrack and many effects were done by them)...

I used to think about id Software as a hard working but cool videogame studio. After reading the book, I am still glad they made the games the built, even if they have been repeating the same genre for more than 25 years, but I now know that the company culture degraded while building Quake, and never recovered, slowly getting worse and worse until almost nobody from the original team remains anymore. The book summarizes at the end: "Id Software has rocket-jumped time and again over more than 20 years. [...]. Every single time, they paid a price.". A fitting sentence for a company where backstabbings and unexpected employee firings were way too common.

A great reading, especially if you lived through that era of the FPS shooters and adventures.

Book Review: 97 Things Every Programmer Should Know


97 Things Every Programmer Should Know book cover

Title: 97 Things Every Programmer Should Know

Author(s): Kevlin Henney & others

As you might guess, this book contains 97 tips and advices for programmers (nowadays "developers"). Each tip is 1.5 to 2 pages long, and the topics are very varied: From design patterns and good coding practices to testing, refactoring, debugging, Continuous Integration, compilation/build & deployment... but also other areas like estimations or collaboration (code reviews, pair programming, etcetera).

It's from 2010 so starting to feel outdated at some places, but in general the advices are still relevant as of today (mostly why I kept reading it until the end).

Can be read quickly, and doesn't contains much code. Also, with brief texts comes brief descriptions, so if something interests you, probably you will have to dig deeper on your own.

Not bad, not a revelation, still a good reminder of (mostly) good practices.


Miscellaneous, unsorted notes (far from all of the book contents, though)

  • leveraging technical debt
  • Referential Transparency
  • Understand your users (false consensus effect)
  • Many incremental changes instead of a huge one
  • Check and add tests
  • New tech is not enough on itself to justify a refactor
  • Sharing code (components, libraries) creates dependencies, take that into account
  • Boy Scout Rule (leave the code better than you found it)
  • Concentrate on building business-domain code as much as possible (today evolved to "build vs buy")
  • Simplicity wins
  • Explicit domain concepts
  • Good encapsulation. It's all about narrow interfaces
  • Code layout: easy to scan, standardized, expressive, compact
  • Do code reviews
  • Reason about: Preconditions and postconditions for functions, invariant for loops, immutable objects whenever relevant
  • Nested sections -> Nested functions
  • Short, single task focused functions, with few parameters
  • Code comments: only relevant ones. "Comments as code": Either they add value (complement code) or are waste to remove/rewrite
  • APIs:
    • Difficult to get right the first time, more difficult to change later
    • Good abstraction
    • Symmetry and consistency
    • Expressive
    • Convenient for the caller
    • Write unit tests for code that uses the API -> surfaces hurdles
  • Don't ignore/silence errors, fix them
  • Learn a language, but also understand its culture
  • Interfaces exist for the convenience of their users, not their implementers
  • Domain-specific types over primitive types (e.g. VelocityInKnots)
  • Prevent errors by helping/aiding the user. Massage input, offer hints, cues, defaults...
  • Write code as if you had to support it for the rest of your life
  • Write tests for the people trying to understand your code

Book Review: The New Corporation


The New Corporation book cover

Title: The New Corporation

Author(s): Joel Bakan

When I watched The Corporation it blew up my mind, mostly because I vaguely knew what a corporation was (I thought it was "just a big company"). I totally recommend the documentary, and I won't be going into details of what corporations are. Just watch it.

What this new book (and related documentary that I have not seen) does is building upon the first one, looking back to what has happened in the last 15 years since the original publication. It explains how corporations have changed, not on their underlying pillar (seeking profit), but in the public message and image they showcase, now being in theory agents of change. We learn how they are "doing well by doing good", making money by being good actors, not being good actors because its the right thing to do. Get explanations of their "social and environmental values", given that many times their solutions are not even solving the problem or solving a problem they themselves caused before. And of course, avoiding as much as possible the most equitable solution: paying taxes.

Other big topic covered is how they are slowly taking control of public services through privatization, proclaiming that governments are no longer needed, instead "good corporations" being the solution. Also enumerates quite a few scandals and notable accidents from big corporations.

I don't want this to be a big review, so a more detailed, almost chapter by chapter summary and quite a few "evil corporation examples" can be read at CounterPunch.

The book tries to not be all grim and pessimistic, the last chapter being focused on sources of change for good and ways to "fight back" privatization and abuse of power. Although feels small compared with the remainder offering such a negative view of the world, but at least is something.

It's an interesting book and an easy read. You might not agree on everything it says, and I also think that a few specific topics take too long (too many examples given), but still good overall and recommended.

Previous entries