Building shared context is

You see a problem at work and you think you have a solution. Some people you have spoken to in hallways agree with you. So you go ahead and try to solve it but suddenly start getting pushback from everywhere and eventually things don’t work out as you had thought they would. You are left bitter and frustrated at “them”.

How many of you have been in this situation? I know I have, and today I want to talk about what I have learned from those failures. This is an idealized version of how I now think about orchestrating…


There’s more than one way to bell the cat

I was recently reading an article by Neal Lathia about how using machine learning is not always necessarily better than using rule-based systems. There are pros and cons to taking either approach, and you should take the one which suits the problem complexity, expected execution speed, and various other factors the best.

I am working on a project which I and my team believe is a great fit for applying ML techniques. However, we have also achieved some measure of success in achieving our goals using a rule-based system. Without sharing the details, I can say that while we…


Hello Everyone!

I just published the 37th edition of my weekly newsletter “It Depends”. Check it out!

The great challenge of leadership is how to create large impactful changes in an organization. This week I wrote about why this is better done by building a shared worldview of the problem than by individual effort, no matter how inspired. Inspired by real failures :)

From the internet this week, @apenwarr on how system design explains the world, Nat Bennett on the ordeal of pair programming all day, and Martin Fowler on the strategy-execution in pursuing an internal platforms strategy.

If you like reading about technology and great teams that build technology, sign up for the next edition. Bring your friends too! You can check out the previous editions in the archive — https://kislayverma.com/newsletter-archive/

Cheers!

Kislay


On organizing code

Hello everyone!

I just published the 36th edition of my weekly newsletter “It Depends”. Check it out!

I’ve been meaning to write about how we organize our code for a while now. The most popular style is to put all services together, all repositories together, etc but that’s a bad idea. A better way is to group by entities and logical concepts, and I explain why in my article.

From the internet this week, @VitalikButerin on the most scarce resource in the blockchain world, @LukeCraven on why he can’t give people certainty, @mstine on system decomposition strategies, and @emgsilva on evolving organization using socio-technical architecture.

If you like reading about technology and great teams that build technology, sign up for the next edition. Bring your friends too! You can check out the previous editions in the archive.

-Kislay


By concepts, not by layers

What is the most popular style of arranging code you have come across in enterprise codebases? The one I have seen most often groups all classes (assuming Java-land) by the layer in the tech stack. So in an MVC style system, all controllers are together, all services are together, all repositories are together, all POJOs are together etc. Let’s call this convention the “stack” style of organizing code.

This is a terrible way of organizing code and I will explain why below. But first, allow me to offer the alternative.

A much better way of organizing code to group it…


Hello everyone.

The 35th edition of my weekly newsletter “It Depends” is out!

After multiple people asked me about it, I decided to write my thought process on deciding how large a method should be. It’s not about size as such but about reducing cognitive engagement (too large) and curiousity (too small).

From the internet this week, Ingrid on why decentralized applications don’t work, Brian Kerninghan interviewing Ken Thompson, @sc13ts on internal consistency in streaming systems, and @sarah_edo on why it should always be “us”, not “them” for engineering managers.

If you like reading about technology and great teams that build technology, you should sign up for the next edition. Bring your friends too! You can check out the previous editions in the archive.

Cheers!


Cognitive load should be the metric, not size

Let’s say there’s a method in the codebase that does 4–5 things one after the other. The code for doing all those things is well-written, but the result is a somewhat large method. At what point should you break it up into multiple methods? There is the old adage about every method being fully visible without scrolling which I have always found weird. Let’s try to do better.

The good part about having all of the code inside a single method is that it is all in one place and in a sense, easy to absorb in one shot. The…


Photo by Aaron Burden on Unsplash

Hello, folks!

The 34th edition of my weekly newsletter “It Depends” is out!

This week I wrote about why the trope of “move fast” should not be about movement at all but rather about creating the ability to move fast. Learning from the customer and solving their problems should occupy far more brain space for a team than the process of “cranking the wheel”.

From the internet, the guidelines on building “well-architected” systems on AWS, a history of socio-technical system design by F.M. van Eijnatten, thoughts on event sourcing as an antipattern by @OliverLibutzki, and the art of self-organizing engineering teams by Tom Sommer.

If you like reading about technology and great teams that build technology, you should sign up for the next edition. Bring your friends too! You can check out the previous editions in the archive.

Have a good weekend!

Kislay


Why “move fast” isn’t about moving fast

A sense of urgency in shipping features is probably the worst result of the agile mindset. While it makes some sense in absolute early-stage startups where everything has to be built ground up, but in places that have a little bit of stability, this is a vestigial mindset which causes a lot of problems.

Delivering the right kind of product is a three step process.

  1. Learn: This is where we try to identify the customer’s problem(s).
  2. Solve: We identify the best ways of solving the problem.
  3. Deliver: This is where the solution is built and delivered.

While tools help, Learning…


Photo by fotografierende on Unsplash

Hello World!

I just published the 33rd edition of my weekly newsletter “It Depends”. Check it out!

My handpicked best of the internet this week — how @ApacheFlink handles backpressure, Start with why by @simonsinek, the “pace layer” model for understanding layers in complex systems by @stewartbrand, and the internal design of @SnowflakeDB

If you like reading about technology and great teams that build technology, sign up for the next edition and bring your friends! You can check out the previous editions in the archive.

Cheers!

Kislay

Kislay Verma

Code, products, platforms, books, music

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store