DEV Community: Liran Haimovitch

A Software Development Manager’s Guide To Beginner Mistakes

Liran Haimovitch — Thu, 16 Mar 2023 13:15:19 +0000

R&D managers, when first stepping into the role, tend to make the mistake of choosing one of two extreme management approaches. Each of these comes with its own set of challenges – and its own set of organizational waste. And that’s the last thing you want to create as a manager.

So if it’s your first time as a manager – or you simply feel like brushing up on your dev managerial skills – how can you keep delivering awesome tech for your company while keeping your team safe?

Understand Which Approach You’re Dealing With

When it comes to software development, dev managers, when first entering the role, tend to adopt two common types of ‘anti-patterns’, or as we’ve dubbed them, ‘bad management practices’. These are commonly used processes, structures, or patterns of action that often seem legitimate and easy to learn from but are usually counterproductive and ineffective (i.e. spaghetti code or God class). The more we know these, the better we can learn to handle them. These two patterns are:

The Guardian – this manager does everything to protect their team from anything outside of the R&D
The Pleaser – these managers focus on having their team deal solely with putting out fires for the rest of the company to keep everyone happy.

For obvious reasons, neither of these is ideal.

The Guardian

This persona in this bad management practice is called the guardian. Their team is their top priority. They focus on preventing interruptions that waste their team’s time on any other issue than the internal work of their team, such as fixing bugs immediately or joining a meeting with a client that requires more technical knowledge. Typical examples of the way they speak often sound similar to: “We’re building features here”, “R&D is expensive”, or “let us do our job.”

This type creates external organizational waste as well as internal R&D waste. Not only do they create a situation in which other teams aren’t being supported – causing others to search for workarounds that often take more time and resources – but also create a situation in which they aren’t helping deal with the actual fires that pop up in the R&D team itself.

The Pleaser

This is the other extreme, in which the manager prioritizes new requests to keep building relationships instead of his team. This kind of behavior includes actions like fixing bugs that are not urgent, supplying a quick response to every client, etc. This type of manager believes that his team can – and should – fix everyone’s problems. You’ll often hear them saying things such as: “Oh, that sounds urgent” or “I’ll deal with that immediately.”

When we speak about relationships, we know that every type is different. However, here we are specifically speaking about internal work relationships. For example, how relationships between R&D members differ from relationships with colleagues surrounding R&D – account managers, support engineers, product, and even sales. These external forces obligate managers to consider their opinions and current needs.

This managerial type will probably create internal organizational waste for his team. One of the effects of this waste is R&D burnout, which in turn will cause the R&D team to handle less of the load from other departments. Another effect of this managerial method would be the growth of technical debt.

We can see that in the long run, the aim to please will actually harm those same departments. It can also create an unfulfilled roadmap that prevents product innovation and create a lot of internal waste.

Natural instincts

At some point, tensions will arise between making the company happy, keeping your team safe, and doing that without littering everywhere. As a new manager, facing unexpected urgent challenges can cause a lot of pressure and sometimes can even make one feel attacked in a new relationship. This unknown situation brings us back to examine our basic instincts: fight, flight, and freeze.

The two first mechanisms help us adopt an immediate reaction without any further thinking. Imagine for a moment you’re in the middle of a jungle with a lion in front of you. This unexpected stressful situation forces you to react immediately to save your life. The first option is to immediately run away or fight the lion. It requires a quick, unconscious response.

Similarly, going to these two extremes as a first-time manager helps us decide how to react and whether to fight the threat or run away. There is a third choice of freezing and doing nothing, but obviously, that’s not recommended in the slightest.

Finding the middle ground

Managing is ever-changing and stressful, primarily for new engineering managers. Falling into the embrace of one of the two ‘bad management practices’ is easy – especially when they look like success. Yet, to not only solve – but get ahead of – these problems, we need to understand exactly what we’re working with. There’s no reason your organization should suffer just because you don’t have all the cards out to play.

So what do we do? First, take a look at the reasons that a manager tends towards an extreme. Did they decide to become a manager to care mostly about their dev team? Is important for them to fix the organization’s problems? Then, understanding the root cause enables us to think of the messages we’d like to transfer to our team and colleagues and try to change this tendency.

Being aware of these mistakes can help turn you (or finetune you, since obviously, you’re awesome) into a better manager and ensure your team – and company – are always performing at top velocity.

The Missing Piece

Liran Haimovitch — Sun, 26 Feb 2023 09:19:25 +0000

