Month July 2025

Old notes

Aaron M. Cohen Leave a comment

When I was a child I had some cognitive challenges. My parents moved me to a school which used the Slingerland program. As such I got into the habit of taking notes and repeating information I wanted to remember. I still do that today. I am a big fan of using paper & pen. Yet I am now left with piles of old notes.

Since my wife moved in and the arrival of my two children my notes have moved many times. I have gone from a home office to a man cave, then a man corner, and now a cabinet. We are constantly reclaiming our home from times of yore. So what do I do these notes?

The easy answer is to scan it digitally and put it in an online store somewhere. But that just moves my notes from one cabinet that I ignore to another. So I plan to revisit each note and turn it into a blog post. Not only does that refresh the content in my memory but also shares it with others.

Lessons from porting Lucene: Starting over

Aaron M. Cohen Leave a comment

So I took a break from my effort to port Lucene. Late one night I couldn’t figure out how to port logic from Java to Rust. I decided to sleep on it. A few years passed and now I am looking at my code with fresh eyes.

Rather than just pick up where I left off I asked myself what went wrong? Turns out I made a mistake that kills many software projects. I didn’t spend enough time starting the project correctly. The rush to code resulted in spending less time on project setup. I selected a Rust project scaffolding and tried to force a Java project into it. As result one project had to resolve too many problems which resulted in my getting stuck.

Every project needs ADRs

Architecture Decision Records (ADR) allow a team to document why something was done a certain way. Yet more importantly it forces teams to thoroughly explore and agree on decisions. Yes even as a one person team I need to come to the understanding this is the right decision. In this case, I would have discovered that the current project setup was inappropriate. This would have happened while addressing the “Consequences” section of the ADR.

Choosing the right Priorities

I recently read “Decisive” by Chip and Dan Heath. It highlighted the importance of having the right priorities to help resolve conflicts. For instance I wanted the port to have the same features as Lucene. I figured I can reuse Lucene’s unit tests to verify to guarantee that. Well… Lucene is a java library. So I was trying to make Rust behave like Java with JNI in the middle which made life difficult. I was putting a priority on supporting Lucene’s unit tests when it wasn’t always appropriate.

Know the usage

Often when porting code I recall the parable of the blind men and an elephant. I end up spending a good amount of time very focused on a specific part without understanding the big picture. For instance I found myself stuck trying to figure out how to achieve Lucene’s inheritance in a non-object oriented language. I really should have asked how is this part used? If it is used in only one place then inheritance doesn’t matter. I can just combine them.

Why I Prefer Vim Over Other IDEs

Aaron M. Cohen Leave a comment

I try not to enforce Integrated Development Environments (IDE) on my teams. Some developers will give up their religion and home sports team before they drop their preferred IDE. My only ask is the code should build and be understandable outside of their chosen IDE. I often found most IDEs to be more of a hindrance and never to be a one size fits all. As result throughout the day I use multiple IDEs. Anything in Java I will do in Eclipse. I will use Visual Studio Code (vs.code) for tools like watsonx Code Assistant (WCA) in Go, Python, or other scripting languages. I like to use WCA for code comment generation. Yet, for the majority of my coding I use Vim.

Yes that default editor that comes with most Linux, Unix, and Mac distributions. Why… because it is there. My teams need to deliver Software in our SaaS environments and for customers to use on-premises. As I like to work on the front lines I want to use tools that are already there. This is why I don’t use neovim even though it is superior to Vim.

Now I do add plugins to Vim to support color syntax highlighting and autocomplete. So you may be asking why not just use the Vim plugin to vs.code? It is because I need to be used to working in a terminal window. As a developer you should overcome anything hard by doing often. So while I do use a plethora of IDEs, I choose to use the hardest often. That way I can be great at using the terminal editor which is nearly everywhere.