Cross-Training for Software Engineers

Disclaimer: No Exercise Required

We don’t often make the comparison of software engineering to running, but in my time doing both, I’ve learned that cross-training is just as important for developers as it is for runners. Competitive runners cross-train by targeting exercises that provide different benefits than running: lifting weights increases strength, plyometrics improve agility, and swimming reduces the risk of overuse injury. Swapping out a few runs for cross-training doesn’t detract from their running — in fact, the variety makes them better athletes.

Similarly, the variety of cross-training will actually make you a better software engineer. Working on multiple similar software projects concurrently rather than just one will help you to consider different (and possibly better) ways of implementing your changes. By understanding the unique features and structure of each project, you’ll gain a deeper understanding of the problem space, and you’ll be able to use that understanding to compose the best possible solution for each individual project.

To demonstrate why this is true, let me tell you a story — a story involving two open-source web frameworks (Flask and Django), one standard distributed tracing API (OpenTracing), and one developer (…me).

Developing a Flask-OpenTracing Extension

The beauty of Flask is that it’s an incredibly simple web framework to learn. In fact, it’s not even considered a full framework, but rather a microframework, since it leaves most design choices (databases, authentication, structure, etc.) up to the user. Most of its functionality actually comes from third-party extensions instead of its core, which made it a great first framework to write an extension for.

Python, the language that Flask uses, has convenient decorators that can wrap methods to extend their functionality. For example, if you want to generate italicized HTML, you could create a decorator @italicize that would return any text wrapped with italics tags as follows:

Using this decorator on hello_world() results in:

> print hello_world() <i>Hello world!</i>

This is perfect for integrating OpenTracing, since its goal to create spans that represent the lifetime of requests to the server, which in Flask are handled by view functions. I created a function decorator @tracer.trace that would, in short, create a span when a view function was called and end the span after the function returned.

The end result was an extension that allowed users to integrate OpenTracing in their Flask app with one import, one tracer initialization, and a decorator on any view function they want traced. Running the following app and navigating to `/traced-path`, for example, produces a trace.