Imposter Syndrome in Tech

Part 2: Compelled to Code

Written by Catherine Browne and Garth Gilmour

Series Overview

What follows is the second in a series of four articles outlining the common manifestations of Imposter Syndrome in the world of tech. In each we will give both the software engineer’s perspective, then the psychotherapist’s response with some ways to tackle it, both cognitive and practical. Of course, these articles are only for general interest and anybody really struggling is advised to seek more specific, professional help.

The first article, dealt with relentless change and fear of being ridiculed. Now, we turn to issues with diversification, career breaks, and the fear of simply working less.

3) Feeling Unsafe To Diversify or Take A Career Break

Most people imagine that software engineers spend their working lives writing code. Chained to a keyboard whilst typing furiously with intense concentration. This is maybe 10% of the job – maximum. 

As in other professions most of the effort is not expended on creating the thing, but on managing the process of creating the thing. Modern software projects require large teams, whose outputs must be synchronized, merged, reviewed, tested, deployed, versioned, and maintained. 

Every team has a ‘pipeline’ for creating and managing releases, which is frequently more complex than either the programming language being used or the architecture of the application being created. This pipeline has a life of its own. It is expanded, enhanced and redesigned continually.

Let’s imagine that, as an engineer, you want to try your hand at something else for a year. Maybe you want to work as a product designer, or a project manager, or an architect. Perhaps you want to venture even further afield and become involved in business analysis, consultancy, or even training. The danger is that even if there are no platform shifts, and you are just as good a programmer when you return as when you left, you will still be utterly clueless when you return to your team. Because the pipeline has incrementally morphed beyond recognition.

This fear also manifests itself in our personal lives. It’s not unusual for developers to worry about taking maternity / paternity leave, or a career break to go travelling. Even though you are returning to the same role, and often the same project, nothing will be quite the same as when you left it. There is also the related problem, common to all high stress professions, that the wider business will have moved on whilst you were away. 

From Garth’s Experience

“When I became an Advocate I was advised that you typically had eighteen months to write articles, produce sample systems, appear on podcasts and present at conferences. During that time the knowledge base you had gained as a developer would incrementally become more and more stale, to the point where you were no longer effective in your new role. The only remedies were ongoing self-education, discussions with ‘real developers’ and secondments back into project teams.”

Catherine’s Response

It is not possible to thrive at work when we feel fundamentally unsafe. Consciously investing in our physical and mental wellbeing, including a fulfilling personal life, can all too easily become secondary to just hanging on, even in toxic or unfulfilling roles, that will keep us gainfully employed with any kind of career trajectory. We don’t feel able to risk a side-step.

But humans are not very good at accurately assessing risks. If anxious, we easily overestimate a threat, and underestimate our resources to adapt to it, a phenomenon known as ‘catastrophising’.

This is made much worse if we hold ourselves to excessively high standards in what adapting might involve. If, for example, we visualise ourselves being anything less than perfectly relaxed after a day or two back in our former roles and interpret that uncertainty as failure or inadequacy. If we don’t give ourselves enough time to upskill and accept that, for a while, we’re going to be surfing a somewhat bewildering learning curve. If we’re not kind to ourselves while we do this.

Finding something difficult does not necessarily indicate a lack of capability, it doesn’t mean you won’t or can’t adapt, just that you need more time and patience with yourself: some self-compassion.

It may help to imagine what you would say to someone you care about who was avoiding taking a similar career risk for fear of how they would cope when they returned to the team. You may discover you would be a lot more positive and a lot more encouraging and supportive of this friend than are being with yourself.

Don’t let yourself forget why you took that tangent or time away – it was a vote for growth, for fulfilment, for yourself and now you are  a more multifaceted person as a result and that can only benefit your professional life. So stand up for yourself in negotiating lower productivity expectations in the first weeks and months on a return to an unfamiliar role and try to be gentle with yourself.

4) IF Awake THEN Code END IF* : Being Afraid to Work Less

* The limit of Catherine’s current programming skills 🙂

Here’s a very common meme about programming:

Like most memes this is based on a kernel of truth. Programming has traditionally been viewed as being as much a vocation as an occupation. Real coders (allegedly) enjoy writing code for its own sake. It’s as much their passion and their refuge from the world as it is a way to make ends meet.

This creates problems when you acquire a desire for luxuries like hobbies, a family, or a conventional lifestyle. The friction between the desire to code and the desire to have a life opens the door to Imposter Syndrome. Hence the media stereotype of the coder as someone who is young, isolated, troubled, or driven:

Some real developers. Not.

It comes as a surprise to many developers to learn this is not the norm in the world of work. The point about a career is that it doesn’t follow you home at night. Or at least when it does you don’t have to like it. A chef may cook dinner for their family, a carpenter may do DIY for relatives, a lawyer may give free legal advice etc… But we never require them to do so as part of their profession, and we definitely don’t think of them as bad at their job when they don’t.

By contrast, software engineers are assumed to like programming to the point where it interferes with the everyday rituals of adult life. Developers are assumed to spend hours in the evenings and weekends, honing their craft by working on personal projects and exploring new technologies. Having a plethora of side projects is another staple of programmer humour:

This has very real implications for starting and sustaining a career in IT. When hiring interns and junior developers it’s common for projects to place as much weight on personal projects hosted on GitHub as exam results and work experience. Thought leaders in the software community are expected to create and maintain open source projects, in addition to their day job. Educators and advocates often blog about the out of hours research they are doing, to the point where they host live coding streams on platforms like Twitch.

