Categories
Remote Engineers

Your manager can’t read your mind.

As a developer, something that always frustrated me was the fact that my managers didn’t seem to realize the disruption they caused. I would be working on a ticket, and someone would switch me to something else on short notice.

Here we go again. Stash my work. Create new branch. Understand what has to be done. Do it all over again once this one is done. Get asked why the ticket I had to drop isn’t finished yet. Well, because you gave me a different task, that’s why!

So when I started managing people, I’d tell them to let me know if there was any problem, and to raise their concerns early if something wasn’t going to be finished on time.

Time after time, I would be disappointed to hear that someone was delayed on a critical task because they were assigned a second task and dropped the first one.

Why didn’t you tell me?

Oh, I thought you knew!

Ah. The mythical mind reading manager. If you never lead a team, you probably assume information always gets to your manager first, including information about how you will proceed if given an ambiguous instruction like “hey, please fix this ticket” without any other specifications on when it is due, what the priority is, and if you should drop your tasks or not to attend to it.

You may think they know that when they tell you that, you will drop everything and do it.

Unfortunately, very often, they don’t. This is especially true of newbie managers. Maybe because they assume there is enough trust that you would simply push back if you had a problem. Maybe because a PM or other member of the team sent you a ticket and told you to work on it without your manager being made aware. Maybe because they think you will work on it as soon as possible and nothing bad will happen.

They should know better. We should know better. But sometimes, we don’t.

I could write a blog for managers (and I might) about being specific when it comes to assigning work and what our expectations are… but I decided to write it for engineers because nobody ever tells us what we can do to make up for mistakes our managers make, or how to push them to improve, or even how we as developers can be better at asking the right questions to help us be more productive and less overwhelmed all the time.

So. The next time you get a ticket assigned that would interfere with your work in progress, go ahead and ask

“Should I stop working on #this and get started on #newThing right away, or should I finish #this first?”

or

“If I drop #this, we may not make it to #that deadline, since I have to context switch 3x to work on #newThing and it takes some effort, is that okay with you?”

…or any other question that helps you figure out the best path forward.

It may feel weird, but communicating your constraints is a good thing. Your manager may not have realized the problem that a new task would cause. Thanks to you, they may find a problem they had missed before around workflows, or they will learn how to plan better.

They may tell you that YES, you need to drop your task. Or they may reconsider and reprioritize. But at least you will know, and they wont be able to ask you “why isn’t this other task done” 1 hour after they told you to context switch 😉

They may even learn a thing or two about remote communications. As you do this, you may want to bring it up on a 1:1, and explain how you managed to stop context switching, or why context switching is problematic if it happens too often. I would expect any engineering manager to know this, but if they have forgotten how bad it can get… at least this will remind them to be careful when they assign work.

On your end, by asking this questions you will know for sure when your task is urgent enough to drop everything and when it is only urgent because someone higher up the chain wants it ASAP. This is important, because it lets you make better decisions, too.

Being the person who knows how to dig up important signal even in casual communications is a skill that will be incredibly useful as you progress in your career. You will understand how work flows from X to Y a lot better, and you will learn how to ask better, more insightful questions that help your team make better choices and be more productive.

Let me know if you have had this problem, and how you approached it. I’d love to hear from you at rowasc@hey.com

Categories
Remote Engineers

Are junior devs supposed to contribute to production in their first weeks or month?

Yes. Without a doubt.

Junior developers cannot learn by being isolated from the team, and the most infuriating way in which they get to be isolated is by not being included in day to day team activities. You may be thinking watercooler. I am thinking pushing code and having someone use it.

If we don’t include junior developers in the entire software development lifecycle, we aren’t training them to succeed.

There is no better teacher than shipping.

So if you are a junior developer wondering if pushing code that makes it into production is a reasonable expectation, let me reassure you that it is, and that you should be wary of environments where the code you write isn’t being used.

The company should have enough safety rails to protect junior developers from making terrible mistakes or recovering from them, but other than that, writing code is something we do to achieve a goal, and we cannot achieve the goal of serving users if users don’t get to have the features a junior developer writes, or the bugs they solve.

I advocate for getting a tiny commit into production as early as Day ONE of your new job, but if that isn’t feasible, Week ONE is good enough as a goal.

Learning how code goes from your precious code editor and into users lives is a critical skill for engineers At All Levels while they onboard into a new job.

Categories
Remote Engineers

Your team wants you to succeed. Don’t stay stuck.

It was Monday morning, and I’d been thinking about it through my weekend. A developer in my team wasn’t making any progress and now a ticket was delayed.

They weren’t asking for help, and our offers to help them were not being received as we hoped. Instead of accepting the team’s help, they kept saying they were almost done with the task.

All I wanted to do was help get the tickets out, and help them get unstuck.

While I worried about not coming off as a micro manager, and drafted my questions to them in the best way I could to avoid stressing them out while they were delayed, they were worried that they had waited too long to ask for help. “How do I even ask for help?” “Is it too late to ask?” “I wish I had asked earlier”.

It doesn’t have to be this way.

Your team wants you to succeed.

Think about the last time you were stuck and waited for more than an hour to ask for help.

What stopped you? What was your decision making process like?

If you aren’t sure why, and you don’t know how to avoid this in the future, you can use this list to help you decide how to ask for help.

Open a blank document and write down

  1. What am I trying to achieve?
    • Good: send a POST request to the server at /card to create a new card
    • Less good: create a card
    • Bad: finish my ticket
  2. What is happening? (vs what you want to achieve)
    • Good: I am able to submit the card to the /card endpoint, but the server responds with a 422 error despite the fact that I sent all the required fields. The error message says “Validation failed”
    • Less good: I get an error
    • Bad: I can’t create the card
  3. What did I try?
    • Good: I read the documentation on the /card endpoint, and verified that I’m sending all the required fields (name, description, tags). Here’s an example payload: {name: “hello”, description: “Hello I am debugging”, tags: “hello, I, am, a tag”}
    • Less good: I verified the payload I’m sending, it seems correct.
    • Bad: I tried submitting through JavaScript
  4. What research did I do?
    1. list anything you googled (exact keywords help a lot)
    2. list anything you used as reference (docs, notes)

Why does this work?

  • Because it helps you find the problem yourself. It’s similar to rubber ducking, in that by forcing yourself to explain the problem in detail to another person and showing them your work, you often find the solution on your own, or a useful clue.
  • Because if you don’t find the problem, you know for sure there’s not time to waste. You need to go and ask for help.
  • Because when you do ask for help, you can send this same debugging list to your team, and they’ll be able to help you a lot better than if you said “the validation isn’t working for me”.

Your team will be delighted to find out you did your research before asking. They will be better at helping you because of all the detail provided, too.

You won’t have to wait for hours, and stay stuck on a problem for no good reason. If going through the list doesn’t help, then You will know that you need help.

What if I don’t know how to answer the questions on the list?

Then, you absolutely need help. Don’t waste more time. Start by writing down what you can, share it, and explain that you don’t know where to start debugging or what to try. Your team will be happy to teach you, and you will learn more debugging techniques, too.