CTPopup1

I recently started studying Talmud every week with a new chevruta. It's something I've wanted to do for ages and I found an amazing chevruta to do it with and we've been having so much fun. One of the things that we often find ourselves asking as we're studying is “What language is this bit of text in?”

When you're trying to figure out how a word is pronounced and what the conjugation is and the tense and the mood, the language matters a lot. If you're studying the mishna, it's probably rabbinic Hebrew. If you're studying gemara, it's probably Aramaic or Rabbinic Hebrew or Biblical Hebrew however it's not out of the possibility that you could have a Greek loan word thrown in. And if you're in a Rashi commentary, the language is probably Hebrew, but a later Hebrew than rabbinic Hebrew, unless he's quoting something, in which case it might be rabbinic Hebrew or it might be Aramaic. And occasionally when Rashi can't find the right word in Hebrew, he uses German or French written in Hebrew characters too.

And it strikes me that this has a lot of bearing to how we think about building software as part of a cross-functional team.

The many languages of business

When you're writing software, knowing what programming language you're in is helpful, but that's not what I'm talking about. What business mindset are we in? Are we talking product speak? Are we talking C-suite or business owner language? Are we talking sales? Are we talking engineering talk? Are we talking front end engineering or are we talking InfoSec or are we talking about devops?

This influences the literal words we use, whether or not folks understand our jargon and our abbreviations and our acronyms, and it also impacts how we speak and are understood.

I worked on a project where I had a very hard time communicating effectively with the stakeholders. One of the things that I learned was that they wanted optimistic certainty, and I wanted to provide transparent honesty. And so it wasn't helpful for them if I said, I think it will take three days, but there's A and B and C risks and I don't really know.

That didn't help them accomplish their goals and their work. What they wanted to know was, Do I need to communicate with customers that this project will be delayed or not?. Those are very different languages and it's very easy to misunderstand each other if you have such different context.

I think that there is tremendous value in stopping to ask ourselves what language is this conversation happening in?

It's not just one language for one conversation

One of the things that happens in the Talmud is that you switch languages very quickly. Sometimes, you'll have five words in Aramaic, and then you'll have four in biblical Hebrew because suddenly you're quoting the Torah, or you will have two words in Aramaic and then you'll have 10 in Rabbinic Hebrew because now you're quoting a mishna or a baraita.

I think that's true in business as well. What language we're speaking can change very quickly. Throughout a meeting, we might speak many different languages. An engineering leader might spend part of the meeting in leadership-updates speak, thinking about what she needs to tell the sales team and the CEO about the project timeline, and part of the meeting nerding out with the engineers on the gnarly techincal details. Or a conversation dives back and forth between a product view and an engineering view.

What language is this anyways?

When you are studying Talmud, there are certain clues as to the language you're in. The first is there are introductory words that a certain type of phrase is coming.

If you see שנומר, you are getting a biblical quote next. That's what's happening. Even so, you might be getting through something from Psalms or something from Genesis, and those are very different Hebrews, but you are getting something from Biblical Hebrew next. If you see Tanya rabbi so-and-so, there's a good chance that you have some Rabbinic Hebrew coming up, a quote from a mishna or baraita but it's not a guarantee. You might have something about the fact that they taught not a quote from them teaching.

Sometimes you don't have those clue. You have to rely on more subtle clues.

Other times, the clues are really obvious. If there's an absurd amount of אs, just what's even happening? Why are there so many אs? You're definitely in Aramaic. Biblical Hebrew doesn't do that. I once had a chevruta who said, it seems like the rabbis were inspired by the Greeks and how long their words were, so they just kept adding אs, and honestly, I buy it.

Sometimes it's really hard to tell; sometimes there is just not a clear answer and you're kind of left wondering. That's just real life.

But when we can name what language we're in, it gives us a lot more certainty about what we're doing and what's being communicated. And I think that that's true in building a good business, and shipping business value to customers as well. Naming what language we're in helps clarify communication.

Recently, I've had several projects that had very little structure to them, and seemed to drag on forever. It's frustrating for everyone when a story/ticket/etc has been open for days and days, or even weeks and weeks.

For the product owner, it gives them very little visibility into whats going on, and it makes predictability difficult. Product owners and folks in business leadership usually care hugely about predictability. In fact, that is often one of their biggest concerns.

For the developer, it's demoralizing. This story was only 2 points, it was supposed to be easy, and here we are on week 2? What's wrong?

Here are a few strategies I use to turn this problem around:

1. Define exploration vs building Often times, when the story drags on forever, it's because work we thought was well defined, wasn't. When this happens, I recommend breaking out the spike or exploration work, separate from the implementing. Make the original story an exploration or spike (possibly with no points, depending on how your team thinks about story points), and add a note that you will write up follow up stories once you figure out what they are.

2. Break out stories As you figure out the different pieces of the work during the spike, add in stories. Flesh them out fully, because your future self won't remember the context of your three word reminder. These stories should be a much smaller piece of the original, too big story.

3. Break down tasks smaller Once you've added your smaller stories, and you're ready to stop exploring (for now) and start building, break down the steps of your task. By now, having explored, you should have a pretty darn good idea how to build this, so you can get pretty fine grained. Try to make each step something you can accomplish in less than half a day, and ideally more like 2 hours. For my brain, nested lists inside nested lists helps me get to the right granularity.

