The issue with Feedbacks

I love feedback. I believe in feedback a lot. However, not all feedback is good, not all feedback is applicable, and not all feedback is fair. Feedback is critical for course correction and growth. However feedback can be manifested in a variety of shapes, forms and intentions. I believe in creating several mechanisms for feedback because, eventually, what needs to be found will be found. Feedback is a signal; sometimes, it tells more about who is giving the feedback than the person receiving it. Other times, feedback is just wrong. Whether feedback is written or bad, it's an important signal. I believe in being more effective and in the speed of change and improvements. However, can you go fast if you dont understand what you are doing? That's my issue with feedback. Oftentimes, feedback is poorly constructed and missing essential details. So, dealing with feedback is not so different than handling high-priority, difficult production bugs. Requires deep tought, introspection, and time. 

Handling a production bug

Let's talk about a production bug. Getting an empty JIRA ticket with no stack trace, error, or steps to reproduce the problem is common. So you need to investigate; the standard steps start with:
  • Talk to someone: Usually, who opens the bug, you might uncover some tips and clues.
  • Look at the code Changes: A recent change could have introduced the bug. Check version control in Git and see if any commits catch your attention. 
  • Look at the Logs: Look at the production logs; usually, central log solutions have good query capabilities that can allow you to have more clues and, if you are lucky, some stack track or error.
You are gold once you have good clues, reproduce locally, and write a test that fails. However, sometimes that is not enough. Looking into dashboards, metrics, and alerts and understanding the effect downstream and upstream. But sometimes, this is not enough, and you need to go deep and do:
  • Look at the code: Not only application code, but libraries code and frameworks code, all the way down to platform code and even languages and kernel code.
  • Debug and Profile: Yes, debug and profile local, and sometimes it's even necessary to do it in production.
  • Simulation: Write code to simulate the problem in the form of POC; you might have an easier time understanding what's happening.
If you are very lucky with a couple of Google searches and you find someone with the same symptoms the solution works. No matter what you are ready and prepare for a battle because is production. When we talk about people and feedback, we do not have 1% of these tools and techniques because often information is sealed and hidden, so how can you debug something without looking at the code and without proper observability and troubleshooting tools is hard, right? That's the issue with feedback.

Feedbacks are Riddles

Comparing feedback with troubleshooting a problem in production should make us realize how little we know about the real problem (if it exists). Feedback often comes in riddles, subtle comments, and small gestures. It's hard to capture that and reason with a lack of information.

The more you share details and talk openly, the more maturity your team needs. However, dealing with and fixing problems is easier when we are open and discuss issues like production bugs or incidents. 

Systems don't have emotions (for now, AGI is not here yet). It's much easier to fix a bug in production than to get good feedback and the facts straight to resolve the issues. We need trust and maturity to get better feedback and better results. 

In his classic Five Dysfunctions of a Team, Patrick Lencioni discusses the dysfunctions every team has. Without addressing the foundations' roots, it's impossible to create a high-performance team because you can only go so far. I strongly believe in highly competitive sports teams like the NBA in the US and the Champions in the EU. If you are looking for a great feedback book, the best one I ever read was Thanks for the Feedback by Douglas Stone and Sheila Heen.

Getting Better

In order to get better feedback, here are some things that can be done:
  • Detach you from your work: It's okay to make mistakes and have things to improve.
  • Be comfortable with discomfort. Nothing grows in the comfort zone, and being uncomfortable is good. It means we are into something. 
  • Make feedback public: Like blameless incident reviews, the more open you talk, the more facts we have and the better chances we have to fix the "bug". 
  • Don't take things personally: Where you are today does not matter; where you will be tomorrow matters. As long as you are constantly evolving. It's fine.
  • Don't take problems from others as yours: IF John got a call out and has things to improve, this is John's problem, so Adam should not take it into his heart.
  • Mind the Culture: When you work internationally or with different countries, understand that the culture is different, don't assume things are personal, and understand that there are things you need to learn. Being direct is a good thing. Feedback is good. The lack of feedback is much worse. 
  • Share the facts: Be as open as possible and share as much as possible; more information is critical for better understanding and addressing problems. 
  • Give more feedback, Ask for more Feedback: Give feedback more often, ask for more feedback; you will see it's not a monster with 7 heads, and you will grow and learn how to appreciate transparency.
  • Trust your Leader: Trust your leader knows what he is doing and ask for help when you don't know what to do and how to proceed. 
  • Practice: The more you do, the more moral will be better you will be.
Silence is the worst thing you can do. As I wrote in my Ignoring Culture, Cost of Silence and Training like Pros. If you want to learn more, I recommend my 3rd book. Continuous Modernization covers the mindset, practices, and shift to better work data with teams dealing with feedback and other soft-skills in complex, distributed systems at scale.

Cheers,
Diego Pacheco

Popular posts from this blog

Having fun with Zig Language

Image
Zig is a general-purpose language created in 2016 by Andrew Kelly .  Zig aims to fix the issues C language has while being pragmatic and simple at the same time. Zig really shines as being simple by not having any hidden control flows, not having hidden memory allocations, no pre-processors, and no macros. Basically, it's one language and one language only. Since pre-processors and macros can get really complex and become their own universe. Sure it's not the Zig Philosophy.  Zig Compiler(Zig cc) also is a C compiler, and the interoperability from C to Zig is very good. Clearly, we can see influence from other languages like Go and Rust; however, Zig is pretty unique and different from Go and Rust.  Zig is fast. Zig is perfect for system programming. I bet we will see a lot of solutions being built in Zig. As a languages aficionado, I like to learn at least one language per year and sometimes more; Zig was my 2021 pick, did not regret it. Even if you dont use all language...
Keep reading

C Unit Testing with Check

Image
When I start on IT, several years ago(+15), C was the first language that I learned. But was not the first language I mastered and deployed in production which was...surprisingly Visual Basic 6.0. However, when I learned C or any language back on that old and arcane time noddy was into testing. However now is impossible to work professionally in any language without tests. C is a low-level language but still kicks ass and has several interesting libs/frameworks. People use to fear C a lot because of lack of syntactical sugar but once you get used to it is not that hard at all. Today I want to show how you can do Unit Testing with C. I will not show how to do Unit Testing with C++ but with C ANSI actually. We will be using Check a unit test lib for C ANSI.
read more »

HMAC in Java

Image
In 2018 AWS CTO(Vogels) said : "Security is everyone's job". For the last 2 years, there was so many famous and big data leaks and breaks that made that statement be very true more than ever. Security often could mean worst performance and worst user experience so in order to get it right you really need to think about the designs before jumping into to code and consider performance and user experience has main requirements.  I was thinking about writing about how to do HMAC in Java for a while and recently Redis 6.0.0 come out and to my surprise, there was a refactoring on the password part in order to use HMAC.  Security easily could scare engineers often because it is not something well spread yet but I believe this will change soon. It does not matter if you have to deal with PII Data or not, security is super relevant because everybody is running their workloads at the cloud or with IoT and Edge devices which means more distribution, more code, more points of fail...
read more »