Coder Legion - Recent posts tagged improvement

Why Is 'Thinking' Being Attached to Everything?

Thu, 17 Sep 2026 11:16:18 +0000

I Noticed That Every Profession Now Has a "Thinking." I Went Looking for Why.

It started as a low-grade irritation.

Systems thinking on a job listing. Design thinking in a workshop invitation. Product thinking in a strategy meeting. Computational thinking on a university course banner. These terms kept appearing, and each time they did, I felt a small, specific unease. The kind you get when you suspect everyone else in the room understands something you do not.

Eventually I stopped treating that unease as a sign of my own ignorance and started treating it as a question worth answering. Why is "thinking" being attached to everything? What does it actually mean when you pair it with another word? And what do all these terms have in common, underneath the branding?

I went looking for answers. What I found surprised me.

Before the pairing makes sense, the word "thinking" itself needs to. And it turns out thinking is not one thing. It is a whole family of mental activities, from recalling a memory to constructing an argument to making a split-second call. The most useful insight I came across was a distinction that psychologist Daniel Kahneman made famous: our brains operate in two distinct modes.

System 1 is fast, automatic, and effortless. It reads the emotion on a face before you consciously decide to look. It finishes the sentence before you hear the end of it. For most of our waking hours, this is what is running the show.

System 2 is slow, deliberate, and genuinely hard. It is what you use to follow a complex argument, to notice that your first reaction might be wrong, to work through something you have never encountered before. The brain avoids it when it can, not out of laziness, exactly, but out of efficiency. System 2 is metabolically expensive. The brain would rather not.

I filed that away, not yet sure what to do with it. It came back to me later, in a different form.

When you place a modifier in front of "thinking," something interesting happens on both sides of the pairing.

The modifier shapes the thinking. Left alone, thinking is unfocused. It wanders, it confirms what you already believe, it reaches for the nearest comfortable conclusion. Adding a modifier gives it a track to run on. The word "critical" in critical thinking does not simply describe a topic; it issues an instruction to the brain. Look for flaws. Question assumptions. Do not accept the first answer that arrives. Without that word, you might still be thinking, but your brain is probably just agreeing with itself.

And thinking reshapes the modifier. This is the less obvious half of the relationship. Take the word "design." On its own, it is a noun — an artifact, a layout, an outcome. Add "thinking" and the entire emphasis shifts. You are no longer focused on the thing being made. You are focused on the cognitive process of making it: the empathy, the iteration, the willingness to be wrong and start again. A noun becomes a methodology.

This is the pattern underneath all of these terms. When you see "X thinking," you are not being pointed toward a subject. You are being handed a cognitive lens. A structured way of seeing and moving through a particular class of problem.

Three examples make this concrete, and they work best when set against each other.

Critical thinking instructs the brain to be suspicious. If a headline claims that coffee drinkers live longer, the instinct is to believe or dismiss it based on how it feels. Critical thinking intercepts that instinct and routes you somewhere harder: Who funded the study? How large was the sample? Is correlation being reported as causation? What do other studies say? The goal is not skepticism for its own sake. It is the suspension of judgment until you have actually earned a position.

Design thinking starts somewhere different, with a person rather than a problem. A bank that wants to improve its mobile app might survey customers and build what they ask for. A team practicing design thinking observes customers using the app in real conditions, notices that what users are actually experiencing is anxiety, not knowing whether a transaction went through — and prototypes a small confirmation animation before writing a single line of production code. The solution that emerges is not the one anyone would have asked for on a survey. That is the point.

Systems thinking instructs you to look at how parts affect each other rather than the parts in isolation. A hospital hires more doctors to reduce wait times. Wait times increase. More doctors means more patients seen, which means more follow-up appointments, which means the scheduling system clogs further downstream. A systems thinker would have mapped that feedback loop before the hiring decision. The intervention was obvious; the consequences were not, until you looked at the whole.

These three frameworks feel different from each other and they are. But they share something underneath. Each one is a deliberate System 2 override. Each was built to intercept the comfortable, energy-efficient shortcuts that System 1 wants to take and route the brain into the slow, uncomfortable processing the problem actually requires. All of these frameworks, at their core, are structured workarounds for the brain's preference for the easy answer.

Why is this pattern everywhere right now? Three things, I think.

The most durable reason is that specific knowledge goes stale but mental models do not. Teaching someone the steps for a particular tool has a shelf life. Teaching them design thinking , a repeatable approach to any human-centered problem like travels across roles, industries, and decades. Organizations are increasingly reaching for that durability.

The second reason is that these terms dissolve gatekeeping. "Design" used to belong to designers. "Data" used to belong to analysts. Re-framing them as types of thinking signals that anyone (engineers, marketers, executives) can and should adopt that perspective. Whether that is always earned in practice is a separate debate. The intent is democratizing.

