The 'Right' Type Of Graph; Starship 🚀; Performance Reviews
Today’s post is rather diverse, ranging from chart idiom choices (with a dash of design principles), a fairly new and robust cross-platform shell prompt, how to kick performance reviews up a notch, and a follow up to a previous newsletter.
The 'Right' Type Of Graph
April is #30DayChartChallenge month on Twitter (and, usual, work+life has gotten in the way of me keeping up with posting charts daily). There have been “theme” days where the only rule is to create charts in the distinct style of The Economist‘s data team1.
One of the entries was from Colin Angus (@VictimOfMaths), an alcohol policy modeler in the U.K.:
Twitter discourse is often, er, not great, but if one is in the right communities, there are serendipitous moments where the simple act of posting a creation like this can end up generating an informative thread where Colin answers a question regarding his choices in how the data was presented.
Colin starts off with what I thought was a fundamental posit when discussing how to visualize data:
The first thing to say is that I don't think any dataset has some inherently 'right' type of graph. There are just different graph types which may be more or less effective at highlighting different aspects of the data.
The second is that there is no truly neutral presentation of data. Your choice of graph type, colour, scale, structure and annotations will all influence what message people take away or what patterns people see.
The thread is just the right length and Colin provides some very sound advise throughout. In one of the tweets, he has a screen capture of a section of The Economist’s design principles. The list is short (which is, I believe, a characteristic of good design principles):
Less is more
Intelligence and wit
as is the expository paired with each entry.
I highly suggest digesting (and bookmarking) both the thread and the principles as both should help anyone craft better visualizations.
When one has been staring, daily, at shell prompts as long as I have it can be difficult to accept (or seek out) change. Truth be told, I’ve been a shell prompt minimalist for as long as I can remember, eschewing fancy adornments to ensure optimal interaction on any system.
This year I decided to try out some new, modern offerings in many categories including joining the cool kids by adopting a jazzy new Rust-based, cross-platform shell prompt dubbed Starship, which describes itself as a “minimal, blazing-fast, and infinitely customizable prompt for any shell”, and I can attest that it does not exaggerate.
Besides the fact of it being written in Rust, I found the requirement of a nerd font also quite compelling, as I 💙 ligatures and character graphics in programming contexts, so why not do the same for shell interactions. Here’s my current prompt setup:
current working directory (
escpos2, which is an R package)
the active git branch (
batmansince everyone’s default branch should be
and the language ( 🌈 for R) + current language version (
Modules — components in the prompt giving information based on contextual information from your OS — are at the heart of Starship. For example, Starship knows what to display when it is in an R package directory (like the one above) due to this module configuration:
format = "with [🌈 $version](blue bold) "
There are over 70 modules one can configure, and if a working directory has multiple contexts (like the above example which is both a git repo and R package) they will be displayed together. I’ve been adding module configurations incrementally as I move around various systems.
Starship is fully cross-platform, which means I can avoid the urge to throw my singular personal Windows laptop against the wall whenever I’m forced to drop to the command line to get real things done.
At-a-glance git tree information as well as being reminded of what version of R I’m dealing with has been far more useful than I expected, and I think Starship will be part of my defaults for quite some time.
Having been both a manager and an individual contributor (IC), I’ve been on both sides of a performance review. Most organizations do fairly terrible job providing sound guidance to managers (on how to handle this type of evaluation) or ICs (how to track and articulate all the great stuff they’ve done).
Whether you’re in a good organization where there are frequent performance checkins throughout the year, or a terrible one that shunts said reviews to an end of the year exercise, one key element that can make these events more valuable is if you, as an individual contributor, keep track of what you’ve been up to.
What was the impact?
Who was the customer / who benefited?
Who did you work with?
The last one — level — is missed in most lists and one ICs often neglect to consider when performing tasks. Here’s how Graham defines that element:
In my opinion, this is the most important column. If your organization has a career ladder (if you don’t have one, why not help create one?), you should map everything you do against it. You should be constantly self-evaluating your work — “am I performing at or above the standard that is expected of my job level? Do I need to do something else to perform at the level that is expected of me?”
We live in a highly competitive world where we, as individuals, cannot rely on others — including managers — to look out for our best interests or to provide counsel on one’s career path. Keeping track of that “level” attribute will help you, and your manager, understand your career goals and create opportunities for you to spend increasing amounts of time in work activities that support your next move/promotion.
Graham’s post is concise, with just enough prompts to ensure you have plenty of content for your next checkin.
In a previous roundup:
I mentioned new Russian “dodgy certs”, and today I realized that I didn’t link to the GitHub repo the author created where they’re keeping track of things.
Another issue done and dusted!
Remember, if you choose to interact in the comments, the only rule is kindness. ☮