DEV Community: Koma/こま

Reflecting on “Technical Leadership and Glue Work” / “Being Glue”

Koma/こま — Fri, 19 Apr 2024 16:23:55 +0000

There is a talk by Tanya Reilly called “Technical leadership and glue work” and a blog post transcribing it called “Being Glue.” (From here on, I will refer to it as “the article” unless specifically mentioning the talk).

Being Glue — No Idea Blog

Slides and notes for the Being Glue talk.

noidea.dog

Career as an Individual Contributor, not a Manager

Tanya Reilly, the author, is a former Staff Systems Engineer at Google and currently works as a Principal Software Engineer at Squarespace. As her job titles suggest, she has been successful in her career by advancing as an engineer rather than a manager.

There are several books on engineering management such as “The Manager’s Path” and “The Making of a Manager,” but there are not many books geared toward senior Individual Contributor (IC) positions. One such book is “Staff Engineer: Leadership beyond the management track.” And Tanya Reilly published her own book “The Staff Engineer’s Path” in 2022.

Glue Work and its dangers

“Glue Work” is the main topic of the article and refers to tasks like helping unblock other team members, reviewing design documents, and onboarding new members. These tasks may seem non-technical at first glance, but according to the author, they are part of “technical leadership” and are expected of senior developers. However, focusing too much on these tasks before reaching a senior level can harm one’s career, as it leaves less time for more “technical” tasks like coding and hinders the development of the technical skills required for promotion to senior positions.

In the article, a story of a female engineer is used to illustrate this point. It seems that many people can relate to her story. The author also mentions that women tend to be asked to do more of this type of work that doesn’t lead to promotions compared to men.

What should and shouldn’t I be doing?

So far, I have introduced the article. From here, I will share my own experience. I have spent a significant portion of my work hours on Glue Work throughout my career. I don’t dislike coding or lack interest in technology, but I tend to choose opportunities that allow me to contribute to projects and teams in ways other than coding.

I have made these choices because I felt that they were the most significant contributions I could make at the time, or because I found them the most interesting. However, upon reflection, I wonder if some aspects of my career choices have been less than optimal. For example, I consider my slowness in getting tasks done compared to other engineers around me to be a significant weakness as an engineer, and I believe that this is a result of my past choices.

I have been in the industry for six years now, and engineering management has become a popular topic in Japan since I entered the field. I have always thought that I might eventually move toward that direction, so I didn’t prioritize spending more time on “technical” tasks like coding. However, the article on Glue Work has made me reconsider the importance of the work I choose to do daily in shaping my career.

Lately, I have been thinking that continuing to work in the same way might not be the best for my team either. I would like to discuss my work and approach with my team members, manager, or even people outside my company to gain new perspectives.

Reading "A Philosophy of Software Design"

Koma/こま — Fri, 19 Apr 2024 16:20:49 +0000

I recently read "A Philosophy of Software Design," highly praised on my favorite Japanese podcast e34.fm. The first edition was published in 2018, and I read the second edition released in 2021.

What kind of book is it?

The theme of the book is the complexity of software. Complexity is defined as something that makes it difficult to understand or modify a system. Symptoms of complexity include simple changes forcing many code modifications, increased cognitive load (as mentioned in "Team Topologies"), and most critically, the occurrence of "unknown unknowns." These unknown unknowns are troublesome because they can easily lead to the introduction of bugs, but by definition, their existence cannot be noticed.

The book introduces various design principles to reduce such complexity. Although it may seem like a catalog of design principles, the development of the discussion is systematic, and it has the impression of a book written by a researcher.

Memorable sections

Deep Modules and Shallow Modules

This is a frequently mentioned part of the book, but it was refreshing to talk about modules in terms of Deep/Shallow. The book argues that Deep modules are better. This distinction appears in Chapter 4, but it is repeatedly mentioned in subsequent chapters as a framework (e.g., "doing this will make the module deeper").

---------------------------------
|       | Interface | Functionality |
---------------------------------
| Deep  | Few       | Many          |
---------------------------------
| Shallow | Many   | Few           |
---------------------------------

※ The term "many interfaces" refers to the number of methods or many arguments for a given method.

General-purpose and Special-purpose

This axis appears around Chapter 6, advocating for designing software that is somewhat more general-purpose than just meeting immediate needs.
Related to this axis, the advice to consider whether a process (code) is general-purpose or special-purpose and to ensure they do not mix, and the advice to remove special-purpose processes from the critical path in the chapter on performance (Chapter 20) were memorable.

About comments

It's often said that code shouldn't require comments, but in this book, the author discusses what kind of comments are good, assuming there are things that can only be done with comments.

Personally, I found the discussion about comments to be full of useful advice, but what stood out most was the distinction between comments explaining details more than the code or comments explaining more abstract concepts than the code. It's often said not to write comments that merely repeat the code, but considering the degree of detail and which direction to lean toward when writing comments seems very helpful.

Also, it was memorable that the book suggested writing comments first, as a means of design, rather than later. If you try to write comments later, they may end up repeating the implementation or not being written at all. By writing comments first, they become part of the design activity, making it more enjoyable and leading to design improvements by considering abstractions.

"Increments should be abstractions, not features"

In Chapter 19, the author discusses object-oriented programming (especially inheritance), Agile development, unit testing, test-driven development, design patterns, and getters/setters.

There were many familiar stories, but it was striking to find the statement "the increments of development should be abstractions, not features" in the discussion on Agile development. When doing incremental development, how to think about design is a major topic, and this was the first time I saw advice in this form. In the following text, it says, "When you realize the need for abstraction, don't take time to create it bit by bit; design it all at once." Although this is still based on "when you realize the need," the direction of highlighting abstraction as the main focus in the development unit is quite convincing.

Regarding the overall stance

I've introduced several memorable points above. Although there were many individual pieces of advice that made me think, "I see, that's an interesting way of thinking," overall, I was left with a strong impression that the style was quite different from what I've been accustomed to so far.

How to create a link between two spans in OpenTelemetry

Koma/こま — Fri, 19 Apr 2024 16:16:12 +0000

Summary

Span links are another way to express relationship between spans.
It is easy to create one in C# with the OpenTelemetry toolkit.
Datadog currently supports span links as a beta feature.

What is a span link?

In OpenTelemetry, there is another type of relationship between spans other than parent/child relationship. It is called Span Link. These are related documentations.

According to documents above, span links can be used in cases below.

when you want 2 separate traces rather than a single trace
when you want to connect multiple spans onto a span

How to create a span link in C#?

It is easy to create a span link with the OpenTelemetry toolkit. All you have to do is,

Propagate SpanContext of the proceeding span.
Create an ActivityLink and pass it to StartActivity method.

/* Producer side */
// add SpanContext onto the message
Propagators.DefaultTextMapPropagator.Inject(
    new PropagationContext(activity.Context, Baggage.Current),
    message.MessageAttributes,
    (attributes, key, value) => attributes[key] = new MessageAttributeValue {DataType = "String", StringValue = value});

/* Consumer side */
// extract SpanContext
var context = Propagators.DefaultTextMapPropagator.Extract(
    default, message.MessageAttributes,
    (attributes, key) => attributes.TryGetValue(key, out var value) ? [value.StringValue] : []);
// start a new span with a link to the producer's span
using var activity = activitySource.StartActivity(
    "ConsumeMessage", ActivityKind.Consumer,
    default(string?), tags, [new ActivityLink(context.ActivityContext)]);

Datadog supports Span Link

Datadog currently supports span links as a beta feature. You can see your span links in span view and move to linked spans with few clicks.