4. Find meaningful chunks of work and notice that they're done One of the most demoralizing things about the endless story is that you have no sign of progress and your brain doesn't get the “I finished a thing, hooray!” dopamine hit. Many of us need that, and need an extra dose of it, to keep going. Make sure to stop and notice what got done. Check the box, click done, just breath it in. Notice your progress.

5. Merge often To the extent possible, aim to commit to main/prod daily, once you get to building. (After you throw away your spike!) This helps with feeling a meaningful sense of progress and accomplishment, and it keeps you and your teammates in sync. It might, sometimes, need feature flags, and that's a worthwhile investment. Smaller change sets are easier to review, and easier to examine if something breaks.

6. Use an exploration doc for exploring I think more details on this might be an upcoming topic, because I really love my exploration doc format. I write down the question I'm exploring and how I plan to explore it. I take quick notes as I observe things that are interesting. Then I write down the next exploratory question, number it, and repeat, in a running google doc.

I would love feedback on my newsletter, even just a thumbs up, thumbs down. Is this interesting? Would you like to read more about a specific topic? Let me know what you're thinking. You can find me @ctaymor@hachyderm.io or reply to the email.

Recently, I've been working on some Twilio tools for a client. This work requires a number of new skills for me. I want to share a few things I use to learn faster, in case they are useful for you in learning.

1. Speed up your iteration cycles. It's hard to stay focused while you wait if it takes you 3 minutes to verify whether your code worked (much less 30). Your attention will drift, and when you come back to your results, you will have to reload the context. This takes you out of flow which interrupts your learning. It also means you can learn fewer things in the same amount of time. How can you learn something faster?

2. Experiment in small pieces Often, when a domain is new, the whole piece of the puzzle is too big to deal with. It needs to be broken into smaller pieces. Also, those smaller pieces often create faster iteration cycles. I'm a huge fan of writing simple learning code and scripts, to figure something out. That might mean writing a tiny Twilio function that just errors the arguments passed in, a mini bash script, or trying it out in the Rails console. What is the smallest piece you can break this into?

3. Clarify your questions When I'm frustrated when learning, I like to have a very clear question in mind. It helps me stay focused. While less directed exploration also has value, I can get lost in that, and struggle to remember what I was trying to do.

It helps me to answer one question at a time, and write down the other questions that come up as I explore. I often use a journaling method similar to what I lay out in my Getting Unstuck: Using the Scientific Method for Debugging RubyConf talk, writing down an experimental question, a hypothesis, and what I observe in a running doc.

If you don't have a clear first question to start, but a whole jumble of wonderings, that's when I engage in Question Shrinking, as taught to me by Shaun Martin and KK Ong. That's a whole other post (or a series, even). But I'd recommend writing down your questions, and everything you know, on paper or a white board. And then write down the connections between them, the other things you remember you know, and explore, to see what you don't know yet.

1. Write down your mental stack When you're learning, it's easy to get overwhelmed. It helps me to keep a written stack of questions, tasks, and more so they don't use up my working memory. I usually use either physical sticky notes (one note per thought), or the Stickies for Mac app (as just a list). You can then add to your stack, or pop things off your stack as you go.

2. Accept being outside your comfort zone Another thing I learned from Shaun and KK is that learning happens in flow and outside your comfort zone. This is, by definition, uncomfortable but it's required for learning. Try to notice and accept the discomfort, without judgement.

3. Take breaks You need idle time and sleep to process, and form neural connections with the new information when you're learning a lot. Taking an actual break to move my body, or reflect quietly always helps a heck of a lot more than scrolling on my phone (even though I do love scrolling Mastadon or playing Square Valley or Monster Hunter Stories).

Please tell me if this post was helpful to you, if you learned something new, if it was boring, whatever. I'd love to hear from you, even a thumbs up or thumbs down. Or even better, share your learning-new-things tips!

A 6 week popup blog on software – Popup 1 Inspired by Nat at SimplerMachines and Paolo Amoroso's invitation to join #BringBackBlogging, I am trying a pop up blog.

I love Nat's pop up blogs and Seasons of blogging. Every one has been a pleasure to read. Especially when the seasons or pop ups are short, I want to read it, and the tasty tidbit leaves me wanting more.

I've been enjoying Mastadon greatly. As many have said, it feels a bit like the old days of the internet, in a good way. One of the great things about the old days was blogs. Long form writing by so many people, with such varied interests. So I was inspired by the BringBackBlogging challenge to give it a try.

Here's what you can expect: * I will blog 1-2 times a week here, from Jan 19 to March 10, 2023. * After March 10, 2023 this first blog popup will wrap up. If you have subscribed via RSS, you won't get more posts. If you subscribed via email, the email list will be deleted. It's a pop up that goes “poof” when it's done. * I will be writing about software, defined very broadly. It might be digging into a specific piece of software, or musings on process, a review of a book that influenced my software development thinking, or thoughts on working as an independent software consultant. * Posts will be longer than a Toot and less than 5 minutes to read.

If you enjoy my writing, please share it and let me know! If you have feedback, or want to talk more about it, please say hi at @ctaymor@hachyderm.io. I would LOVE to hear your thoughts.