And then there is the honest third reason: this is a good brand. "Design thinking" sounds like a fundamental upgrade to how your mind works. "Design workflow" sounds like a checklist. Packaging methodology as cognition makes it easier to sell as workshops, certifications, consulting engagements. The frameworks are often genuinely valuable. But their proliferation is not purely intellectual. The brand is doing real work, and it would be naive to pretend otherwise.

Now when I encounter a new "X thinking" term I have never heard, I reach for five questions.

What domain does this framework operate in? What specific failure mode was it invented to fix ? What does it exist to prevent? What does it tell you to pay attention to that your default thinking ignores? What does it tell you to resist or question? And what are the actual practices , not the concept, but the things you would do differently on a Tuesday morning?

The answers will not come from knowing what "thinking" means. That word tells you a structured method exists. It does not tell you what the method is. For that, you have to go learn the specific framework , its history, its steps, its blind spots. But at least now you know exactly what you are looking for.

When I see those job listings and workshop banners now, I do not feel the old unease. I feel something closer to recognition. Each term marks a place where someone looked at a class of problem, noticed that human beings approach it badly by default, and spent real effort designing a path through. That is not jargon. That is worth learning.

Improving my previous OpenRewrite recipe

Thu, 19 Jun 2025 09:26:47 +0000

I started discovering OpenRewrite last week by writing a Kotlin recipe that moves Kotlin files according to the official directory structure recommendation. I mentioned some future works, and here they are. In this post, I want to describe how to compute the root package instead of letting the user set it.

Reminder

I developed last week a recipe to follow the Kotlin recommendation regarding directory structure:

>In pure Kotlin projects, the recommended directory structure follows the package structure with the common root package omitted. For example, if all the code in the project is in the org.example.kotlin package and its subpackages, files with the org.example.kotlin package should be placed directly under the source root, and files in org.example.kotlin.network.socket should be in the network/socket subdirectory of the source root.

>-- Directory structure

In a Java project, if you have packages ch.frankel.foo, ch.frankel.bar, and ch.frankel.baz, you'll get the following structure:

src
 |__ main
    |__ java
       |__ ch
          |__ frankel
             |__ foo
             |__ bar
             |__ baz

In Kotlin projects, many developers follow the same structure as above, but it can be flattened as:

src
 |__ main
    |__ kotlin
       |__ foo
       |__ bar
       |__ baz

The work

My recipe's original version mandated that you configure the root package yourself, e.g., ch.frankel for the above example. However, it should be possible to compute it automatically, from looking at the source files. It adds an extra step to the process: before moving the file to the root, the recipe should look at each source file, get the package, compute the longest prefix with the existing root, make it the root, and go to the next source file. The regular Recipe doesn't work in this case. We need to switch to a ScanningRecipe:

>If a recipe needs to generate new source files or needs to see all source files before making changes, it must be a ScanningRecipe. A ScanningRecipe extends the normal Recipe and adds two key objects: an accumulator and a scanner. The accumulator object is a custom data structure defined by the recipe itself to store any information the recipe needs to function. The scanner object is a visitor which populates the accumulator with data.

>-- Scanning recipes

Scanning recipes offer two steps: the first to gather data, the second to do the work.

We must design our algorithm within the constraints of OpenRewrite, and they are the following: in the first phase, for each source file, OpenRewrite will call the getScanner() method that returns a visitor of our choice. In turn, OpenRewrite calls the visitor's methods, which can access the accumulator.

My first naive approach was to use a collection as the accumulator, but it's not necessary. The algorithm is much simpler if we set a mutable placeholder that holds the package root and update it if necessary during each visit. The initial value should be null.

If the value is null, which happens on the first visitor, set the package root to the source file's package.
If the value is an empty string, skip–see below.
In any other case, compute the new package root by finding the longest prefix between the existing package root and the source file's package.

It might result in an empty string, indicating that packages have no common root, e.g., ch.frankel.foo and org.frankel.foo.

Here's the updated code:

class FlattenStructure(private val rootPackage: String?) : ScanningRecipe<AtomicReference<String?>>() { //1-2

  constructor() : this(null)                                                   //3

  override fun getDisplayName(): String = "Flatten Kotlin package directory structure"
  override fun getDescription(): String =
    "Move Kotlin files to match idiomatic layout by omitting the root package according to the official recommendation."

  override fun getInitialValue(ctx: ExecutionContext) = AtomicReference<String?>(null) //4

  override fun getScanner(acc: AtomicReference<String?>): TreeVisitor<*, ExecutionContext> {
    if (rootPackage != null) return TreeVisitor.noop<Tree, ExecutionContext>() //5
    return object : KotlinIsoVisitor<ExecutionContext>() {
      override fun visitCompilationUnit(cu: K.CompilationUnit, ctx: ExecutionContext): K.CompilationUnit {
        val packageName = cu.packageDeclaration?.packageName ?: return cu
        val computedPackage = acc.get()
        when (computedPackage) {
          null -> acc.set(packageName)                                         //6
          "" -> {}                                                             //7
          else -> {
            val commonPrefix = packageName.commonPrefixWith(computedPackage).removeSuffix(".") //8
            acc.set(commonPrefix)
          }
        }
        return cu
      }
    }
  }

