Working In The Industry

There are a few things I think worth discussing about working within the industry that are not really technical but more psychological, but effect you nonetheless.

There is a bit of real world examples and opinions in here, I only mention it as its things I have seen on my travels and it feels they are worth openly talking about, if you don't like them just move on.

Imposter Syndrome

Not everyone suffers from this, and not everyone who does suffer from this ticks all the boxes for the syndrome, but it is a frequent thing in the technical industry that a lot of people to some extent feel some level of anxiety around their own abilities especially against the frequently moving technical industry.

What Is It?

You can google it for more information but it's basically the feeling of being a fraud or in this industry often feeling you are not as good as you need to be, or just generally not knowing enough to be a real developer.

One of the worst things about it is that the more you learn about technologies/practices, the worse the anxiety can become. For example if all you know is a single language i.e c#, all you would worry about is

"am I a good c# developer, can I really do this new role?"

The more you learn outside of purely coding and about the larger technical world such as testing, releasing, architecture etc the worries compound and become worse as there are more facets to worry about, especially given roles are asking for more and more known technologies outside of just doing the code.

Historically a developer was expected to just do some code, but now they are expected to do code, understand build systems, be able to write and maintain automation tests etc. Then the higher you go the more responsibilities you are expected to fulfill and it can be really overwhelming.

How To Combat It?

If you do suffer from this there is no silver bullet to solve the feeling of anxiousness, but realistically most companies/projects only require a specific skill set, and even if you don't know everything 100% you can often skill up quick enough to be competent.

The mere fact you worry that you may not know enough shows that you can assess yourself and potentially see weaknesses and think on how to best solve them. Also most roles will expect you to have a ramp up time to things and if you are a pragmatic person you will be able to ask the right questions and fill any knowledge gaps when needed.

The way I think about it even if I am not the greatest dev in the world, I hopefully know enough to be useful to whoever im working with, be it an open source project or a company paying me. I have worked as a dev for over 15 years and have worried about almost every role I have taken, and every one has been fine and I have known more than enough to help the team in some way.

Look at it this way though, if you have been doing a development job for a while, be it junior, senior, lead and you are looking to go for a new role, what really is going to be that different? If you have successfully been a developer in one place, you will probably be a successful developer elsewhere, just assess where you may need to learn new things and just have a look into it.

How To Deal With New Roles?

There are loads of roles out there these days from engine developers to mobile automation testers, but not as many skilled technical people to do the work. So one thing to remember is that YOU are a commodity which is often in high demand and you can use this to your advantage when looking for new roles.

What If I Hate The New Role?

Well given there are loads of roles out there just apply to another one and leave. At the end of the day this is your life and these are your skills to use how you see fit, if you are not happy in a role then don't stick around there.

There is often the sentiment that you owe something to your employer or a team, and in reality most companies will not care about you, so do not put their needs above your own. The staff may, and hopefully you will make friends and be happy there, but technical companies often fold or change and these changes are not always for the better when it comes to you.

I'm Being Asked To Do More?

This can manifest in a few ways, be it more work in the same time frame because of deadlines, or being asked to take on more responsiblity without any additional benefit to yourself.

Whatever the scenario you need to think about if it would make you happier to do it or not, in some cases maybe it would be good to take on some responsibilities for some new tech/process which would give you more of a chance to use it in real world scenarios and upskill. However in a lot of ways it could also just mean you are expected to do more in less time.

However you feel about it just remember that your time is your own, if you feel that doing this is going to set you up for fail, or it's going to put a plaster over a problem in the company/team, just say NO.

Imagine you hired a brick layer to build a wall, then asked him if he could also sort out a few plug sockets on the wall hes built. I'm sure he COULD do it but why would he? you are not paying him for that, and if something went wrong with the plug sockets you are going to phone him up and ask him to fix them, so why would he put himself in that situation for no benefit?

Learning New Things

This is also part of being asked to do more, and in some cases you may be asked to learn a specific tool from a 3rd party, or a specific technology to do a new facet of your role.

In some cases this may be fine, i.e they are moving from webpack to rollup and you need to learn a bit about it, or they are moving from Youtrack to Azure Devops etc, so you are just going to be using a similar tool to fulfill the same job as you are already doing.

The key thing to ask here though is WHEN are you meant to be learning about this new thing, is there training provided? are you meant to learn in your own time? do you learn on the job?

Knowing what is expected of you will at least let you know how you want to handle the situation, and in reality if a company is wanting to drastically retool in an area or move technology, you saying "I don't want to" won't really change anything, but at least you can assess if you want to stay at this place doing this role.

Real World Example

For example a place I had previously worked at changed from C# to Java and changed a lot of tooling around for their back office work, and also moved from near one city to another to attract other developers. They expected people to commute to the new office and just change over and start using a different language and eco system.

It is worth noting that sometimes this makes sense at a business level, so being angry at a business for trying to be more efficient or productive is pointless as it's what they do (lets not go down the rabbit hole of the ethics of this), but in some cases its a new CTO coming in just wanting to make an impact, and knowing the difference can be useful.

Some people were happy at this, as there was some subsidies offered or transportation assistance to new offices for a period and they wanted to learn these other technologies. A lot of other people were annoyed that they were no longer doing the role they signed up for and the more back office people had to learn a niche 3rd party tool vs a common open source tool.

So some of them stayed and just lived with or embraced the change of role, some left over time to go back to doing what they wanted, but ultimately people had to decide how to handle this huge change the company was imposing on them.

The world still turns regardless of what you or your employer/team decide to do and even if you part ways etc, but just remember that you are in control of your career. If anything that is the CRUX of this whole chapter, YOU ARE IN CONTROL, don't worry about it.

Being Approachable

It's not my job to tell you how to be, some people like to focus 100% when they are working, others like to just relax and do bits of productive stuff here and there, at the end of the day as long as stuff gets done it shouldn't matter.

However there is something to be said for being approachable on a team, it is more likely to make others happier which makes the whole team happier and it's also going to generally make everyone more productive if they can openly chat to each other about technical issues or possible queries.

Deferring Problems Makes More Problems

So one problem that sometimes comes up around this is that some people don't like being bothered and to avoid being bothered by someone with a 5 minute problem today, will schedule a 15 minute meeting tomorrow. Also this has probably taken you about 5 minutes to do anyway as you need to crack open your calendar and look for available times etc when you can fit it in.

This snowballs the more you do it, so if 3 people ask you for help throughout a day you end up having 3 meetings the next day, which means anyone the next day who asks for help will end up having to wait more and before you know it you end up having a day full of meetings where you cant be bothered starting any work because you always have a meeting in 30 minutes time.

This whole problem can be avoided if we just take time to help others when they need it, not only does this mean you can probably spend less time on the issue as its fresh in the askers head, but also you are not delaying them 24 hours just because you want to stay in the zone a bit longer.

Also lets face it, none of us are disarming bombs or doing brain surgery. If you take 5 minutes break and lose a slight amount of productivity for the greater good, no one is going to notice, if anything you will be praised for being very helpful and also save yourself effort in the long run as you wont be perpetually creating your own meetings to solve problems you would never have had in the first place.