I’ve historically been a pretty big fan of Grafana, I’ve advocated for the cloud solution at more than one company.
But it seems like business development has utterly hijacked the experience.
The flow you want out of the box is Prometheus, Loki, and Tempo with one button that drops you the config for grafana-agent (now alloy which seems good technically but brings a whole new config language with some truly insane discoverability problems) that makes graphs on screens, you build up from there.
But these days everything is some complicated co-sell, up-sell, click farming hedge maze through 90 kinds of cloud vendor rip-off half baked thing.
Graphs, logs, traces out of the box. Put all the works with Snowflake shit behind an icon. A small one.
Not OP, but looked at doing grafana self hosted for similar reasons. The tooling is too spread out across different installables, the common golden signals and other monitoring metrics have a high learning curve / cliff more like it, and there's not good enough documentation to cover the user from "I want to do a synthetics test on a service to see if it is alive and show the results of that test in a graph"...a journey like that involves 4+ different tools.
DD was just easier to use for everybody, has lots of useful baked-in things we liked to use (apdex scores), and was intuitive enough that non-devs could design their own dashboards. We also found it way easier to collect metrics, traces, and other things.
FWIW none of these things are insurmountable and I suspect you'll eventually reach parity. Datadog lost our business for two reasons 1) Lack of billing transparency and 2) an incompetent account rep who managed to piss off our finance department while also embarrassing our CTO. And to be clear, while we aren't a "whale" our spend was over $6M/yr with Datadog - and the CTO along with the rest of eng leadership were all huge DD fanboys and yet they still managed to burn that bridge to the point where we'll never go back.
What happened to the girl you had a crush on? Did your effort to distance yourself from computers bear any fruit in any way? Do you have any regrets with that part of your story?
Girl: she moved away at the end of grade 6 (I think to the US) and this was in 1992 before the internet so that was the end of that.
Distancing from computers and regrets: worked well, and no regrets. Had long hair and listened exclusively to heavy metal and almost all of my friends in high school were girls. I remember the computer guys where we lived tended to just hang out in the computer lab and not a girl to be seen in there. (I'm sure they got fantastic jobs early on, of course)
Though in 2015 when our team at the pipeline company got packaged out I probably would have properly learned to code if I had gone straight with F# instead of Python and then trying everything else until I ran out of time and had to find a job instead. Or Rust though version 1.0 would have just come out then and not sure if there would have been enough resources to pull through.
I'm amazed that the author doesn't recommend Pair-programming as one of the techniques to avoid "Doing too much before looping in others"
He mentions:
> an engineer on a project should never go more than a week without showing something, and usually it should be more like a day
But in my experience by pairing you can shorten this feedback loop to seconds.
A few other people have commented about pairing: It's clear people have different preferences and that it's wise to use pairing at the right moments, but it still seems a glaring omission from the article to me.
I’ve worked my whole career in the UK (7 years software eng, plus a bit in other jobs). Sounds from your comment like you’ve had better experiences in other countries. Is that right? Which ones, and how?
Thanks for the comments - they're already very useful.
To explain our process:
We have a single designer, and when designs are reviewed it's usually by one of the devs
In the past we've done wireframes (Sketch) and interactive prototypes (InVision)
We were frustrated that:
1. Lots of issues didn't surface until we started coding, when a raft of problems/edgecases would appear.
2. It was too easy to ignore existing UI components/css, so that each design featured new component styles and css.
For approx the last month our designer branches from `master` and hacks on top of that to create designs. He then creates a PR for design-review, alongside a spec with some screenshots in Dropbox Paper.
Some advantages of this:
1. We get visual diffs from Percy, so we can see what's changed easily
2. We get versioning more easily built into designs (via git)
Then just before development we'll break a story down into tasks / subtasks and log those into JIRA for development.
We have trouble with:
1. Letting the designer make changes once the subtasks are created and development has started (devs sometimes chasing a 'moving-target' spec)
2. Design not knowing the current state of development