To summarise, you’re only a really real developer if you’re doing a sufficient amount of extra-curricular activity. But no one is ever going to tell you how much is enough. There can even be a horrible Catch-22 effect, where the more you become known for your side projects and open source work the more effort you need to put into maintaining and extending these unfunded, after-hours, time sinks.

In some ways this is a perk of the profession. It enables you to build a reputation and portfolio of work which is visible to all and legally detached from your day job. That way, even in the event of redundancy, you can easily show your worth to new employers. But, as with any form of insurance, the problem is that you have to pay in advance. Typically you pay via the time and social opportunities you sacrifice. But you also pay in monetary terms. For example, many developers invest in a home coding environment that puts their office setup to shame.

From Garth’s Experience

“Anxiety regarding ‘slacking off’ has been a constant during my career. When I was at college I would code in the evenings using languages valued in industry, in order to enhance my career prospects. As a commercial software developer I researched new and emerging tools in the evenings, and blogged about what I found. When I became an educator I spent even more time doing this to prove I hadn’t gone soft and lost my edge. As an advocate I felt the poorer for not having multiple open source projects to my name, and tried to make contributions wherever I could. Many managers I know work really hard to keep their programming skills current, but almost all eventually give up in frustration.

The underlying anxiety is not ill founded. I’ve encountered many founders, recruiters, and managers who value passion for coding over academic results or a conventional work history. With passion being measured in contributions made for free, outside of work, and for no conventional reward.

Catherine’s Response

Only you can determine your priorities in life. Perhaps your top priority, this week, is indeed to binge out on your passion for coding. It is your life and therefore your choice.

But is it? The real issue we’re examining here is feeling compelled to spend far more time facing a screen than you actually want to. If you feel that pressure then you need to find the self-assertion to create some time-boundaries that are right and healthy for you. So that programming and related work takes up only as much time in your 24/7 as you allow it, and the  time for the rest of your life is ring-fenced with mental steel.

You can make a start by spending some time listing what is really important to you in life right now (your priorities), and what is likely to be important to you over the next few years (your life goals), that, to be achievable down the line, needs some foundational effort and intention invested today.

Of these things, what will you be neglecting, or giving up entirely, in order to write code all evening? All weekend? Don’t take for granted that you can get away with neglecting That Person or That Thing, and it’ll still be available when you see fit to return your attention back in that direction. As many before you have discovered, irreplaceable Good Things can be easily lost through complacency that cannot be recovered without prolonged, intense effort. Or sometimes not at all.

Let’s start with your body. Voluntary or not, excessive hours of almost anything are not remotely good for you and, anecdotally, a tendency to migraines seem to be commonplace in the tech community, especially by mid-life. Have a look as well at the posture of the figure in the graphic at the top of this section – it’s not that far from the truth. Your body will degrade after hours and hours and hours slumped in a chair and even daily gym visits won’t necessarily compensate. “Sitting is the new smoking” may be an exaggerated scary strap-line but certainly you need plenty of fresh air, sunlight, stretching and exercise to stay mentally as well as physically well.

Then there’s your relationships. You know, other people, especially the ones visible in 3D around the edges of the screen. The fact is that the more time you spend coding, the more boring you’re likely to become to non-programmers. Maybe you already divide humanity into Coders and The Other Ones but, if not, you’ll need to invest a good chunk of your time connecting to non-tech based life. Or at least the consumer version.

Finally, there’s your self-concept. Don’t ever lose sight of who you are beyond your work, beyond your programming skills. Without either of these things there would still be a you. Over identifying your Self with your skills and achievements in one area of life means that, if that area blows up for any reason, you’re left with very little base your resilience on. We need a diverse constellation of nurturing relationships, fulfilling non-work interests, healthy habits and purposeful personal goals to absorb the impacts of unexpected losses. So do think carefully about how much time and energy you’re investing in each area of your life. Don’t put all your eggs into the same basket, woven out of lines of code.

About The Authors

Garth Gilmour presenting at GoTo Copenhagen

Garth Gilmour started coding as a teenager in the 80s. He was a full-time developer during the Celtic Tiger years before moving into education and consultancy. After leading the training team at Instil Software in Belfast for a decade he joined the Advocacy team at JetBrains. Over the years he’s taught well over 1000 courses, workshops, and seminars – using everything from CORBA to Kotlin. Currently Garth is the Learning Consultant at Liberty IT. He is a prolific speaker, writer, and co-organiser of several local conferences and meetups. When not at the whiteboard he teaches martial arts, lifts heavy weights, runs very slowly, and fights nerf wars with his kids.

Catherine Browne started her career as a Oracle PL/SQL Developer, but fell sideways into project management and from there into implementation consultancy. Over a 25 year corporate career she migrated through IT and physical security, CSR, corporate governance and ultimately enterprise risk management. She realised quickly that her natural strengths were in driving change through emphasising psychology in the successful adoption of business transformation intiatives.

Along the way she accepted that her true vocation was actually as a psychotherapist. She duly completed an integrative counselling degree and is now a BACP registered counsellor in private practice. She brings to her work a dynamism, a passion and a focus on practical change while at the same time providing the space for deep work on whatever burdens her clients need to release. She recharges by practicing Krav Maga (sometimes with Garth), lifting considerably lighter weights than Garth, messing about in her garden and trail running.

Scroll to Top