Charity Majors Profile picture
Sep 14, 2020 β€’ 11 tweets β€’ 3 min read β€’ Read on X
Updated definition:

πŸ“‰ Monitoring is for running and understanding other people's code (aka "your infrastructure")

πŸ“ˆ Observability is for running and understanding *your* code -- the code you write, change and ship every day; the code that solves your core business problems.
Questions monitoring tools (like datadog, signalfx) can answer:

* When will my disk fill up?
* Am I running out of capacity in $(cluster)?
* Did the % free memory drop after my last deploy?
* What is the avg, 90th, 99th percentile latency per service?
Questions observability tools (like honeycomb, lightstep) can answer:

* What (1..many) things do all the errors in that spike have in common?
* How many exports per second is $app doing, and how large are they, and how does this compare to the average export size in kB?
* Break down by app and sort by export size: what are your top 3 export users, and what is the sum of their total throughput compared to the overall throughput?
* Are the errors evenly distributed across workers, AZs, instance types, software versions, build_id versions, shards?
* Are the timeouts happening for all our users, or only the test users, or only our top users by write volume, etc?
* For all of the deliveries that failed over a specified time period, what are the top three reasons they failed, and what % of failures were from a single app?
Running infrastructure means running black boxes. You may have some insight into them (god i hope so) but you don't have the ability to tweak their instrumentation, and you certainly aren't shipping code changes every day.

Infrastructure code gets package-upgraded, rarely.
And when it comes to monitoring and understanding your infrastructure, metrics-based monitoring tools that let you understand performance in aggregate are the tool for the job.

Esp when workloads are high throughput with little differentiation (routers, etc) metrics are king.
When it comes to aligning developer perspective with user experience to provide core business value, though: event-based observability tools are the only way to get at the information you need.

You need the flexibility and precision of a scalpel, not an axe.
To see an expert yet beginner-friendly (and entertaining!) intro to observability for business problems, check out this talk from @seebails -- observe2020.io/2020/03/chris-…
And to continue my killjoy track record of stiffly caring about technical definitions for technical terms, if you'd like to read more, please read my three year history of observability in the software domain. aka how we got here and where we're going:

thenewstack.io/observability-…
annnd -- should you be in the mood to build an o11y tool in-house, or want to argue with me about why datadog and signalfx and their ilk are definitely not observability tools (or about what constitutes an o11y tool), do read this:

honeycomb.io/blog/so-you-wa…

β€’ β€’ β€’

Missing some Tweet in this thread? You can try to force a refresh
γ€€

Keep Current with Charity Majors

Charity Majors Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @mipsytipsy

Apr 28
In 2023 we saw several rounds of quality conversation around engineering productivity, thanks to McKinsey, @GergelyOrosz and @KentBeck and others.

It moved the industry forwards. πŸ™Œ But it also felt fairly inside baseball to me. Deeply technical, lots of metrics.
It felt, to me, like those participating were stepping very cautiously around a few of the third rails Jaana just tripped over. (πŸ’œ)

"Work-life balance"
"Working hard vs working smart"
"Meritocracy"

The intersection of company tech cultures and expectations and performance.
These are hard, complicated topics, and there are some very good reasons for speaking carefully. People can pick up a sentence and run in the wrong direction with it, and do a lot of damage.

I have abandoned god only knows how many drafts on this topic, for that reason.
Read 26 tweets
Apr 22
The question is, how can you interview and screen for engineers who care about the business and want to help build it, engineers who respect sales, marketing and other functions as their peers and equals?

It's a great question!! I have ideas, but would love to hear from others.
I said "question", but there are actually two: 1) how to hire engineers who are motivated by solving business problems and 2) aren't engineering supremacists.

They are not *unrelated*, but they are different things.charity.wtf/2022/01/20/how…
Some things you can ask to tease out these attitudes are,

* when was the last time you paired with someone outside engineering? Outside R&D?

* what did you learn? How did it change your perspective or the way you do your job, or did it?
Read 12 tweets
Mar 22
Ooooohhh boy, this is a terrific question. I have written two closely related pieces,

* for engineers interviewing at a new company, on how to sniff out bad management culture:

* how to tell if the co is rotten on the inside: charity.wtf/2021/02/19/que…
charity.wtf/2022/01/29/how…
But both of those were written from the perspective of the engineer/interviewee, not the interviewer. The dynamic is different, for sure. πŸ€”

I would probably start by asking them why they became a manager, why they enjoy the job (if they do). (Softballs)
* what was the most demoralizing week of your management career to date, and why? What would it take for you to give up management entirely?

* I would probe their familiarity with our tech stack, and ask what they do to stay sharp and up to date technically.
Read 7 tweets
Feb 14
Pro tip: any time you see someone confidently opining on what all good CTOs know or do, it is ✨bullshit✨

There is no stock template for CTO, or default set of expectations or responsibilities. It stands alone among the C-levels in that good ones are all over the freaking map.
This may not hold true for publicly traded companies. But in my experience, a good CTO can be:

* over all of R&D
* over engineering, like a VP eng
* like a principal eng or architect
* team lead for special projects
* a great senior programmer

(continued... πŸ‘‰)
A CTO can also be:

* a great communicator and popularizer
* on the road as a devrel
* a field CTO, whose authority opens doors to big customers
* a product visionary who sweats the details
* more of a cofounder than technical contributor, sharing "company-running" duties w/CEO
Read 12 tweets
Jan 22
Yeah, this is a fair caveat. If you're already a decent senior engineer and manager, it's kind of possible to split your attention between managing a small team and writing code.

But you aren't going to improve at either skill set. Those cycles get devoured by context switching.
Tech lead managers ("TLMs") are a mistake we make over and over in this industry. I've written about this a bit, but the definitive post was written by @Lethain.



Instead of being the best of both worlds, TLMs are poorly equipped to do either.lethain.com/tech-lead-mana…
(I will now brace for complaints. πŸ™ƒ)

This is one of those topics that people really get worked up about. There are roughly two groups:

1) TLMs, or EMs whose identity is tied up in also being TL

2) Engineers who only respect their EM to the extent that they write great code
Read 7 tweets
Jan 8
My coworker @suchwinston wrote a terrific piece on burnout before the break:

There's a reason why burnout and work/life balance are such evergreen topics, and it's not actually because the world is so terribly harsh and everyone is criminally overworked.honeycomb.io/blog/product-m…
Just to be clear: some places *are* awful, and some people *are* criminally overworked. But burnout and work/life balance are an issue for everyone, not just those people.

I think this is bc there is no real "solution". Each of us has to find and maintain our own equilibrium.
It takes a lot of hard work to become good at technology, and a lot more hard work to maintain your edge in a fast-changing industry.

I don't know of anyone for whom this is _easy_. None of this is remotely natural, from an evolutionary perspective. πŸ’
Read 12 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(