I’m a big fan of CLI tools. There’s something about a terminal (emulator) that feels so damn special. I still remember the excitement I felt when I edited ~/.bashrc for the first time to create a command alias or modify the PATH. The simple commands I entered had an immediate effect and it felt like magic.

With time, I learnt how to manage my bash dotfiles, how to update system packages, where to configure newly installed open-source tools. It made me learn about my environment and where to look if I get an error. I learnt the importance of automatization in the development process (aka building your own development workflow!) and the importance of maintanance. After I nuked my root with the cursed rm -rf / command on WSL2 by failing to perform auto-complete and entering it way too late to remedy the situation but well in time to realize I’m in a pickle, I had to go through restoring my entire environment. And this is when I decided to take a more organized approach to managing my dotfiles. Today I use the home-manager to declaratively define my environment, Oh My Zsh instead of bash, kitty as a terminal emulator and of course neovim (my love, always) as a code editor.

On Java LSP support and editor¹

A note on IDE. I use neovim btw but that was until God blessed me with Java. Is what you probably expect me to say. And indeed setting up a Java LSP for neovim turned out as difficult as they say. I abondoned my beloved code editor and asked daddy aka my employer for a premium license for IntelliJ. I spent a bit of time rewriting some of the most basic functionality from neovim config in Lua to Vim script to still benefit from Vim motions in the IntelliJ IDE. I have to admit the IDE made many things easier but after a while I still turned back to neovim. Buckled up and divided into the LSP setup once again. I ended up with java-language-server (as opposed to the more popular jdtls but it gave me the most basic things I needed: code diagnostics and quick remedy strategies (hashtag lsp_code_actions), signature help, autocomplete suggestions, etc. Although granted, there’re still many things I’m unhappy about (e.g. symbol signature and third-party code, more stable cross-project referencing) but this is most likely due to a skill issue.

On input validation and error handling¹

• Always validate your inputs. And by that I mean ALWAYS. This will spare you hours of running simulations only to find out that something went wrong and changed the behaviour of the entire system

• Confirm your expectation of the system behaviour. Especially in a non-deterministic aka asynchronous context. ESPECIALLY in a distributed setting with a high data transmission ratio. There’s no humanly possible way to prune gigabytes of log files to verify your assumptions.

On abstraction and ugly code¹

• DO NOT ABSTRACT UNLESS ABSOLUTELY NECESSARY! Yep, I said it. Abstractions are beautiful in theory and Java makes it so tempting to start with an abstraction and work your way down to specifics. Fight the urge to abstract early, you’ll thank me later.

• This goes in hand with the above but I’ll make a separate point out of it. Do not try to be a smart-ass. Clean code, modularisation - out of the window. This is unimportant in the POC stage. Hack it out as fast as possible to get a working solution. I’d go even further than that. Make it your goal to make it as ugly as possible. Avoid early optimisation and getting stuck on splitting your code into functions 4 lines of code each (I’m sorry, Uncle Bob). Raw dawg 50 line-functions all the way, embrace code duplication. Embrace chaos. Only when it starts getting really uncomfortable for you (and by that I don’t mean your perfectionism), only then do some refactoring. Don’t let some abstract principle guide your hand. Make it dirty and functional because you learn so SO many things about the process.

The power of positive mindset (even if it’s java).¹

Curiosity and a positive mindset go a long way. They will give you a good head start on the most challenging part of solving a difficult problem with a language you hate slightly dislike. Keeping an open mind helped me push through the initial learning curve (especially the part with functional Java) and shape my thinking to focus on the things that I do find enjoyable. For example, I hadn’t dealt so much with threads before and the standard Java library provides extensive functionality to make threads realively comfortable. Suddenly, the bloated world of alien Java modifiers (like volitile and synchronised) starts slowly to make sense. After building a a few simple TCP servers you feel slightly more confident and optimistic.