I have had the opportunity to write bad code and read good code in the last couple of years. I don’t think code reviews must be done through the lens of objective goals. Code reviews are prone to varied range of subjectiveness and people shouldn’t be too religious of it without good reasons. The most important constituent of a good code review is common sense which is formed through experience (ex: people appreciate the value of logs truly only after they’ve experienced a terrible incident). So the below list is based off of my experiences in the Java Ecosystem. ...

List of good software that I use on a daily basis IntelliJ Idea MongoDB PostgreSQL Gitlab Postman Excalidraw Teams (it’s a considerable leap foward compared to Skype) VScode Confluence LogSeq Windows Terminal (very sleek UI) Super Putty Outlook Zoom (commendable audio quality over Meet) Matter (read-it-later app)

This list maily comprises of the libraries and frameworks I use frequently Guice (hard to grok initially, but it is worth) Dropwizard (was a pioneer in the Java ecosystem and I still admire the constructs it invented) Spring and Spring-Boot (love the convenience) Redis Guava (very utilitarian) Kafka (suitable for enterprise but would not be my first preference) Maven (simplest dependency management tool, I wish something like it existed in Python Ecosystem) FailSafe and OkHttp Morphia (half decent when compared to its counterparts) Webpack and TS.

Lately, I have realized that Interfaces matter more than their Implementations. Key distinctions in Interfaces can give you a competitive edge like no other. Yet people get lost in the Implementation details. The Interface is the design and design requires effort. The Interface is the gateway to whatever-the-thing you’re building and I feel like not enough work is being put into shaping that gateway. Jumping over the gun and discussing the details is fine, but they should be driven by Interfaces. Finally, the Interface is the agenda that acts as a direction.

There are some instances where I try to solve a problem that has already been solved. Though this approach allows you to learn more about the core problem, it doesn’t necessarily help you to do the job. Earlier I used to believe it was the right way to tackle problems that was akin to solving a Differential Equation with just the knowledge of basic mathematics without the calculus part. There has to be Some Other Way, right? ...

For the vast majority of the art that gets produced, there is little value for it when it enters a different phase of time. Though fewer in number, there are artists that capture the core constructs of human civilization and produce art around it. Books that reveal the atomic constructs of the way things are built, never go out of fashion. In the lieu of this realisation, I started reading books that are not publicised in the current news hype cycle. Keeping my news information diet to a minimum along with reading classics from the past has ensured my sanity prevails. Step-function breakthroughs are only possible when the units in the time dimension get zoomed out. But only upon careful inspection, you will get to know that the mosaic was actually formed by arranging smaller pieces together. ...

I used to be the guy who got hyped for every new database that got released in HackerNews and I assumed that every new release was tied with a significant improvement in the underlying tech. That assumption turned out to be wrong. Sure there were some improvements, but most of them were non-significant. Even though I use databases a lot daily, I couldn’t build one up from scratch till I read Martin Klepmann’s Designing Data-Intensive Applications(DDIA). Reading DDIA was being in a Database-Anatomy class, where Martin ripped apart a database and explained its fundamental parts. As a result of it, I can smell bullshit from a mile away if someone wants to overengineer their application by using something they don’t need, the power which I didn’t possess earlier. This was possible only because Martin gives you the right set of tools and frameworks which help you see right through the marketing crap and evaluate a database’s core offering. In short, you have a non-trivial type of information which facilitated you to evaluate a database objectively. ...

The medium by which you get modelled (the brain’s perception of different things) changes with every passing generation. Earlier it was an essay now it is a blog. At their core, Words have the same power as they had at the beginning of human civilisation. And technology updates the representational medium of those Words now and then. Your core opinions are formed through the transfusion of other people’s Words with your thoughts and experiences. And due to this fact, Twitter has a good chance of shaping your opinions than either Instagram or Linkedin. Governments and Politicians use Twitter to exploit its superpower to various degrees. ...

Repetition is a very peculiar term in the English language, as its contextual dependence is damn high. For me, my mind always repelled at the idea of Repetition of anything. But lately, I have been appreciating Repetition a lot, especially Iterative Repetition. People think Repetition is boring and is a dead end when it interferes with your career. And I agree with the latter, you can’t just assume that you’ll climb up the career ladder with repeating things day in and day out. But Iterative Repetition is a game changing way to model your career. ...

Should have been more aggressive in the start while I was being onboarded to my first job. Took more than a month to get the whole picture of the internal tooling and abstractions. Should have found out someone who was willing to help me understand the internals of the company. Was not comfortable asking people for help as I was afraid of getting no from them. But it turns out to be a bad assumption to make in the first place. People are willing to help, you just need to find out a good time. Should have set out personal 1-1’s with all my teammates in the beginning itself. Should have been more proactive with the follow-ups w.r.t to an Issue or an MR. Context is everything. There were some instances where the effort I put in without realizing the context had gone futile. Could have saved a ton of unnecessary work. Became lazy with documentation after a while. Initially, I was very enthusiastic about documentation, but I lost interest after a while. Big mistake on my part. Documentation is the most important skill that can reduce the repeated effort, lubricate and delegate communication in an effective manner. Was unsure about the priorities of many tasks. I am getting better at managing tasks with differing priorities. Didn’t time box my day-to-day tasks. Huge mistake. Everytime task has to be time boxed, you can’t keep dragging it till you can. Didn’t think reading existing code was a good idea. Again a huge mistake. Code and Tests are the best documentation of the codebase. Getting comfortable reading code is paramount to debugging. Learning is exponential when you’re on Support. The kinda of skills that get acquired when you’re on Support helps you to be more than a programmer. Communication, Delegation, Prioritization, Debugging, How-not-to-write-code and what not. Was not a good code-reviewer at the beginning. Was thinking too much about design patterns and other idealistic shit. Instead, could have focussed on common-sense and instincts. Any code should meet basic readability and making-sense aspects. Should have googled more about any unknowns I was encountering on day-to-day basis. Basic googling infuses much more context than anything will. Didn’t respect the human aspects that arise from code. I didn’t care much about the backward compatibility and constraints of various surrounding systems. Used to propose audacious things which have 0 percent of materialization. One word, was not realistic enough. Didn’t experiment enough and didn’t invest enough time in mastering the fundamental tech. Having code samples which can help you to play with things and mastering CLI tools can massively come to your aide when the situation arises. Gotta work on this more. Hands on experience beats everything. Didn’t pay much heed to my curiosities. Again a big mistake. Whether it is making small POCs and understand how they work or reading some good’ol research papers, you have to follow your curiosities.