  override fun getVisitor(acc: AtomicReference<String?>): TreeVisitor<*, ExecutionContext> {
    return object : KotlinIsoVisitor<ExecutionContext>() {
      override fun visitCompilationUnit(cu: K.CompilationUnit, ctx: ExecutionContext): K.CompilationUnit {
        val packageName = cu.packageDeclaration?.packageName ?: return cu
        val packageToSet: String? = rootPackage ?: acc.get()                   //9
        if (packageToSet == null || packageToSet.isEmpty()) return cu
        val relativePath = packageName.removePrefix(packageToSet).removePrefix(".")
          .replace('.', '/')
        val filename = cu.sourcePath.fileName.toString()
        val newPath: Path = Paths.get("src/main/kotlin")
          .resolve(relativePath)
          .resolve(filename)
        return cu.withSourcePath(newPath)
      }
    }
  }
}

Inherit from ScanningRecipe instead of directly from Recipe
Set the accumulator type to be an AtomicReference<String?>
Make the configuration easier when you don't override the package root
The initial root is uninitialized
Skip the computation if the root package is manually set
If it's the first file visited, the accumulator holds null, and we can set the (temporary) root as the current package
One of the previous computations returned no common root–do nothing
Find the longest common prefix between the held package root and the current package
The only difference with the original code:
we check if the root package has been set manually otherwise, we use the one computed in the first pass

Optimizing the recipe

You may have noticed that when there is no common root, e.g., ch.frankel.foo and org.frankel.foo, we scan all files anyway. In a small codebase, it's not a big issue, but when scanning millions of source files, that's a huge waste of CPU cycles and time. If you run the recipe in the Cloud, it directly translates to money. We should stop scanning as soon as we detect the computed package root is an empty string to optimize the recipe.

Here's the updated code:

override fun getScanner(acc: AtomicReference<String?>): TreeVisitor<*, ExecutionContext> {
  if (rootPackage != null) return TreeVisitor.noop<Tree, ExecutionContext>()   //1
  val currentPackage = acc.get()
  if (currentPackage == "") return TreeVisitor.noop<Tree, ExecutionContext>()  //2
  return object : KotlinIsoVisitor<ExecutionContext>() {
    override fun visitCompilationUnit(cu: K.CompilationUnit, ctx: ExecutionContext): K.CompilationUnit {
      val packageName = cu.packageDeclaration?.packageName ?: return cu
      // Different call than the one above!
      val currentPackage = acc.get()
      // First scanned file
      if (currentPackage == null) acc.set(packageName)                         //3
      else {
        // Find the longest common prefix between the stored package and the current one
        val commonPrefix = packageName.commonPrefixWith(currentPackage).removeSuffix(".")
        acc.set(commonPrefix)
      }
      return cu
    }
  }
}

If the root package has been set, skip visiting
If one of the previous computations sets an empty string, there isn't any common root package: skip visiting
Simplify the visitor by removing the clause when the accumulator is an empty string since it can't happen anymore

Note that OpenRewrite still scans each file, but at least doesn't visit it thanks to the no-op visitor.

Counting visits

I made a couple of attempts before finding the right approach to the above. To ensure that I got it right, I wanted to display the number of visits by the scanner. We can use the accumulator to increment the visit count. Here are the changes I made:

Migrated from an AtomicReference<String?> to an AtomicReference<Pair<Int, String?>>
The getInitialValue() function returns AtomicReference<Pair<Int, String?>>(0 to null)
During each visit:
- Get the visits count from the accumulator
- Increment it
- Print it
- Store it back in the accumulator
Update the tests accordingly

With packages ch.frankel.blog.foo, org.frankel.blog.bar, and org.frankel.blog.baz, the log shows:

[INFO] [stdout] FlattenStructure: 1 file visited
[INFO] [stdout] FlattenStructure: 2 files visited

By changing ch.frankel.blog.foo to org.frankel.blog.foo, the log changes to:

[INFO] [stdout] FlattenStructure: 1 files visited
[INFO] [stdout] FlattenStructure: 2 files visited
[INFO] [stdout] FlattenStructure: 3 files visited

Because I made these changes just to validate my understanding of how OpenRewrite works, I put them in the visits_count branch on GitHub. To see the differences, execute git diff master visits_count.

Conclusion

In this post, I added the automatic computation of the root package. I had to change my design and understand how scanning recipes work. Then, I skipped further visits when there wasn't any common root package to optimize performance.

The recipe is still not serializable, though it's a recommendation. I also noticed that my tests didn't leverage OpenRewrite's testing API. There's still a lot of work to do!

The complete source code for this post can be found on GitHub.

To go further:

Originally published at A Java Geek on June 15^th, 2025