Beyond Writing Code

Tag: setting limits

  • Recognize your wall

    Recognize your wall

    I’m not saying it’s time to go stare at the wall. Well, maybe I am.

    Maybe you’ve been firefighting most of the day, one urgent situation after another popping up like ads on top of a recipe blog. Perhaps it’s been an endless stream of meetings. Or maybe you’ve been working heads-down for hours (lucky you!), writing code for some huge project. Whatever the situation, it’s now late in the day, you’re dragging… but you’re trying to get “just one more thing” done before you dash out the door.

    Photo by Tim Gouw on Unsplash

    First of all, is it just me, or is there always “just one more thing” immediately after that “one more thing” you’re working on? An endless stream of what seem at the time like final tasks, each one inspiring the need for the next…

    Secondly, let’s take a good look at how well you’re accomplishing that “one more thing.” Mmm hmm.

    I can hear some of you now, saying, “Oh come on, I can totally code for 13 hours straight! My code at 8pm is just as good as my code at 8am.” I hear it because I’ve said similar things in the past. And I’m not here to suggest that you’re wrong. I mean, you’re probably wrong. But who knows, maybe your ability to code for long hours is truly exceptional. 🏅

    I am here to suggest that you start to learn the signals that tell you when you are simply Done Coding For The Day, regardless of what the clock says or how long you’ve been at it. In other words, learn how to recognize when you’ve hit a wall. Here are some warning signs to watch for.

    You’re forgetting stuff

    You spend an hour debugging your code, only to find out that you’d assigned a variable the value "INSERT_REAL_VALUE HERE" instead of the correct value. You meant to go look up said real value and add it before committing that code. You forgot. Looking up the value takes you 20 seconds. Well, there’s an hour you won’t get back.

    Or you send your boss an email about a spreadsheet, but you forget to attach the spreadsheet. You send a second email with the attachment, forgetting there are actually TWO spreadsheets you need to send. You send the second attachment. Two minutes later, you remember that you never added this morning’s data to the first spreadsheet…

    You’re making familiar mistakes

    Even though I’ve been using mostly JavaScript for several years now, other languages I’ve used sometimes still make an unwanted guest appearance.

    For example: when I, yet again, use contains() on an array in JavaScript. JavaScript, yet again, reminds me that it doesn’t know what I’m talking about. It’s includes() that I want, not contains().

    I have to look that up, every time. I had to look it up for this article. For me, the warning sign is not forgetting the function name. The warning sign is forgetting to go look up the function name.

    You’re making newbie mistakes

    If you’re a newbie, making newbie mistakes is normal! Nothing to see here. You can move on to the next section.

    If you’ve been in this field a while, though, and you’re catching yourself using = (assignment) when you mean === (strict equals), for example… it might be time to step away from the keyboard.

    You’ve gone way off course

    Your code worked fine at around 4pm. You were just trying to fix one little piece of one little unit test. Now it’s several hours later, and not only have you not fixed your unit test, you have broken your previously working code in a way you don’t understand. And in the course of trying to fix that, you accidentally changed something else, and now your application won’t even start on your branch. And in your flailing attempt to get the code on your branch to work, you inadvertently committed a bunch of code to an unrelated branch…

    When you are so far down in the pit of despair, my friend: stop digging.

    You literally can’t see 😫

    A comma where a semicolon ought to be. Missing quotation marks. A variable called employeeFirstName in one place and employeeFirstname 20 lines later. These things happen to us all now and then. But if “now and then” has turned into “three times in the past hour,” it’s time to give your eyes a rest.

    Someone at a laptop clutching their head, phone and glasses to one side
    Why do I get an error that customer-file-052122.json doesn’t exist?? I can see that customer-fle-052122.json is right there! (Photo by Elisa Ventur on Unsplash)

    Better late than never

    If you don’t catch yourself faltering in the moment, you might start to notice the results the next day. You can’t change the past, but this is still useful information for the future!

    Pay attention when, in the light of day, you see that all of your code from last night stinks. Or worse, your peers reviews your late-night pull request, and point out at length exactly what stinks about your code. Even worse, most or all of it involves basic mistakes you know you wouldn’t normally make.

    Water under the bridge, but start to connect a certain fuzzy-brained feeling on day 1 with the unpleasant results on day 2. You’ll begin to recognize what might have been signs for you last time, and thereby learn what might be signs for you next time.

    Regardless of whether you can make it through 13 hours straight of coding, or if you run out of steam much earlier than that, pay attention to what the warning signs are for you that things are going awry. You’ll save yourself a lot of stress by learning when it’s time for you to step back from the keyboard and go do something else — or go stare at the wall.

    Originally posted 23 May 2022 on Medium.

  • Something’s gotta give

    Something’s gotta give

    You’ve already got a full schedule when the boss asks you to take on a special project. Or maybe an urgent issue just jumped up above everything else you were planning to do this week. Or you’ve got multiple stakeholders, and all of them insist on being your “top priority”.

    Photo by JESHOOTS.COM on Unsplash

    Before you start canceling evening and weekend plans so you can spend even more time than you already do at work: stop.

    You only have so many hours in the week when you will be able to work effectively. And anyway, sacrificing your personal time might be necessary in a pinch, but it should be a rare occurrence. That time is yours!

    When you start to see that you’ve got more on your plate than you can handle and still deliver the high quality of work you’d like to be known for, here are some strategies to find balance.

    Something else is de-prioritized

    If you’ve got room for five projects in your week, and your manager just approached you with a sixth, inquire about which of the other five you should set aside to focus on the new project. It may be that when your manager realizes you have five important things already planned, that sixth one doesn’t seem so urgent after all. Or maybe they agree that #1 and #2 are still your top priorities, but #3 could wait for later, and this new project should take its place in your workload for the week.

    Someone else to the rescue

    If none of your current projects can be dropped, perhaps there’s someone else who can assist with the new assignment. Or perhaps you can shift one of your items to someone else’s to do list in order to allow you to pick up the newcomer.

    Be warned however that simply adding people is often not helpful. If a colleague is assigned to help you with one of your projects, but you are going to spend more time explaining the project to your colleague than you would spend just working on it yourself, this might not be the time-saver you expect. There are great reasons for working collaboratively, but short term time savings is not always one of them.

    Scale it back a bit

    Let’s say you learn that all six of these projects must get done, and they must all get done by you. Can the scope of any of these projects be scaled back to allow you to handle all of them? Perhaps the columns on the table you’re coding don’t need a sort option, after all. Or maybe you can just handle the “happy path” case for the new screen, the error handling pieces can be taken care of next week.

    Step up now, step back later

    In some situations, you might legitimately have a time crunch that can’t be avoided. There’s a hard deadline next week, and there’s nobody else available to pitch in. If that’s the case, you might choose to negotiate putting in some extra time now in exchange for a little extra time off after the deadline has passed — if you can trust that your management will keep that promise. A few late nights this week might be rough, but next week when you’re cutting out early on a sunny day or taking a morning off to relax, it might all be worth it.

    Estimating your work is part of your job

    It isn’t easy to say “no” (or even “not this week”) to management or other stakeholders. However, accurately estimating how much time a project needs is part of your role. Your boss might not be aware that the “simple” item you are coding will take several days, or that you need several hours of preparation time for that workshop you are leading on Thursday.

    For larger tasks, you might need to break it down into sub-estimates. Then, when your supervisor says “what do you mean that will take six weeks??” you can calmly explain how you arrived at that number to help them understand everything involved with the project. And again, if they say “but I need it done in three weeks,” you have options: drop other work, get some help, scale the project back, and so on.

    Think of it as your manager relying on you, as a professional, to let them know how much time you will need to complete your work. This can help make it a little less intimidating to speak up when the boss arrives to add more to your already packed to do list. And finally, more good news: this gets easier with practice!

    Originally posted 16 May 2022 on Medium.