just discovered the honeycomb pollinators #chART group. omg, how did i not know about this? this one is "we sent a bunch of emails from 4am-5am, the resulting load on the system" ππ
and "oh hey, one of our queries was doing a full table scan instead of using an index because we were filtering based on UPPER(id) and indexing on id"
this one isn't so much art but it cracked me up. "load tests vs production: An Enterprise Customer Story"
Memory Usage: A Love Story
"Ask Your Doctor If An Index Might Be Right For You"
there's a whole series here entitled "Spot The Configuration Change"... i'm cracking up
"Spot the Configuration Change", postgres edition
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
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.
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.
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
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.