A selection of paintings by Daliah L. Ammar (previously featured here). More images below.
aka the bow-wow barrier. my coping mechanisms are top notch *thumbsup*
Tried, tested and true.
Wednesday Book Reviews (on Thursday, because I'm dumb):
Two Cheers for Anarchism (Arthur) This was a fun little introduction to ideas of anarchism. It’s a short book, and I don’t have too much to say about it, other than that I’m sympathetic to the idea of having as much as possible accomplished by free association between voluntary actors. Whether it’d work for a large of people, I haven’t got a clue.
Calvin and Hobbes (Watterson) You may have noticed my artwork’s gotten a little more… painterly? I’m not sure the right word. But, I wasn’t sent this book and decided to read every page. It’s interesting to see Watterson’s early style - he’s still finding his way, and doesn’t yet have that calligraphic style he eventually mastered. Of course, it’s still ten times better than me, but you can see where he’s still figuring out how to do things.
We Can Build You (Dick) This book is all over the place, and it is very hard to follow. If I were more concerned about the appearance of intelligence, I would call it “post-modern.” As it is, I just found it confusing. What *is* interesting, is that it has a lot of the motifs that’d later appear in Dick’s magnum opus, Do Androids Dream of Electric Sheep, including the concern over whether oneself is in-human, and the emotional tests used to detect machines. It even has the motif of the spider that’s so crucial in that later work. But, as a book alone, it’s not solid gold. It’s almost like a dream about that later book - a sort of creative fluid that needs to congeal into something more graspable.
Genius at Play (Roberts) I just absolutely adored this biography of John Conway, the great mathematician. It’s been a while since I read a great memoir of a scientists. They’re typically written without much love or understanding of the work. The other of this book had many many interviews with Conway, in addition to doing an immense amount of research. It’s just delightful, and I recommend it.
Feynman (Ottaviani and Mirick) This comic book is a sort of dreamy stringing together of some of the famous Feynman stories and lectures. I definitely enjoyed reading it, though I found it hard to tell if the comic book format added to that. It also (necessarily, but…) ends up painting a picture of Feynman as he saw himself, and mythologized himself, for better and worse. I did really enjoy it, though.
Call the Midwife: Farewell to the East End (Worth) Well, the first book in this series was great, the second was solid, and this one ends up somewhere in between. It’s really a return to more stories of midwifery, and this is facilitated by using stories from other people alive at the time. I don’t know to what extent they are fictionalized, and I frankly don’t care. They’re great little stories. Worth also takes a strong stance for legal abortion, which is bolstered by horrifically detailed tales of what abortions were like in her time, when performed in secret by women with little to no medical background, using literally medieval methods.
Asking good questions is a super important skill when writing software. I’ve gotten way better at it over the years (to the extent that it’s something my coworkers comment on a lot). Here are a few guidelines that have worked well for me!
To start out – I’m actually kind of a big believer in asking dumb questions or questions that aren’t “good”. I ask people kind of dumb questions all the time, questions that I could have answered with Google or by searching our codebase. I mostly try not to, but sometimes I do it anyway and I don’t think it’s the end of the world.
So this list of strategies isn’t about “here are all the things you have to do before asking a question, otherwise you are a bad person and should feel bad, but rather “here are some things that have helped me ask better questions and get the answers I want!”.
Our goal is going to be to ask questions about technical concepts that are easy to answer. I often have somebody with me who has a bunch of knowledge that I’d like to know too, but they don’t always know exactly how to explain it to me in the best way.
If I ask a good series of questions, then I can help the person explain what they know to me efficiently and guide them to telling me the stuff I’m interested in knowing. So let’s talk about how to do that!
This is one of my favorite question-asking techniques! This kind of question basically takes the form
For example, I was talking to someone (a really excellent question asker) about networking recently! They stated “so, what I understand here is that there’s some chain of recursive dns servers…”. That was not correct! There is actually no chain of recursive DNS servers. (when you talk to a recursive DNS server there is only 1 recursive server involved) So them saying their understanding so far made it easy for us to clarify how it actually works.
I was interested in rkt a while back, and I didn’t understand why rkt took up so much more disk space than Docker when running containers.
“Why does rkt use more disk space than Docker” didn’t feel like the right question
though – I understood more or less how the code worked, but I didn’t
understand why they wrote the code that way. So I wrote this question to the
rkt-dev mailing list:
Why does rkt store container images differently from Docker?.
The answer I got was super super helpful, exactly what I was looking for. It took me quite a while to formulate the question in a way that I was happy with, and I’m happy I took the time because it made me understand what was happening a lot better.
Stating your understanding is not at all easy (it takes time to think about what you know and clarify your thoughts!!) but it works really well and it makes it a lot easier for the person you’re asking to help you.
A lot of the questions I have start out kind of vague, like “How do SQL joins work?”. That question isn’t awesome, because there are a lot of different parts of how joins work! How is the person even supposed to know what I’m interested in learning?
I like to ask questions where the answer is a straightforward fact. For example, in our SQL joins example, some questions with facts for answers might be:
When I ask super specific questions like this, the person I’m asking doesn’t always know the answer (which is fine!!) but at least they understand the kind of question I’m interested in – like, I’m obviously not interested in knowing how to use a join, I want to understand something about the implementation details and the algorithms.
Often when someone is explaining something to me, they’ll say something that I don’t understand. For example, someone might be explaining something about databases to me and say “well, we use optimistic locking with MySQL, and so…”. I have no idea what “optimistic locking” is. So that would be a good time to ask! :)
Being able to stop someone and say “hey, what does that mean?” is a super important skill. I think of it as being one of the properties of a confident engineer and an awesome thing to grow into. I see a lot of senior engineers who frequently ask for clarifications – I think when you’re more confident in your skills, this gets easier.
The more I do this, the more comfortable I feel asking someone to clarify. in fact, if someone doesn’t ask me for clarifications when I’m explaining something, I worry that they’re not really listening!
This also creates space for the question answerer to admit when they’ve reached the end of their knowledge! Very frequently when I’m asking someone questions, I’ll ask something that they don’t know. People I ask are usually really good at saying “nope, I don’t know that!”
When I started at my current job, I started on the data team. When I started looking at what my new job entailed, there were all these words! Hadoop, Scalding, Hive, Impala, HDFS, zoolander, and more. I had maybe heard of Hadoop before but I didn’t know what basically any of these words meant. Some of the words were internal projects, some of them were open source projects. So I started just by asking people to help me understand what each of the terms meant and the relationships between them. Some kinds of questions I might have asked:
I actually wrote a ‘dictionary’ of all the terms because there were so many of them, and understanding what all the terms meant really helped me orient myself and ask better questions later on.
When I was typing up those SQL questions above, I typed “how are sql joins implemented” into Google. I clicked some links, saw “oh, I see, sometimes there is sorting, sometimes there are hash joins, I’ve heard about those”, and then wrote down some more specific questions I had. Googling a little first helped me write slightly better questions!
That said, I think people sometimes harp too much on “never ask a question without Googling it first” – sometimes I’ll be at lunch with someone and I’ll be curious about their work, and I’ll ask them some kind of basic questions about it. This is totally fine!
But doing research is really useful, and it’s actually really fun to be able to do enough research to come up with a set of awesome questions.
I’m mostly talking here about asking your coworkers questions, since that’s where I spend most of my time.
Some calculations I try to make when asking my coworkers questions are:
I don’t always get this right, but it’s been helpful for me to think about these things.
Also, I usually spend more time asking people who I’m closer to questions – there are people who I talk to almost every day, and I can generally ask them questions easily because they have a lot of context about what I’m working on and can easily give me a helpful answer.
How to ask questions the smart way by ESR is a popular and pretty hostile document (it starts out poorly with statements like ‘We call people like this “losers”’). It’s about asking questions to strangers on the internet. Asking strangers on the internet questions is a super useful skill and can get you really useful information, but it’s also the “hard mode” of asking questions. The person you’re talking to knows very little about your situation, so it helps to be proportionally more careful about stating what exactly you want to know. I don’t like ESR’s document at all but it has some useful things to say. The “How To Answer Questions in a Helpful Way” section is actually really excellent.
A more advanced form of question asking is asking questions to reveal hidden assumptions or knowledge. This kind of question actually has two purposes – first, to get the answers (there is probably information one person has that other people don’t!) but also to point out that there is some hidden information, and that sharing it is useful.
The “The Art of Asking Questions” section of the Etsy’s Debriefing Facilitation Guide is a really excellent introduction to this, in the context of discussing an incident that has happened. Here are a few of the questions from that guide:
“What things do you look for when you suspect this type of failure happened?”
“How did you judge that this situation was ‘normal?”
How did you know that the database was down?
How did you know that was the team you needed to page?
These kinds of questions (that seem pretty basic, but are not actually obvious) are especially powerful when someone who’s in a position of some authority asks them. I really like it when a manager / senior engineer asks a basic but important question like “how did you know the database was down?” because it creates space for less-senior people to ask the same kinds of questions later.
One of my favorite parts of André Arko’s great How to Contribute to Open Source post is where he says
Now that you’ve read all the issues and pull requests, start to watch for questions that you can answer. It won’t take too long before you notice that someone is asking a question that’s been answered before, or that’s answered in the docs that you just read. Answer the questions you know how to answer.
If you’re ramping up on a new project, answering questions from people who are learning the stuff you just learned can be a really awesome way to solidify your knowledge. Whenever I answer a question about a new topic for the first time I always feel like “omg, what if I answer their question wrong, omg”. But usually I can answer their question correctly, and then I come away feeling awesome and like I understand the subject better!
Good questions can be a great contribution to a community! I asked a bunch of questions about CDNs a while back on twitter and wrote up the answers in CDNs aren’t just for caching. A lot of people told me they really liked that blog post, and I think that me asking those questions helped a lot of people, not just me.
A lot of people really like answering questions! I think it’s important to think of good questions as an awesome thing that you can do to add to the conversation, not just “ask good questions so that people are only a little annoyed instead of VERY annoyed”.
Thanks to Charity Majors for reminding me that I have something to say about asking questions, and to Jeff Fowler & Dan Puttick for talking about this with me!
kids these days with their wing-wangs, beep-bop and their hoop moop scadoops!
happy awkward gift opening time!