Overcoming Imposter Syndrome

Jonny Ray — Wed, 01 Nov 2023 17:00:20 +0000

You suck at your job and everyone knows it.

Not really, but it's not an uncommon feeling that we have about ourselves at some point(s) in our careers. I know I certainly have about myself.

Sometimes it has come as a persistent voice in my head telling me that I should be performing better, that I'm terribly behind, and it's unacceptable. At other times it has been an unnerving feeling that I'll eventually be 'discovered' as someone who is not capable of the responsibilities given to them in their job. It is like a shadow that looms over me, harbouring anxiety, and difficult to shake off.

Imposter Syndrome can come for us all regardless of the field we're in. It's generally described as a frequent (or sometimes constant) inability to believe what we have accomplished or achieved is truly deserved. We'd rather question it or simply attribute it to other explanations like fortune or negligence on another's behalf instead.

Building resilience against these sentiments is difficult. The best solution is unquestionably a psychotherapeutic one as issues like these can be deeper than what's on the surface. It's an answer that has worked well for me and one that I will always heavily recommend. There are additional strategies, however, that can complement this approach. Based on my personal experiences, I'd like to offer three suggestions that have proven helpful during challenging times.

Always Be Learning

Continuous learning has been my most reliable ally in conquering the 'imposter' feeling. By consistently expanding your skillset and knowledge, it can boost your self-confidence and feels reassuring that even if you're not the best in your field, it's much more important that you're progressing towards a better version of yourself. If you need help getting started in this, try to set learning goals to motivate you in the right direction.

You're Not Alone

Imposter Syndrome doesn't discriminate based on experience or success. Whether you've been in the industry for two years or two decades, it can impact you at any stage of your career. Renowned individuals like Tom Hanks, Awkwafina, and David Bowie have all battled with these feelings. Chances are a good proportion of your colleagues have either gone through or are going through this themselves too. Try reaching out to them, or if you prefer, you can reach out to me. Share experiences. When we feel less isolated then acceptance becomes more accessible.

It's OK to not be OK

Remember that "to err is human" - everyone has off days, even weeks, or possibly longer stretches. These moments don't define your abilities; they are simply temporary challenges with a beginning and, more importantly, an end. In turn, remember that "to forgive [is] divine" - take a moment to practise some self-compassion. You can explore mindfulness, meditation, stoic readings, or any other techniques that suit your preferences to manage negative emotions.

Overcoming Imposter Syndrome is not a quick fix; it's a journey with its peaks and troughs. I can't say for sure if I'll ever fully conquer it on a personal level, but with the right tools, I'm no longer defined by its self-doubting narratives.

If you've experienced similar feelings or have tips for dealing with Imposter Syndrome, I'd love to hear from you in the comments below. Sharing our experiences and supporting one another is an essential step toward overcoming this common challenge.

The Power of Prefactoring

Jonny Ray — Wed, 25 Oct 2023 14:35:23 +0000

I've recently been reading Martin Fowler's book "Refactoring: Improving the Design of Existing Code", and while I could (and probably should) praise the book's overall quality and usefulness, there is something from the earlier chapters that particularly resonated with me: the concept of refactoring before starting a task, or 'Prefactoring'.

But why? Well, let us first take into consideration refactoring in unto itself.

Refactoring in a nutshell

Refactoring has a rather bad reputation outside of the engineering department; it's usually seen as work done with no new functionality added, and therefore no added value to the product. But for those within engineering, we know that's contrary to the truth; just because the end result doesn't have a tangible added value to customers, it doesn't necessarily mean it was time wasted. Refactoring, generally speaking, is done for two main reasons:

1. Maintaining existing code

We as engineers are by no means perfect, and even if we're not digesting articles and books in our free time we are still always learning about programming with every class or function that we write. Once our code is written and no longer just verbose specifications handed to us or ideas in our heads we tend to interpret it differently and see it more clearly for what it is. Perhaps we can improve the efficiency of an algorithm, or maybe just simplify some code that turned out to be complex overengineering on our behalf. Potentially we named it something very particular to our feature work/use case, but in fact has quite a general implementation that could be used by other subsystems. As long as we already have our test suite coverage, all of these things and more can now be cleaned up very quickly to have a happier and healthier code base. For those familiar with the principles of Test Driven Development this is where the 'Refactor' in "Red; Green; Refactor" comes in.

2. Extending existing code

