Software + Management // by Mike Borozdin

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…

Most of the literature about interviews is focused on how to give good answers and get an offer letter.
I talk to a lot of candidates that forget that interviewing is a bi-directional process.  In the world of technology companies and startups specifically the candidates are interviewing the company just as much as the company is interviewing them.  Over the years I have collected some questions that I believe could help someone understand if the opportunity is right for them.  Here are some areas that I believe every candidate should touch through the interview process:

Business Who are the customers?  What happens if they don’t have your product?What are the revenues right now and what are the means of ramping them up?What is the financing now and how much runway do you have left?When delivering your product/service - how much of the process is digital and how much of the process involves people or hard assets?  Are those non-digital parts of your service on your books/payroll?What …

When your work is to manage an engineering organization there are few people you could get advice from.  If you are a Director, VP or CTO in a tech company there might be zero to a handful of other people with similar job responsibilities. Almost everyone accumulates a number of mentors or friends throughout their career but those connections fade and sometimes geeks feel weird asking other geeks to “get together and catch up.”

I have come across Enrich (https://www.joinenrich.com) which is a facilitated peer groups and it helped me get some perspective and advice I don’t think I’d get anywhere else.  This group costs money and my company doesn’t pay for it, so I was fairly resistant to signing up for it at first.  My thoughts were that I am already paying a huge premium for living in San Francisco which has the highest concentration of technology leaders in the world.  I should be able to connect with people and foster those relationships without having to pay someone to organize gr…