Somewhere in 2017, I made the decision to move into DevOps and DevTools. As a notorious bookworm, I made my way through quite a few books while learning about this new realm. Particularly, I remember reading through the Google SRE handbook, or as some of my friends like to call it, “The Dev Bible.” There is an endless amount of takeaways you can take from it, but my personal favorite is how Google built the first planet-scale web service using nothing more than metrics for their core Observability.

For the past few years, I have felt that metrics are something we are missing out on at Rookout. We’ve focused heavily on perfecting the core debugging experience and integrating with some of the cooler kids on the block (distributed tracing, I’m looking at you), and really never got around to taking a stab at it.

And then, our engineering team stepped up and decided to make it happen.

Do you already have great metrics?

Well, metrics are roughly divided into two categories. Metrics for off-the-shelf code (databases, queues, libraries, frameworks, etc.) and metrics for your code.

Metrics for off-the-shelf code are easy. Everybody knows that code - and most APM services - provide excellent instrumentation out of the box for it. Period.

Metrics for your code are hard. Unfortunately, these are the important metrics. These are the metrics Google talked about in that book. Another well-known example of this type of metric is the Facebook Like button, which became the company’s Northstar and the cornerstone of its operational monitoring.

Code-level and business metrics provide you insights into vital questions such as:

Are you serving your customers well?
Are you generating value for the relevant stakeholders?
Is this function being used?
Is this code path hot or cold?

Only engineers on your team can effectively add those code-level metrics. After all, you kind of have to understand the code to do that.

What’s so hard about that?

Well, I’m glad you asked. Every time you want to add a new code-level metric, you need to write a line of code that reports that metric. And then, you need to build and deploy a new version of your application with that line to the appropriate environment. That’s where things often go wrong.

Defining the metrics you need to monitor your code effectively is a process of experimentation, trial, and error. Over time the metrics will improve, but you’ll undoubtedly run into various blindspots. Maybe you are troubleshooting an incident and need to split a metric into two. Maybe you are designing a new feature and need to answer a one-time question. Either way, traditional, static, code-level metrics won’t be able to get you the data in an efficient and timely manner.

This leads us to metrics FOMO (you might have read my previous blog post on Logging FOMO), which is adding endless metrics in the hopes that you’ll cover everything and have no missing data ever. Well, you won’t. With most Observability providers charging by the volume of data, you won’t hear them complaining about it. But your CFO might.

I can go on and on about how hard it is to correlate metrics with the code that’s producing them and how metrics that were added to answer a single question once are left in the code for years. But it might be time to shift to that new feature I promised.

How’s Rookout different?

In the new Live Metrics mode, you can instantly add a new metric to any line of code by simply adding a Non-Breaking Breakpoint on that line. Think of it as zooming out of our “regular” Non-Breaking Breakpoint, where each hit would have taken a full snapshot of the application state.

Live Metrics offers rate and counter metrics without any quotas or usage-based fees, with additional metric types and export functionality in the works.

Summary

Live Metrics is in early access, so reach out, and we’ll hook you up :)
https://www.rookout.com/

Webinar- Code & Context: Debugging running code faster with intelligent observability

Liran Haimovitch — Tue, 17 Jan 2023 10:48:04 +0000

Date & Time: 21st February 2023, 11:00 am (ET)

As digital transformation continues to accelerate and customer demands increase, traditional approaches of debugging are limited and reactive troubleshooting is insufficient. During incidents, developers need to quickly understand the relationships between user sessions, topology, and end-to-end transactions. In addition, they must have the tools to triage and debug what the code is doing in order to resolve issues and minimize user impact.

To help with this need, Dynatrace brings together high fidelity distributed tracing, code-level visibility, and advanced diagnostics across the most advanced cloud-native serverless and service mesh architectures. Dynatrace uses a sophisticated AI causation engine, called Davis®, to automatically tell you when there is a problem, the business impact, and the root cause. With these answers, Rookout’s Developer-First tooling and observability solution enables developers to capture live debugging data across your tech stack without stopping and redeploying the running application.

Rob Jahn, Sr. Technical Partner Manager from Dynatrace will be presenting the webinar, along with myself, Rookout Co-Founder & CTO.

We'll discuss and demo 👨‍💻:

Common observability challenges of cloud-native architectures.
How to capture and analyze timing and code-level context for distributed traces end-to-end and across the full stack.
How to collect metrics, log lines and debug snapshots from a running application, troubleshoot faster, and get instant insight into your app.
How easy it is to get started with the Dynatrace-Rookout integration.

⏩ Register Here: https://www.rookout.com/webinar-debugging-running-code-faster-with-intelligent-observability/