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!
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.
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 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:
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.
Before participating in a career panel at the TechRadar conference in November’22, I sat down with the organizers to talk a bit about my career and of course – the unavoidable subject (even though we tried) – women in tech (Hebrew).
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.
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.
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.
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:
Over the recent years we’ve seen an explosion in content about and for women in the workplace, and women in tech specifically. Broadly speaking, there are two types of approaches to this subject:
Play the game: Represented by the esteemed and critiqued book Lean In by Sheryl Sandberg, this type of content focuses on getting women to succeed within the existing framework, hopefully getting them into positions of power where they will be able to help others.
Smash the patriarchy: Represented by the 2020 book The Fix by Michelle King, this type of content focuses on highlighting all the ways the system is broken and has to change for women to succeed.
Smash the patriarchy is often opposed to play the game advice because they feel it’s literally playing into the hands of the existing power structures. While this is true in some ways, I personally think waiting for the revolution to come is not the best course of actions for all individuals, we should probably try to do both, in appropriate contexts.
There is a 3rd genre, represented by books like Brotopia by Emily Chang. This type of content can be summarized as “everything sucks, you’re not imagining it, it’s not your fault”. I’ve stopped reading this kind of book because I already know I’m not imagining it and it’s not my fault (though not everything sucks, at least not all the time), so I feel it doesn’t help me grow, it’s just depressing. This content is important to understand, but not for me, not right now.
Most of the content written about women in the workplace targets women on the management track. I think women trying to make their way up in technical roles face a unique challenge which is not being addressed yet. In this post I will try to share my perspective on some of the obstacles in our way and how to overcome them.
After my last post on how I got my career back on track I was flooded with (at least 3) requests to share my advice on what I did to “level up” my work so other people could get ahead the same way.
The easy answer here would be “I can’t say”. Each person, each manager, each organization, each situation is unique and who am I anyway to be giving advice on things I’m still figuring out myself. That said, my “obvious” might be someone else’s “mind blown”, so here goes.
My career started pretty normally, I guess. I went to a respected university and finished a BSc. in computer science and an MBA with good grades. I was working as a student at a well respected international corporation and was offered a full time job. I was totally set up for success. Somehow, 12 years passed and I found myself in a dead-end job with a feeling that I’d missed out on my potential and I would never make up for lost time.
In this post I’ll share how I recovered from an unknowing attempt to kill my career, and how within a few years became a senior engineer with my eye on higher IC levels (maybe staff engineer in a couple of years? Keep your fingers crossed).