It is an obvious observation that we write code to fulfill a specification, those specifications can change over time, and so with it the code. So as pragmatic programmers, we try to write clean, modular code that can be adapted and substituted if needed. But where is the line between being prudent and helpful to future developers of this code, and going into 'YAGNI' (you aren't going to need it) territory? We can only do our best with the information we have at the time to make the right decision(s), but rarely do we have enough to be truly confident in them. This is where Prefactoring can shine.

What is Prefactoring?

As I mentioned at the start, while typical refactoring is done after we've written some code and the corresponding tests, prefactoring is (as the name implies) all about doing our refactoring before we start our next task or feature. It could be something done as part of your planning for the next sprint, or something you schedule to include in your sprint's capacity. What makes it so valuable is that it excels in situations where we might struggle with normal refactoring.

While cleaning up code as soon as we've written it is the best thing to do, it's not an avenue that is always available to us. Sometimes we're in a rush to finish a sprint for whatever reason and we can't afford the time to clean everything up. On other occasions maybe we just don't know that we can improve on what we have because we haven't learned a better approach yet. With regards to extending what we have, we now know the direction the code is going in because we're planning on (or are already in the process of) changing it for that very purpose. This helps eliminate any concern of overengineering what we aren't going to need. Additionally, although I might be pointing out the obvious we must also remember that less code is easier to refactor than more code, and so if we do this before adding new functionality we will therefore save time overall!

An example

Let's start with a very basic deployment script that takes in a given (constant) set of files and processes them before deploying. Initially, we could have code that looks like the following:

web_files = [
    "my_page.html",
    "my_scripts.js",
    "another_page.html",
    "my_styles.css",
    "more_scripts.js",
    …
]

for web_file in web_files:
    with open(web_file, 'r') as file:
        if web_file.endswith(".html"):
            # do special HTML processing here
        # do typical file processing here

While maybe not the prettiest of solutions, it certainly does the job asked of it. But now let's introduce a change to the spec - we need to minify the javascript files when we process them.

Naturally, we could just add another if condition and be done with it. There's nothing inherently wrong with that approach and depending on the particular situation it might be the most pragmatic one, but for the sake of this example let's pretend that there could already be many if conditions, or maybe we know that minifying .js files is just the first of many to come. Let's prefactor!

class FileProcessor:
    def __init__(self, file_name):
        self.file_name = file_name

    def process(self, file):
        # do typical file processing here

class HtmlFileProcessor(FileProcessor):
    def process(self, file):
        # do special HTML file processing here
        super().process(file)

By introducing the strategy pattern here, we can now simplify the original orchestration:

web_file_processors = [
    HtmlFileProcessor("my_page.html"),
    FileProcessor("my_scripts.js"),
    HtmlFileProcessor("another_page.html"),
    FileProcessor("my_styles.css"),
    FileProcessor("more_scripts.js"),
    …
]

for web_file_processor in web_file_processors:
    with open(web_file_processor.file_name, 'r') as file:
        web_file_processor.process(file)

What have we achieved here? From a product perspective, arguably nothing - no new functionality has been added. But from an engineering perspective, I would argue a lot of value has been gained! Primarily, we have separated out our processing logic from our orchestration logic. The orchestration can now live happily on its own with simpler unit tests and be closed for modification. On the other hand, our FileProcessor class is very much open for extension - as per the spec change we can add a JsFileProcessor that introduces our required minification, as well as any other strategies we may require in the future!

Suggested guidelines for prefactoring

As with refactoring, prefactoring should follow similar guidelines:

Prefactor with purpose! While our prefactoring is not explicitly adding value to the product, it should always be adding value to the code base, and we achieve this by focusing on making the code 'cleaner' than when we started. If the result is going to be harder to extend or maintain, then we should reconsider our approach.
Test coverage is essential. As one of my former Leads once told me "refactoring without tests is no more than hopeful guesswork".
Do not add any new features or functionality as a part of your prefactoring. Firstly, this misses the whole point of prefactoring as a separate, self-contained, and reviewable step. Secondly, this has a tendency to be more prone to accidentally introducing mistakes/regressions and will make reviewing the code more difficult. Ultimately, depending on how your tests are laid out, you should only need superficial changes at most to your test suite to keep everything passing.

In summary

As those who have worked with me already know, I'm a big fan of refactoring because it challenges our engineering skills to get the best out of our code. To me, Prefactoring is a natural and wonderful extension of that. But what are your thoughts? Have you tried Prefactoring (under this name or another), or would you consider giving it a try? What other benefits or drawbacks should we take into account? Feel free to share your thoughts in the comments!

DEV Community: Jonny Ray