DEV Community: Cathrine

I hate making dashboards #2

Cathrine — Mon, 09 Oct 2023 23:01:23 +0000

Another reason why I hate building dashboards — it's an invisible job. Careerwise a dashboard is a black hole. It consumes loads of you time and gives nothing back, just grows to be an even bigger problem.

Problem 2: How hard it can be

You know that feeling, when you decide to support your findings with a chart and get from a manager "Oh, that's a nice chart, we should have it in our dashboard". Instant regret.

Am I being a diva? I mean, how hard it can be, you basically have the whole thing done, all you need is just to press a magical button "execute daily".

Not quite. And there are three reasons why it's not that simple.

1/

Unlike most of developers, analysts write a lot of disposable single-use code. It is not meant to be rerun unsupervised, moreover quite often it's not even possible to rerun it in one piece. We take shortcuts, we filter out data using very case-specific signs, we even copypaste when no one's around. And it's not us being bad coders, it's the specifics of this type of job.

To make that frivolous code run day by day, with seamless connection through dates, with general indicators for dividing and filtering data (that stay somewhat sustainable through project development) — that's a whole another task.

2/

Data delivery is not that reliable. Let's face it: data for product analytics is not vital for service being up and running, so it gets fucked up relatively often. Delays, downtimes, glitches, and "Ooopsy, we forgot to add that logging you asked for in a new release" is a daily struggle.

So, each chart needs a life-support system: workarounds for all kinds of glitches and delays, automated recalculations backwards and informative alerts for failures.

3/

If you have an interactive dashboard, every new chart needs to be prepared the same way. Sometimes it's a few extra lines of code attaching the same hierarchy for a charted feature. Sometimes it's a logical puzzle of trying to squeeze new data into the old frame. And a cherry on top: every new chart slows down rendering time for the whole dashboard. Sometimes — to the level of the dashboard becoming unusable.

So, adjusting dashboard to include new charts is not just squeezing in a new widget. It takes time and taste, it requires communicating with users of that dashboard, it implies rebuilding it and even making major dashboard redesigns when needed.

How to deal

The problem is not the workload itself. The problem is a significant underestimation of the resource it takes to run a dashboard.

So the first thing I highly recommend here is learning how to communicate clearly. As simple as it seems, people don't do it that often. You can say something like "I can add that chart to a dashboard. It would take me 2 days to make it ready for an unsupervised runs, and one more day to configure all the adjacent parts. Also I assume it would take another hour per month for maintenance"

And that it's your manager's call to decide, if that chart is worth it.

Second thing is reducing the amount of this invisible job, by building your code bound and self-sustainable. My must-have tricks are check-and-sleep cycles for all the data sources and recalculation backwards for all missing datapoints. Also I always use common precalculated and groomed data instead of raw one. It allows to solve every new emerging problem once and for all.

Talk to me

Do dashboards eat up your time? What are your pro tips on how to avoid it? Let's discuss it and next time we'll talk about the most irritating issue that comes along with dashboards.

I hate making dashboards #1

Cathrine — Wed, 04 Oct 2023 08:34:59 +0000

Don't get me wrong. I appreciate visual materials, I think that automatisation of repetitive tasks is a must and I strongly recommend you to cover your production servers with all kinds of monitors.

But making dashboards for top management was my most hateful job as a product analyst. And I can tell you exactly what's wrong with it, and how you can navigate through it, if you absolutely have to.

Problem 1: It's not what it looks like

Let's say that we want to see how many users we get every day. What can be easier, right? It's just all unique users' ids from daily log. Or is it?

Well, not quite. What about those people who don't allow cookies' usage and they don't have an id? What about those people who have some security add-ons installed in their browser, who have multiple different ids throughout a day? What about bots? Search engine robots? People with browser, that downloads all the tabs in background at every restart?

So, you make workarounds for that issues, you filter out UserAgents for search engines, you filter out too frequent requests for bots, etc. The resulting chart doesn't show the number of users, it shows the next best thing — estimation for that number.

The thing about data is that it never stays the same (unlike your shipped code). Maybe there is a release of new GDPR guidelines, maybe an intern dropped a line of code which was assigning an id to a user. One way or another, the day would come when the data changes and your chart immediately gets messed up.

How to deal with it

Stick to the most unambiguous values that you can find. It's fine to make chart of the "number of successful billing transactions" or "number of clicks on an ad banner".
Keep all calculations for the charts as simple as possible. Remember that every additional level of logic that you add to your code, would double the trouble in a long run
You don't have to stick to the data available at the moment. Talk to the dev team, come up with extra events to log, which will help you to avoid unnecessary complexity in your algorithm.
When there's no way to avoid having the gap between log events and high-level data to show on a chart, make it very clear, that it's not some magical "true value". That it's an estimation, and it will inevitably get messed up. Not because you didn't see it coming, but because the management asked for too abstract of a value, that doesn't have an unambiguous representation in logs.

What's problem #2? We'll talk about it next time.

Dealing with Data

Cathrine — Sat, 30 Sep 2023 20:24:21 +0000

Hello, everybody!

My name is Catherine and I'm a very opinionated data specialist.

In my 15 years of work experience I've seen data that comes in all shapes and flavours:

search engine databases,
web logs,
app logs,
geo tracking,
cars' engine sensors,
images,
geological models,
food nutrition values,
custom oil-barrel sensors made by a research institute deep in Siberia

What is even more important, I worked in teams that come in different shapes and flavours — from tech-giant company with 10K+ employees to 2-people startup. Problems that I saw as a standalone issue in my first project, I can see now as a global pattern that many teams are facing and replicating. And I'm dying to talk about them.

So, here to come: personal observations, practical tips&tricks, career-building edifications and debatable concerns. Welcome onboard, and I hope you would join into the conversation.