Srikanth Sastry A Techie in Boston

Reuse Code, Not Objects

We all know of the importance of code reuse and DRY code. It is important to remember that this applies to code, and not to objects!
A common anti-pattern I see in stateful classes is something along the following lines:

class SomeStatefulClass {
  private ResponseType responseType;
  private final ErrMessages errMessages;
  public SomeStatefulClass() {
    this.ResponseType = null;
    this.errMessages = new ErrMessages();
  public void init() {
  public Response process(Request request) {
    try {
      // Process the request.
      // Update stats.
      // Update otherState.
      Response response = computeResponse();
      responseType = computeResponseType();
      return response;
    } catch (Exception e) {
    return null;
  public LogMessages getErrMessages() {
    return this.errMessages;
  public ResponseType getResponseType() {
    return responseType;

This design pattern is a major code smell. Ironically, such classes are prone to be misused through reuse. A common example of this is reusing the object within a loop:

public void process(List<Request> requests) {
  final SomeStatefulClass statefulObject
      = new SomeStatefulClass();
  Response response;
  for (Request request: requests) {
    response = statefulObject.process(request);
    appendResponse(response, statefulObject.getResponseType());

The issue here is subtle, but dangerous. Consider what happens if one of the requests in the list of requests passed to process() causes statefulObjectto throw an exception inside computeResponse(). Dutifully, this exception is caught by process() and it returns null. However, note that the value of responseType in statefulObject was never modified by processing of this request, and therefore, it still hold the ResponseType of the previous request! Therefore, the line appendResponse(response, statefulObject.getResponseType()); is now passing in a null response and the response type of the previous request!
These types of bugs are subtle and a pain to track down.
And this happened because we chose to reuse the statefulObject. If we were to use a new instance each time, this would not really be an issue.
Moral: If feasible, do not reuse objects; create new instances and throw them away when done!

Code reuse can prevent bugs

I am as surprised as you are at the title. The statement does seem like "Duh!", but much to my embarrassment, I have seen enough code in many code bases to need to reiterate this.

The latest example was the following bug that I spotted. First some background. The caller to this function can choose any subset of a given set of 'modes' or 'features'. The caller represents this via a bit-mask. So 1 represents feature 1, 2 represents feature 2, 4 represents feature 3, 8 represents feature 4, and so on. So, if the caller requests with bit-mask 3, then it represents features 1 and 2, and bit-mask 10 represents features 2 and 4.

The following piece of code is support to filter out requests depending on the requested set of 'modes/'features'.

if ((bitMask & ModeEnum.FEATURE_FOO.getValue()) == 0) {
  // FEATURE_FOO has already taken care off the by some other module. So do nothing here.
  return null;

/* Some more code here */

if ((bitMask & ModeEnum.FEATURE_BAR.getValue()) == 0) {
  // For now, we process the request only if caller explicitly specified FEATURE_BAR.
  return null;
/* more code to process the request with FEATURE_BAR. */

The code above has a bug because the comment inside the first if-check does not match the if-check's logic. The intent was to skip processing the request if FEATURE_FOO is enabled. Instead, it does the exact opposite.

The naive way to fix it would be to replace

if ((bitMask & ModeEnum.FEATURE_FOO.getValue()) == 0) {


if ((bitMask & ModeEnum.FEATURE_FOO.getValue()) != 0) {

However, this misses the more important point of why this bug occurred in the first place. The simple answer to that question is that this bug occurred because the author ignored the principle of code reuse. By putting that principle into practice, a cleaner way to write this code (and therefore fix this bug and prevent similar bugs in the future) is as follows.

We first encapsulate the logic to detecting various modes via this function

boolean hasRequestedFeature(int bitMask, ModeEnum feature) {
  return (bitMask & feature.getValue()) != 1;

With that function in place, the new code looks as follows

if (!hasRequestedFeature(bitMask, ModeEnum.FEATURE_FOO)) {
  // FEATURE_FOO has already taken care off the by some other module. So do nothing here.
  return null;

/* Some more code here */

if (hasRequestedFeature(bitMask, ModeEnum.FEATURE_BAR)) {
  // For now, we process the request only if caller explicitly specified FEATURE_BAR.
  return null;
/* more code to process the request with FEATURE_BAR. */

This make the code more readable, and as long as we reuse the hasRequestedFeature() function, such bitwise operation fragility will not reoccur in the code.

Is this obvious? I think so. Was it necessary to belabor the point? Empirical evidence seems to scream "YES!".

Tale of two departures

Image by Maret Hosemann from Pixabay

Saying goodbye to a workplace where you have spent a considerable amount of time is never easy. But it can be made into a positive experience by the organization, or be made miserable. Netflix is famous for celebrating when an employee leaves by thanking them and wishing them well, and in contrast, Hubspot is know for firing something and calling it a ‘graduation’.

I have two stories to share on how my departure from two different organizations played out. Both both these stories, there were only good intentions all around, but yet, the executions of the departure were very different. The juxtaposition is instructive on its own.

First story: I said goodbye, and they said Au Revoir

Image by S. Hermann & F. Richter from Pixabay

In the first story, I had a meeting with my manager and told him that I accepted an offer with another company, and so was leaving. His immediate response was to check with me if there was anything he could do that will make me change my mind (he also prefaced that by saying that he thinks that the answer is ‘no’). After I said that my mind was made up, he thanked me for everything I had done so far, and said that he will set up meetings with various folks to help me transition my responsibilities.

With my consent, he immediately and discretely told members of my team, set up transition discussions, and then followed that up with an org wide announcement. Then, the entire team got together for a goodbye lunch, with everyone including the manager wishing me well. Finally, before I left, he said that he wishes me the best, but if things don’t work out with the new role, then I am always welcome back.

Second Story: I said goodbye, and they said uh.. wait, what?

Image by Alexas_Fotos from Pixabay

In the second story, I had a meeting with my manager and told him that I did not see my skills fitting the role, and that it doesn’t play to my strengths. So, I think serves both the org and me well to plan a transition for me to move on. He tried to convince me otherwise, and this went on for some time. I indulged his thoughts and arguments and made a good faith effort to pursue the avenues he suggested, but it only served to strengthen my initial proposition.

After I made my final decision, he asked to delay my decision until I had a new role. After I found a new role, he asked me to spend a month transitioning my responsibilities to someone else. But for over a week, I did not see any movement in the transition plan. Meanwhile, I am furiously preparing everything for the transition. Until about a week before my last day, there is no news of my departure, and no person or people to transition to.

With just over a week left, on my request, my manager calls the team together to announce my departure, except that he had already mentioned this to each of them private well over a week ago, but didn’t really provide any guidelines to them or to me about who else had been looped in. So, no one spoke to me about it, or to each other, and kept acting like everything was business as usual. It had become an elephant in the room and made everything uncomfortable for no apparent benefit.

Finally, the last few days were a frantic meeting spree with my transition of responsibilities to other folks, and my brain dump spread across multiple documents that was hastily reviewed by the team as my last day at work came and went.

My final goodbye was in an org-wide meeting where my manager thanked me for my contributions and wished me well.

Donts of processes for upward communication

Upward communication critical to organizational well-being and effectiveness. It is also notoriously difficult to get right due to the inherent power/authority differential involved in the hierarchy of any organization. Almost every place that I have seen upward communication done right focuses on mitigating this differential. Unfortunately, many organizations seem to be completely oblivious of how the existing power differential within a hierarchy can jeopardize upward communication.

Does your organization share this blind spot? For obvious reasons, it doesn’t help to ask the organization leaders about a blind spot. However, there are symptoms you can look for. Here are some examples, that I hope will help you see whether and why upward communication is failing in your organization. Note that all my experiences are from the software industry, and so I am focused only on software engineering organizations. So please keep that in mind as you read on.

Here are four IMHO important symptoms to look for.

  • Focusing on the format instead of a well thought out framework
  • Asymmetric commitment from the leadership on communciation
  • No reacting/responding to the contents of the communication
  • Not getting engineers’ buy-in

Format instead of framework

Any sort of ongoing upward communication tends to be only marginally useful if the organization does not have a framework within which the receive and process the communication. For instance, an organization may care about cross team collaboration, and could get information about this from employees through upward communication channels. However, without a framework for the employees to provide that feedback, the organization may not be able to glean much.

Unfortunately, organizations tend to conflate framework with format/template. When this happens you tend to see rigid templates or formats within which upward communication takes place leaving little space for nuance, reflection, and awareness to unforeseen issues. An example should make this clearer.

I worked in an organization which asked employees to fill out a weekly report. This report had mandatory questions such as “On a scale of 1 to 10, how happy were you working with other teams?” On the face of it, it might seem reasonable. But consider the following scenario.

An engineer who has had a bad week at work and wants to communicate that upward. She fills out her weekly report outlining her frustrations and why she hasn’t made as much progress and what’s blocking her. She proceeds to submit her feedback, but the tool rejects her submission because she didn’t answer the mandatory question. Effectively, the organization is saying “unless you give the information we seek, in the form that we prescribed, we are not interested in listening to you”.

When scenarios like these repeat themselves often enough, both the organization and the employees end up with blinders on what can and should be communicated. And that creates blind spots in the organization.

Asymmetric commitment for communication

When an organization sets up expectations for upward communication, it is automatically asking its employees to invest time and effort into it. If the organization does make a corresponding commitment on its end, it becomes demotivating for the employees, and any upward communication becomes either perfunctory or severely biased.

I recall a case where senior leadership wanted regular progress updates from all teams, for slightly different audiences and use cases, the content was required to be slightly different. The 'solution' to this issue was that team leads fill out almost identical, but slightly different, contents in an online form, a doc, a presentation, and a spreadsheet so it is all available for senior leadership when they want to review it. This is a really good example of asymmetric commitment. The effort here is expected entirely from the employees, and little from the leadership.

In contrast, I worked in organizations where management and leadership worked on upward communication along multiple avenues depending on how the engineers worked, and how the engineers liked to communicate. There were weekly/monthly sync up meetings where the management and leadership took notes, which the engineers communicated in the manner that was most convenient for them (including just talking, or presentations, or code changes, or screenshots, or even demos). Apart from that, the managers were also always sitting with the teams they supported, paying attention to the chatter among engineers and engaging when they realized some important decision were being made. The mangers participated in the decision making by proving additional context as appropriate, noted the decision that the engineers took, and made it a point to follow up on its execution while making an effort to not be intrusive.

That is an example of the leadership and management demonstrating their commitment to upward communication.

Reaction to upward communication, or the lack thereof

One of the expectations following upward communication is that the leadership with react to the communication, and then follow through on their commitment to address the issues brought into focus. When this redressal and follow through is missing, the impact is palpable and the consequences can be detrimental.

A common example where I have seen this is when the teams are expected to report progress and roadblocks, but the roadblocks are ignored by the leadership with the assumption 'the team will figure it out'. Or worse, at times, the leadership actually does not know what to do, but instead of making that a discussion, they choose to remain silent (for reasons that could constitute its own blog post). I assume I need not elaborate on the negative consequences of that behavior!

In cases where the leadership acts on upward communication, the impact can be dramatic and hugely positive. I recall two distinct cases in two different organizations I worked at, where the entire team had an unfavorable review of their manager. In response, the leadership immediately asked the managers to transition to a non-managerial role and re-org’d the teams so that they can have a different (and hopefully) more effective manager to support them.

Not getting engineers’ buy-in

Any upward communication process that does not get the engineers’ buy-in is bound to have limited success. Interestingly, this precipitates more communication processes that also do not have employee buy-in, and the cycle continues.

In one of the organizations I was at, the leadership, for reasons unknown, determined that a bespoke task tracking/project management tool be used. Very few engineers, if any, liked this tool. Yet, this was the tool of choice and decreed to be so. Not surprisingly, the tool was not well used, and so the leadership did not get the information they were looking for with respect to work done/progress made, etc. In response, the leadership created a new role that was focused on upward communication, and insisted that every team dedicate one person to perform this role. This not only took away one engineer from already resource-constrained teams, it also asked that engineer to execute a role that they weren’t really selected/skilled for. Naturally, that didn’t fare well either. There was improvement in upward communication as far as the leadership was concern, but it was not sufficient. So, the leadership decided that, harkening back to the Industrial Age, all teams should follow the exact same and synchronous development cadence and report progress on that exact cadence of the leadership. This cadence fit some teams better than others, and you can imagine the morale in the teams that ended with the short end of the stick there.

At no point during this entire affair did the leadership actually sit down with the engineers in various teams and actually ask them how the teams like to get work done, and how leadership could work with each team to accomplish the goals of the upward communication that was being sought.

Responding to concerns as a people manager

You are the people manager for a team, and a team member comes to you with a concern. How should you approach it? I have been in this situation multiple times, and have admittedly made some wrong turns. After some corrections and learning, here is what seems to work well for me (although YMMV). If you like lists, here is a snapshot of the path I take.

  1. Listen
  2. Empathize
  3. Don't take notes
  4. Descend into the particular
  5. Check with others
  6. Socialize, if the issue is common
  7. DO NOT become an apologist for status quo

Note that this doesn’t talk about the resolution for the issue. That is very specific to the issue at hand. What I have is more of an approach to understanding the issue in a manner that is respectful of the stakeholders. With that disclaimer, let’s unpack each of those bullet points.



When someone in the team you support talks about how things are not a 100%, just listen. And I mean really listen. Take what they are saying at face value, even if you suspect something else is at play. Be non judgmental. Give full attention here. This is a lot harder than it sounds! Beware of you mind trying to make connections with that you are hearing. Resist that impulse. Repeat back to them what they said, but in your own words. Ask for a confirmation if you have captured their thoughts and feelings well. Rinse and repeat until they respond affirmatively.



Now that you know what the team member is talking about, do not respond yet. Stop to empathize with them, or their situation. Even if you do not agree with them, still take the time to understand where they are coming from and why they are feeling the way they are. Talk to them to make sure you do understand where they are coming from. It is important not to come across as someone with all the answers, or worse, with condescension. It is important that the person feels validated and not diminished for sharing what they did share. Not giving them that luxury is a sure way to get them to express themselves less and hold things within themselves until it gets to a point where they decide to leave.

Don't take notes

Original Image by StartupStockPhotos from Pixabay

Really, put your pen, phone, laptop (or whatever you use to take notes) down. Taking notes during this process does harm on two fronts: (1) it impedes your listening and your ability to empathize, and (2) it can have a chilling effect on the other person's candor.

When you start taking notes on what you are hearing, your brain stops listening because it's too focused on ensuring that what it hears is making it into the notes. This directly impacts empathy in that when you don't listen, you cannot empathize. You might think that by the other person see you take notes, they get the impression/message that you care and you want to make sure nothing is lost/forgotten. However, when it comes to matters where they want to be heard as much as they want their concern addressed, they are looking for a real conversation, and taking notes decidedly gets in the way.

Many such conversations where a team member is bringing a concern comes with an automatic expectation of some form of confidentiality and discretion; otherwise, they would have brought this up in a group and not in private. The moment you start taking notes, you are giving the impression that everything they are saying is 'on the record and in writing' so to speak. This makes the speaker guarded; they no longer feel comfortable speaking in a fluent stream of thoughts; they might feel the need to measure their words lest it be misinterpreted from the notes.

Descend into the particular

Image by Gerd Altmann from Pixabay

After hearing the person out, remain focused on the specific issue they are bringing up. Do not try to generalize. By generalizing you risk losing important details that might be critical to addressing the issue. Also, when it comes to such issues, it helps to solve the exact problem at hand first, and then look to address the general case outside the scope of what the team member is bringing up.

For instance, I had a team member come up to me and say that their lead engineer was micromanaging them too much. The lead would literally look over the engineer's shoulder and insist that the engineer do things exactly the way the lead wanted them to do it. To get away from the lead, the engineer started working away from their desk, but the lead ended up following them to where ever the engineer was and proceeded with the same behavior. Here the engineer is coming to me for a solution for this particular issue, and it does not help for me to start thinking about generalities such as hostile work environments, issues of gender and under-represented minorities, or workplace aggression. Instead, I chose to focus on the two individuals involved, and the current situation that needed addressing. I strongly recommend you do the same!

Check with others

So, you listened, empathized, kept your focus on the issue at hand. Next, we start trying to resolve it no? No! Don’t try to solve the issue yet. Check with others to see the issue is more widespread than the single individual.

There are multiple ways to do this, and it really depends on the issue at hand. You can bring it up with others in various contexts and situations, but be sure to respect the original team member’s privacy and discretion. And do this urgently. Letting too much time go by sends the wrong signal to the person who brought up the issue in the first place.

By checking with others you get an important signal. Is the issue singular int hat it is just this individual facing it, or is it an issue that multiple people are facing it, but one only of them brought it to you attention. This signal has a strong bearing on which way to proceed next.

Socialize, if the issue is common

If you find that the issue raised actually affects more than one individual, it is important to socialize it. It conveys that the organization is willing to engage in difficult conversation for employees' benefit, and it is important that everyone sees that. Of course, you have to mean it, and actually follow up with actions that address the issue.

DO NOT become an apologist

This is a strong temptation. Given what you know about how your organization and your leadership works, you might want to explain how the issue arose due to misunderstandings, or how the person who brought up the issue is misinterpreting things, or how things really are working the way things should and all that this person needs is a little faith and patience, etc. The argument doesn’t matter. The mistake is to make any such argument at all.
By becoming an apologist for the status quo, you are effectively victim-blaming. You are telling the person who brought up the issue that it is somehow their fault that this unpleasant situation has come about. You can only imagine the ramifications of that insinuation. So, just don’t try to justify any part of what happened.
Once you have these pieces in place, whatever resolution you come up with likely to be better received, and therefore, result in a better outcome.