A few weeks ago, I wrote about how we should design any system from one logical level up, i.e. considering the environment of our system. A Redditor offered an interesting comment that this approach was contrary to how anything natural evolved. Natural evolution is always bottoms up and that seems a lot more flexible.

This is certainly a valid observation and it got me thinking. Natural evolution happens bottom-up with everything co-evolving at the same time. Why should we not define and build the lowest levels first?

The purpose of a system

I have come to the conclusion that the difference is one…


KNOW THE EFFECT you intend to create

I was recently listening to my friends argue about whether to privatize govt banks or not. Some argued that this will improve efficiency, some wondered if private corporations can be trusted with all the banking in the country, some debated socialism and its pros and cons.

Photo by Dmitry Demidko on Unsplash

This is a common discussion pattern in both formal and informal settings. A lot of public opinions are framed this way (e.g. rapists should be summarily hung, but what about humanitarian treatment or legal rights) so is a lot of tech hype (e.g. …


Theory building, visual probability, index while read, and hiring a dev manager

Photo by AbsolutVision on Unsplash

Hello everyone!

The latest episode of my weekly newsletter It Depends is out! Go get your weekly dose of great technical reading.

This week, Peter Naur on how programming is theory building, visual representation of probability and statistics, @bernardleong on indexing while read, and @mipsytipsy on hiring a dev manager.

If you like reading about technology and 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


Libraries, scalability, autonomous teams, and domain driven design

Hello everyone.

The latest episode of It Depends is out! Go get your weekly dose of great technical reading.

This week on the blog, I shared some guidelines on how to write good libraries. These are slightly meta as compared to the usual hard-nosed advise on API design, abstraction, etc, but I hope you willl find them useful.

From the internet this week, the @Dream11 approach to scalability, a beginner’s guide to domain driven design using Symfony, empowering autonomous teams, and @lesscraiglarman ‘s law of organizational behaviour.

If you like reading about technology and 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


Photo by Fotis Fotopoulos on Unsplash

What is a library?

A library is a collection of implementations of behavior, written in terms of a language, that has a well-defined interface by which the behavior is invoked

Wikipedia

So a library is an artifact containing the implementation of some functionality but hiding it behind an API. “Host” systems can use the library to achieve the functionality by simply invoking the API instead of having to understand the implementation. Libraries are created to share code between multiple systems. e.g. In the Java world, Rulette is a rule-engine library published to a central repository. …


Competitive programming, cleaning up noisy labels, forking gRPC, and the heptagon of configuration

Photo by Glenn Carstens-Peters on Unsplash

Hello everyone!

I just sent out It Depends #46. Go get your weekly dose of great weekend reading!

This week on the blog, I wrote about the rise of competitive programming to fetish levels in colleges and how this has broken the junior engineer hiring process. It’s a classic case of gaming the metric which is hurting the industry badly IMO.

For those who prefer audio, you can listen to it on Spotify, Apple, or Google.

From the internet this week, Aline Guisly on using event-driven architecture to clean noisy labels, @mattrickard on the heptagon of configuration, DRPC as a…


We need to de-escalate

This post is a rant. I know that this is not true of every company and or every engineering student. But it is widespread enough in my experience that I find it worth ranting about.

tl;dr

Competitive programming is a good tool for building the programming muscle. An extreme pursuit of competitive programming is worse than useless. Unfortunately, companies and students are both headed in that direction at the moment instead of looking for engineers with broad interests.

From competency to fetish

Competitive programming started out as a good thing. When I was in college, there was no leetcode or equivalent websites. I think…


Edge computing, agile manifesto, Hexagonal architecture, and bureaucratic blunders

Photo by Maxim Ilyahov on Unsplash

Hello Everyone!

I just sent out It Depends #45. Go get your weekly dose of great weekend reading!

For those who prefer audio, you can get the podcast on Spotify, Apple, and Google.

This week on the blog, we cover the rise of edge computing as a transformative new architectural paradigm. We discuss the various use-cases that it will unlock, the companies that are taking a lead in this field, and the ways in which it will change the developer experience.

From the internet this week, @RonJeffries shares perspective on the agile manifesto, @adlrocha on IPFS, a couple of guides…


This article is contributed by Maaz Humayun. Maaz is a senior engineer at Amazon. He spent five years with Amazon Appstore working on high-volume web services that power search, ordering, and entitlements on first and third-party devices. More recently, he’s joined the Amazon Luna team, where he’s working on game-streaming tech. In his free time, he enjoys reading about SaaS platforms and new trends in software development.

You would be hard-pressed to find an industry the internet has not yet transformed. Banking, health, publishing, entertainment; the list goes on. And we’re all better off for it. Internet-enabled services are…


Tech Debt, Edge Computing, Decentralization, and Flow Architectures

Photo by Glenn Carstens-Peters on Unsplash

Hello everyone!

I just sent out It Depends #44. Go get your weekly dose of great weekend reading!

This week on the blog, I discuss technical debt. I find it instructive to view software engineering as the process of converting tech debt into knowledge about the problem domain. So if a team can deliberately take on tech debt and continuously eliminate the worst of it, they can achieve a lot.

For those who prefer audio, you can check it out on Spotify, Apple Podcasts, and Google Podcasts.

From the internet this week, the Cloudflare team on edge computing, @lsanger explains…

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