Cracking the Dress Code

Steve Jobs had it easy, he could wear a black turtle neck and blue jeans all day every day and it was hailed as genius. If that works for you, you can stop reading here. But if you feel that the “tech uniform” doesn’t allow you to be as authentic at work as you would like – this blog post is for you.

This is the outline of a talk I gave on December 2022 at the Google TLV office for a group of women in technical roles. I did not record it and I'm happy I didn't, because it enabled me and the participants to be much more open. I doubt I will ever give this talk again, it was a one time thing after being asked for it repeatedly - but I don't want it to become my thing. 
The first section covers why I think this subject is important to discuss, even if I would rather focus on strictly professional subjects. The second section has concrete tips on how to develop your own style and how to apply it.
As usual, this talk is rooted in my experience as a woman SWE, in Israeli/American tech, it might not apply to everyone. However, I believe it's an important subject that will be useful for many women in STEM and other male dominated fields, so here goes.
Continue reading

The medium is the asynchronous message

Hey, what’s up? If you’ve worked in any kind of tech organization since 2013 or so, you’ve probably been using some kind of chat application for work. It doesn’t matter which chat application you use, you’ve probably been in one of the following scenarios (as Alice or Bob or both):

In the first scenario, Alice sends a message to Bob. Bob is away from his desk and doesn’t see the message for a while. By the time Bob responds, Alice is also gone. Two messages have been sent but no useful information has been passed between Alice and Bob. Only the 3rd message, delayed by who knows how long, is actually useful.

Continue reading

Whatcha gonna do with a toxic colleague

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.
Any identifying information is removed and I always inform participants before posting anything we talked about.

In today’s mentoring session we discuss what to do about a toxic colleague. That person that makes you feel small and stupid, maybe taking credit for your work and ideas, or “stealing” all the interesting and promotable tasks you were supposed to be doing, maybe just rude and unpleasant in general.

Hopefully you’ll never encounter one of these, but if we’re being realistic – you probably will. Unfortunately, they may exist even in the best of workplace cultures because their behavior is easy to hide. Often, their misconduct will be directed at those lower on the organizational food chain, and therefore the powers that be may be blissfully unaware. If no one tells them – how will they know?

Image by Vlad Vasnetsov from Pixabay
Continue reading

The floor is lava: a realistic approach to work-life balance

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.
Any identifying information is removed and I always inform participants before posting anything we talked about.

In today’s mentoring session I addressed some concerns around starting a family while maintaining a tech career. While this post will focus on the specific challenges of pregnancy and raising children, some of the insights may be relevant to any kind of attempt to balance a career with other responsibilities and interests outside of work.

tl;dr: Balance is for people who don’t have a life or don’t have work. For anyone (everyone?) else – the most you can hope for is not to neglect either one too much.

The conversation started with the a concern specifically about how to manage the final months of pregnancy: Should she agree to reduce the scope of her tasks and responsibility? Should she start her maternity leave early? Does this internal debate mean she’s weak, and a man wouldn’t even consider reducing his workload just because he was pregnant?

Photo by Anrita1705 on pixabay
Continue reading

Silly Baboons, Stubborn Elephants II: Navigating Culture Differences Across R&D groups

In September 2019 I published Silly Baboons, Stubborn Elephants: A Product Engineer’s Guide to Working with Platform Engineers. Since then I’ve expanded my thinking on culture gaps inside engineering organizations and how they affect our ability to collaborate across different groups with different motivations and incentives into a talk, presented at Reversim 2021 conference (right before Omicron hit and everything shut down again for COVID).

The talk is in Hebrew, so I’ve included the slides and my speaker notes (with bonus content I didn’t have time for!) translated into English after the video.

Update [September 2023]: I gave a short version of this talk at LeadDev Berlin in 2022 which is now available in English! Yay!

Continue reading

This email should have been a document

Everyone knows about the terribly boring and ineffective meeting that should have been an email, but… Should it really have been an email? I’m not so sure. I think email in the workplace was fine when that was all we had, but that form of communication has outlived its usefulness and should mostly be replaced by other mediums. There, I said it.

Photo by Maksim Goncharenok from Pexels

Emails are traditionally used for 3 main purposes:

Continue reading

Tips for starting a new job

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.
Any identifying information is removed and I always inform participants before posting anything we talked about.
Photo by Matt Hudson on Unsplash

In today’s mentoring session we’re helping someone who’s about to start a new job and is worried about onboarding. There is an infinite amount of content on how to start a new job and how to onboard well, so I’m going to focus on 3 tips:

Continue reading

Defensive estimations and time management

This post is part of my mentoring conversation series which includes relatively short posts on topics that have come from a mentoring session. Often, these conversations produce insights which could benefit a wider audience.
Any identifying information is removed and I always inform participants before posting anything we talked about.

In today’s mentoring session we’re dealing with a manager who doesn’t trust task estimations and asks to reduce them, resulting in stress and overtime. Add to that a feeling that you’re not keeping up with the tasks you’ve committed to completing… This is, of course, not the healthiest environment, but unfortunately, still quite common.

Photo by Tima Miroshnichenko from Pexels
Continue reading

Rubber duck debugging – out. Talking to a person – in.

If you’re part of the software industry you may have heard of rubber duck debugging. The idea is when you’re trying to debug an issue, you’ll explain it to an inanimate object and the answer will present itself. This sounds cute, especially if you visualize yourself speaking to a rubber duck, or teddy bear, or cat. But trust the software industry to find the dark side of any cute idea.

Photo by Quang Nguyen Vinh from Pexels

Many software engineers, particularly when they’re just getting started (but not only!) find it hard to strike the right balance between asking questions and figuring things out on their own.

First, they’re afraid of looking “dumb”. Second, many engineers convey (whether on purpose or inadvertently) that their time is too precious to answer “unimportant” questions. Third, often effective communication is neither engineer’s strong suit, and things may break down in that area.

Continue reading

How to write an effective design document

So, you’ve come up with a beautiful, elegant, solid software design. But to move forward you have to get it approved. And to get it approved, you have to communicate it to others. Because, unfortunately, having the idea in your mind is not enough to get it built as you envisioned it. Getting your design across effectively is not a simple task, and many software engineers are not skilled at it. But as most skills, your skill at writing design documents can be improved, I hope this post helps you on your way.

As we write a design document we should keep two main concerns in mind:

Purpose

In my opinion these are the three objectives of a good design document:

  • Get buy-in for the high-level architecture from relevant stakeholders (engineering managers, technical leaders, engineers from other relevant groups).
  • Provide a blueprint for implementation.
  • Provide documentation (for historical reference, onboarding etc.)

But most importantly: A design document may include a summary of requirements, if appropriate – but it should not read as a wishlist. Someone reading a design document should get a clear idea of what you are planning to do.

Image by Pexels on Pixabay

Audience

Who will be reading the design document:

  • People who need to approve/provide feedback on the design.
  • People who need to do the work outlined in the document.
  • The author (you’re not going to remember why you did any of this in a couple of months).

In addition to their role, readers may have varying context on the design:

  • Internal readers who already know the background whose memory just needs to be refreshed.
  • External readers or newcomers who have no or close to no context and need a high level overview of what this document will cover.

When we write a design doc we need to keep the purpose and the different audiences in mind so we can write the right thing in the right place at the right level of detail.

Now that we know why we’re writing a design document and for who, let’s get into what it should include:

Continue reading