Beyond Writing Code

Tag: learning

  • Where to start

    Where to start

    Many of my blog posts start as a response to something I see online. I start typing away in a comment box, and I soon realize either:

    • I’m going to go way over the character limit
    • I’m going to want to reuse this

    Or both. Today, definitely both.

    Someone in the LeadDev community recently posted this:

    I’m a tech lead / staff engineer (20+ years in the industry). I’m quite technical, I was an engineer… I’m kind of hitting a ceiling and I’m looking at what I could learn next.

    This person considered a number of different educational or certificate programs including some technical ones, but added:

    but I feel I need to learn leadership skills, or find a blend between technical and leadership. Any idea or inputs for me?

    Well. Good to know that there’s demand for the book that I’m just starting to write! But I also can’t write an entire book in response to a question on Slack. “Hang on about a year and a half and I’ll have something for you…”

    “Hang on about a year and a half,” she said. Photo by VANDER FILMS on Unsplash

    So let’s boil this down to some concrete steps that worked for me.

    Talk to your boss

    If you have a supportive manager, that might be a good place to start. Your manager may be able to give you some feedback (knowing your existing skills and strengths) and advice (knowing what opportunities there might be at the company).

    Take on a challenge

    You might look for a new assignment within your role, or even a new role entirely, that challenges you in new ways. Leverage your existing skills to show why you are ready to take on something that might at first seem to others (or to you!) like something above your level. “My experience creating mid-level strategies will be useful on this project where I would gain additional experience [doing xyz]…”

    And don’t sell your current skills short! You don’t need a people-manager title to be a leader.

    Look for a mentor

    Would it help to have a mentor – someone (who isn’t in your reporting chain) to turn to for advice on leadership challenges, who might help you get more visibility into how leadership works at your organization, who may be able to nudge you in the right direction?

    I wrote about some of my experiences finding and working with my mentors here: Choosing a mentor. Note the distinction between “mentor” and “sponsor.”

    Provide guidance to others

    You could also be a mentor, but there are other ways you can offer guidance to others beyond a formal mentoring relationship:

    • Responding to requests for help from developers who are stuck
    • Presenting or doing a Q&A session on a topic you know that others may not (e.g., the architecture of a solution you worked on, or a new technology you’ve tried)
    • Documenting a tricky process to make it easier for the next person to go through it, or breaking a confusing topic down to make it easier to understand

    Study the leaders around you

    • Whose leadership style do you admire? Why?
    • Who seems successful as a leader in your organization? Who has the respect of your peers, of their peers?
    • Who is “leading without authority”? They are clearly a leader, but they don’t have the title or rank perhaps you might expect.
    • Are any of these people approachable?

    Books I recommend

    I’ve read a lot of enjoyable books, but here are a few that were not just good reading but which actually changed how I think.

    I’m in the process of reading The Staff Engineer’s Path, by Tanya Reilly – but recommending that in LeadDev might be like recommending The Phoenix Project in the DevOps community – something that people have read already!

    Formal training?

    I’ve looked at a number of academic-type programs in leadership, like certificates from various universities, but I’ve never been able to bring myself to spend the money on them (some are five figures, ouch). I’m more of a fan of getting my training in the work setting, where I can get paid to learn as I go.

    One certification I’ve considered is Gary Gruver’s Engineering the Digital Transformation, and I did at one point buy the course material for it… I just haven’t had the chance yet to go through it. I would read Gruver’s book by the same name first, though, which will give you a good idea of what ground the training would cover. (It’s also a great book.)

    That’s a start. I can never tell how obvious (or not) some of these things are to others who have been in the field a long time, so I’d love to know if things on this list are helpful to you. I’ll also keep updating this as I think of new items that belong on the list.

    Good luck on your career journey! (And do sign up for my mailing list if you’d like updates on the book.)

  • Language learning

    Language learning

    My Romanian coworkers were impressed when I started learning Romanian. I’d say “bună” (hello), complete with the ă, and they’d be shocked by even this basic effort.

    What confused me, though: several of them insisted that Romanian was “hard”. I wasn’t sure at first how vehemently to disagree. I think of English as being a hard language to learn, partly because its mixed ancestry makes it fail to be consistent in its behavior. Take through, tough, dough, cough, plough, and thought, for example. Six different ways to say “ough” already.

    Blocks with letters, numbers, and symbols carved into them - in reverse, for printing
    Photo by Bruno Martins on Unsplash

    It could be that I just have an advantage here. Romanian is, no surprise from the name, a romance language, as are French and Spanish. I studied French for 5 years, Spanish for about a year, and I have a smattering of German as well.

    After about a year of Romanian, I recently switched to Haitian Creole (Kreyòl Ayisyen). Kreyòl is especially fun for someone with a background in French, because so many of the words are similar in pronunciation but different in spelling. Fwomaj, for example (fromage in French and cheese in English).

    And then the other day, out of curiosity, I tried a bit of Polish. I am about 50% Polish in ancestry, after all. My grandfather would mutter a few numbers in Polish now and then when playing cards.

    Jestem kobietą, says Duolingo. Uh oh. We’re on familiar territory with jestem (I am), but we’re already in a whole new place with kobietą (a woman). It didn’t get easier from there.

    And that’s still a language with a familiar-ish writing system. I did dip my toe into Hindi on Duolingo for like… two days. In that time, we’re nowhere near using words, we’re just getting the sounds of a few characters down. I gave up because it was just too challenging for me to see the differences between symbols on my tiny phone screen.

    Considering all that, then, Romanian might have been one of the easiest possible choices for me. It uses a mostly familiar alphabet. The pronunciation system is one-and-done: learn the full set and you’ve got pretty much the entire language (no “six ways to say -ough”). A lot of the grammatical concepts and words are familiar to me from either French or Spanish.

    I have gone back to Kreyòl for now. Here’s one thing that’s blowing my mind about Kreyòl at the moment:

    mwen manje – I eat
    ou manje – you eat
    li manje – he/she eats
    nou manje – we eat
    yo manje – they eat

    Uhh. I was just starting to get used to Romanian’s ability (like Spanish) to drop pronouns and know who we’re talking about by how the verb is conjugated. Completely the opposite here!

    I love seeing stuff like that.

  • The dangers of “who” and “why”: post-incident reviews

    The dangers of “who” and “why”: post-incident reviews

    Originally posted 23 September 2023 on Medium.

    Five valuable lessons, including one that really threw me for a loop when I read it.

    In one of his LinkedIn posts, Jeff Gallimore posted some thoughts about retrospectives and post-incident reviews:

    Just a PSA and periodic reminder about things to keep in mind when conducting retrospectives and post-incident reviews.

    1. No one comes to work to do a bad job.
    2. Everyone is doing the best they can given the information they have at the time.
    3. There is no single root cause. There are multiple contributing factors.
    4. Counterfactual thinking (i.e., “I/We should have done…”) isn’t productive.
    5. Leading with “How”, “What”, and “Tell me more about…” is more constructive than “Why” and certainly “Who”.

    Psychological safety. Learning. Generative culture.

    Now, the first four reminders are important, and I’ve been getting better at catching myself as the years go on. But that fifth one was a new one for me, and I’ll admit, it stung a bit when I read it, because I often ask why and who.

    A dark hallway with a large glowing question mark on the wall at the end.
    My image search here was for “investigation”… this felt about right. Photo by Emily Morter on Unsplash

    Asking “who”

    I have no intention of assigning blame. I don’t find the “blame game” useful. Usually, I’m not trying to exonerate myself or my team, although I can admit to there being a little bit of motivation to do that. Mostly, when I’m asking “who” or “why” questions, I’m trying understand what happened so we can figure out what needs to be addressed. Specifically, if I’m trying to find out who was involved, it’s only because I want to know what they were experiencing in that moment. It seems like only someone who was there can truly report on what was happening at the time.

    That said, I’ve had people refuse to tell me who did something. At the time, this was frustrating. My thought was: how can I prevent this problem from happening again if I can’t even talk to the person involved to find out what was going on?

    Just reading that thought back to myself, though, raises a good counter-argument: why does it need to be me who finds out what happened and figures out how to prevent it?

    If you’re guessing that I’m thinking of a specific instance, you’re correct. In this scenario, the team affected (mine) and the team that appeared to have caused the problem had a history of conflict. Trust was low on both sides.

    I can only guess that when they saw someone asking “who did this,” they were motivated to protect one of their own from possible criticism. I might have believed that I would interview that person without blaming and shaming, seeking only to understand and to help. But I hadn’t established that trust with the other team, so they had no reason to share that belief. It makes sense that asking “who” would put them on the defensive. Not helpful.

    Could I have asked “why” instead? Would that have been better?

    Asking “why”

    Consider this scenario: A problem was caused (at least in part, see Jeff’s point #3 above) by someone doing action Z. Let’s forget about who this person is. Shall we ask instead: why did this person do Z?

    Let’s start by assuming that whoever did Z was doing the best they could with what they had (see Jeff’s points 1 and 2 above). They didn’t come to work intending to cause a problem. Maybe they:

    • truly believed Z was correct (or that they were doing it in the correct way)
    • did Z without even realizing they were doing it
    • did good thing Y that in turn set off Z unexpectedly
    • did Z believing it WAS good thing Y
    • knew Z was trouble, but they believed they had to do it
    • didn’t actually do Z at all

    The list could go on and on. Then behind those things there are often other layers: overworked operator, lookalike buttons, alarm fatigue, things changing without notice, culture of fear, information not flowing as expected.

    Each of these suggests a different strategy for preventing this from happening again. Maybe someone needs information, training, or just rest. Maybe a misunderstanding needs to be cleared up. Maybe some easily confused things need to be clarified and disambiguated. Maybe speaking up needs to be made safer. Or maybe we need to keep working to identify the cause and the fix.

    Again, though, I think it comes back to trust. I have, in the past, tried asking “why did you do this?” or “why did this happen?” as gently and kindly as I could, with people who I thought would trust me… but the responses usually don’t help. “I’m sorry” is one common response — no matter how gentle I think I am, the person still senses danger and apologizing seems safest. “I don’t know” is another common response.

    Nobody ever says “because I thought it was the right thing to do,” or “because I’m tired from long hours and I got confused” or “because the instructions weren’t clear” or…

    I don’t think asking “why” gets me anywhere.

    How and what to do instead

    Jeff’s post has helped me identify that I have some strategies that don’t work. His suggestions of “How” and “What” and “Tell me more about…” seem like good places to start.

    I’ll assume here that we’re avoiding confrontational non-questions that are really attacks in disguise (“How could you do something like that?” and “What were you thinking?” aren’t especially likely to bring on collaborative problem solving.

    Maybe the “you” in these questions is at the heart of the problem. I can see where that might put the focus on a person, rather than on a situation, a process, a circumstance. Does focusing on a person run afoul of Jeff’s fourth point — that counterfactual thinking isn’t helpful? We might be avoiding blame, but are we still ultimately talking about what “should have” or “should not have” happened? This person should have had more training, the documentation should have been clearer, the alarms should not have been so numerous, good thing Y should not have triggered Z?

    Perhaps the key is switching to a future focus. How can we prevent this from happening in the future? What could be done to improve the process? How could we make situations like this easier and safer? Tell me more about any barriers you see that could be removed or strategies you’ve thought of for doing things better. Engaging people in the problem solving, rather than trying to be the solver myself.

    I posted this on LinkedIn in 2023. But here or there, I’d love to hear your thoughts about how you’ve approached this. What have you found useful in place of “who” or “why”?

    Originally posted 23 September 2023 on Medium.

  • Lessons from Uncle Sidney

    Lessons from Uncle Sidney

    Uncle Sidney was notorious. I think even he’d agree to that.

    Sidney was his own weather system, with lots of thunder. Photo by Johannes Plenio on Unsplash

    He might indeed be someone’s uncle, but he isn’t my uncle or the uncle of anyone I know.

    He was the main instructor for one of the programming languages used (and created!) by one of my former employers. But if you said Uncle Sidney, everyone within earshot of him knew who you meant. Sidney was his own weather system, with lots of thunder.

    His reputation preceded him, for everyone’s safety.

    Portrait of Sidney

    Likely in the same moment in which you were signed up for Sidney’s class, you were warned that you DO NOT under any circumstances show up late for class. Leave home an hour early, if you have to. Don’t be late. Your manager will hear about it, loudly and in no uncertain terms.

    His insistence on timeliness wasn’t pure whim, or even simply a matter of respect. He had the timing of every day of his class down to the minute. If you delayed the start of class, that would throw him off schedule. And there was no “just start without me, I’ll catch up” in this world. This class was intense, and he needed you on board and attentive for every minute.

    Second thing you learned: don’t fall asleep in class. I did this once. You better believe he noticed, stopped the class, and called me on it — loudly, crossly, but not unkindly. We took a short break. Again, he needed our attention for every minute.

    The stories could go on and on. Some of the stories were not so great. “Sidney yells because he cares,” we’d say. It helped me to think of being yelled at as a badge of honor, but not everyone can let shouting roll off them like water from the back of a duck.

    Some stories were more entertaining. My favorite moment was when he quipped that Friday was actually “fried day” because people were fried by then… and then he laughed so much at his own corny joke that he couldn’t continue class for at least a full minute. Which, of course, threw him off schedule.

    I emerged from those classes reasonably conversant with the programming language. It’s been years since I last used it, and most of my knowledge of the language is gone now. However, several other lessons from Sidney stick with me.

    Slow down, smart people

    I find myself repeating this one as I’m mentoring: smart people have a tendency to rush, especially by jumping to conclusions. We’re gratified to put some of the puzzle pieces together and think we see the whole picture. We see A and B, and we get excited. We immediately decide F and G, therefore K… skipping a bunch of intermediate steps. Then when K doesn’t turn out to be true, we’re confused and stuck.

    The answer is often to rewind and start again with A, taking it one step at a time. A, then B, then C, then D… wait, what about E? It turns out E isn’t true after all, which explains why K was a faulty conclusion.

    Here’s a concrete example. Let’s say a specific input to a function should be generating a certain output, but it isn’t. We stare at the function, and we don’t see how we could possibly be getting the results we are seeing, given the input we’re passing in — or more accurately, given the input we assume we’re passing in.

    Slow down a bit. Check to see if the values we’re passing in are what we expect. They are. Slow down a bit more. Are the values we’re passing to the function the same as what the function is receiving? “How could they not be??” you might ask. Check anyway. Wait, they’re not… I pass 5 and 100 and the function is receiving 0 and 0?? How can THAT be?

    And that’s exactly the reason for slowing down: you’ll find those problems that exist in the cracks, in places where you assumed everything was going according to plan. Maybe you never saved your most recent code changes, so the code that is running isn’t the same as what’s on your screen. No wonder E isn’t true.

    Don’t always take notes

    There’s some evidence that writing things down with pen and paper, rather than typing them, improves retention. Writing by hand might force you to do more processing to put the ideas in your own words, whereas typing lets you record what was said closer to verbatim, without necessarily comprehending it.

    Sidney took this a step further, calling me out on my tendency to try to write down everything. He would provide us with notes, he promised. Try putting the pen and paper aside and just listening. Just absorb the ideas and make sure you understand. Too much writing, especially in a class as fast-paced as his, and you might start to miss the current idea because you’re too busy trying to record the previous idea. This can snowball quickly.

    Ask the question ASAP

    If I’m listening to someone lecture, I often hold a question in my mind, rather than asking it. I am trying to allow for the possibility that they’re going to explain it momentarily, or that I have all the information and I just need to make some mental leap to understanding. This is not a great habit.

    With some lectures, the information is cumulative. If you don’t understand the point that was just made, you are going to be confused by the point currently being made, baffled by the point coming next, and completely lost in a matter of minutes. And at that point, it can become hard to admit that you actually lost the teacher several minutes prior and you need them to recap a lot.

    Put another way: the best time to ask is as soon as you have the question, or as soon as you realize you’re confused. The next best time to ask is when you’re kicking yourself for not having asked because you’re now completely lost. As challenging as it is to confess being lost, it’s only going to get worse the longer you stay lost.

    Could you teach it?

    Related to the point about asking the question right away: one of Sidney’s tricks was to ask the class if we all understood something. Are we sure we all completely understood it… yes, nods all around.

    Okay, he’d say, then explain it back to me.

    Uh oh. Suddenly, we’re not sure we understood it so well after all. Oops.

    It’s not necessary that you understand everything perfectly on the first try, or that you could explain it to others after just one hearing. It is definitely useful to know that there are layers of understanding, and to know when you might be expected to be at a deeper layer than you are. Now, I routinely check my understanding: did I just barely follow what I was being told? Could I explain it to someone else if they asked? If not, what do I need to ask to get clarification? Or is my minimal understanding sufficient for now?

    You influence others too

    Uncle Sidney retired before I left that company. On his last day, I made sure to catch up with him to say my goodbyes and wish him well in his retirement.

    And it really hit me — as one of the original developers of that language, he’d taught “generations” of developers how to reason about it. He’d taught us how to slow down, skip the note-taking sometimes, ask the questions, and check our understanding. And everyone who taught the language would do so in his footsteps as well, even if their approaches and teaching styles were entirely different. In that way, his influence on the organization was not so unlike an uncle after all.

    What’s your legacy, and what do you hope it will be? When you move on from where you are now, what will people remember about you? What habits will they pick up from you, what lessons did they learn from you, and how did you influence the culture and people around you?

    Originally posted 10 September 2023 on Medium.