Software + Management // by Mike Borozdin

Comments are a topic of vibrant discussion.  Ever since programmers could leave some text in the program that was ignored by the machine the debate started: “what’s a good comment, what’s a bad comment, why comment?”
There are endless instructions to programmers that say many of the following things: 1)Describe your function! 2)Don’t write in the comment what you wrote in the code. 3)Tell people why you are doing what you are doing.
What I think has been missing from this discourse is the audience for comments and through those audiences there is intent.  The code is being read, skimmed or analyzed by people and tools.  So what are the audiences and reading modes?
1)Maintaining and enhancing the code 2)Skimming through the entire module or file to figure out what the overall structure is 3)Reviewing the test files to check out the test coverage and edge cases 4)Seeing the docstrings of functions while being in a separate file altogether 5)Reviewing the files for copyright and intellectual prope…

The Last Dance on ESPN is a huge hit.  I was a teenager during the Bulls’ era in the 90s and it was a wonderful way to relive the magic of that time.  For those of us who are in leadership roles, there were a lot of great lessons from players, coaches and managers of a  basketball dynasty.  However if you are looking to use some of Michael Jordan’s leadership tactics to your organization - I think it’s critical to know what applies and what doesn’t.

There is a myth around in Silicon Valley about a hard charging leader, who is pushing his team to get them to operate at the “next level.”  There are stories about how Steve Jobs and Bill Gates were mean to their employees, this is lauded as a key ingredient to success.  People who buy into that saw Michael Jordan pushing his teammates as a proof point that it’s the way to get it done.  The truth is that your company is not an NBA franchise.

Tech workers today do not put up with people pushing them and definitely won’t take a punch like S…

There is nothing that says that a constructor of a class can’t perform complex transactions, but most of the people do not expect them to be long running or fragile.  When someone is writing a constructor that connects to a database, makes a network call, parses files on disk or something that can error out, that is not intuitive.  In the words of Big Lebowski “you are not wrong, you are just an a-hole”



My overall mantra of intuitive programming and design is that you should create systems with the principle of least surprise to the caller and maintainer.  Most of the programmers assume that object constructors rarely fail and rarely take a long time.

Constructors are generally used to create object and assign default or provided values to the fields in the object.  The trouble with overloading the constructor with something super heavy is that while you can remember that this is a “special constructor” others won’t intuitively get that.  Often times when you do something strange you…

Reading code is only easy in trivial systems and a system that has a lot of functionality usually has a lot of code.  Reading code is a critical part of what software developers do every day so it makes sense to make reading code easier by making the code more intuitive to the largest population of programmers.

There are books and numerous articles on software design, patterns and naming conventions.  I encourage everyone to read those, this blog post is not an attempt to create and exhaustive guide to writing good code.  Here I am going to cover a few small hacks that help people understand what your are doing faster.  The first topic of discussion is classes.

When I started programming in 1990s Object Oriented Programming (OOP) was all the rage.  After 25 years I have noticed that software field has fashionable trends where “everything must be so”, so in 1990s a lot of people were into C++ and Java (today the fashionable thing is micro services). Objects and classes were not invent…

Deadlines are a necessary part of life.  I wish all the things I worked on didn’t have deadlines, yet I want other people to give me a timeline and stick to it.  For instance: I am currently going through a house remodel and it’s taking longer than we thought (most of them do).  It takes a massive amount of awareness and empathy to understand that getting everything right is impossible when you are paying for it out of your own pocket.

It’s hard to talk about deadlines in isolation, deadlines are a part of a larger system of goal setting: time, teams, objectives and results.

Over time my view on the subject of deadlines has evolved and I am certain that a part of this article is going to be a shock to some people who worked with me several years ago. I was an early adopter of Scrum in 2001 and loved sprints with estimates for a long time, but in the last couple of years I have stepped away from Scrum because I realized that Scrum fails to distinguish important vs unimportant tasks an…

After having developed several distributed systems and been a part of dozens of architectural discussions I decided to put together a way to frame the microservices debate. Microservices have been fashionable for some time. A lot of it stemmed from the fact that big and successful cloud companies are using microservices.  It seems reasonable that to create a “serious system” one must be using serious tools and architecture, today it’s microservices.  No engineer wants to be called out for creating a solution that “doesn’t scale.”

The definition for a microservice varies, but overall it tends to be a piece of your system that can run somewhat independently (unless of course it depends on other microservices) and has a REST or queue processing interface.  Overall code encapsulation and separation of concerns have all been around for a long period of time.  Current evolution with containers, fast networks and REST API allows people to easily integrate pieces of their system using web se…