Preparing for your first job

a couple of months ago

It’s your first day at your new job. You are hired as a software developer. You get read and write permissions for the project you are going to work on. You start reading the code and as you go deeper and deeper into it, you start getting a panic attack. This is not what the college or your working alone on some project from scratch prepared you for.

First thing that you have to realize is that you are not alone. Every single programmer felt that way. We even have the word that describes that particular thing.

Impostor Syndrome

Impostor Syndrome is fear of being exposed as a fraud. While you are looking at that code, all through that process, somehow the feeling that you have tricked you employee into hiring you, gets bigger and bigger. Best way to fight that feeling, is to expose yourself. You have to ask questions.

Asking Questions

This is where a lot of us get this part wrong. We go into two different extremes. Some of us do not ask questions at all. This is wrong for apparent reasons. If you are new to some code or project, it is perfectly normal to ask questions. That is something which is even expected from you. By not asking questions, you are just feeding that impostor fear, and you feel all alone in that sensation. Not to ask questions will be bad not only from coding aspect, but psychologically also. Asking questions is pivotal in establishing yourself in the team and eventually adding value.

On the other hand, we have developers who ask too many questions. Yes, you can ask too many questions, regardless of people telling you otherwise. You will be respected more if you do some investigation first on your own, and try different solutions to your problems, and if that fails, come back with questions. You look like a competent developer if you phrase your questions like this:

I am having problem with getting a and b. I’ve tried using c and d, but that only produced e. Can you help me?

Person you are asking will be more engaged when you phrase your question like that and when solution is not something obvious that you should check first.

Legacy Project

Let’s get back to that code you were reading. You have to realize that applications that are out there, powering our 21. Century world that we know are mostly written badly. The most of them are legacy projects, they are maintained by expert beginners and the most of them have serious security problems as well.

If you are in the company that has a lot of expert beginners, you have to fight not to become one of them. This can be very challenging because, expert beginners are mostly presented as superstars in certain company and you are a newcomer. So what chance do you have against them?

This is very tough position to be in. But there is a way. You have to prove with value that your way of thinking is worth more then theirs. By value I mean results that could be easily seen.

Adding Value

Most of companies that are stagnating have applications that are full of bugs. Why? Well one of the reasons is that they are inventing a wheel. For example, lets say they have their own ORM in place, so instead of using Doctrine or Hibernate, they use their own implementation and because of that they have issues. Your value there could be to suggest a change, and not only that, but to show them, on smaller scale (not by overwriting entire project) how using this well established library will help them not to have so many bugs in production.

Second important thing is to get your colleagues on your side. You cannot do all that work if you are alone. Acting together as a team in improving some procedures that you all have problems with is essential in changing culture of company.

Small dot in space

There is a middle line here also. There are companies that are running normally and by that I mean that projects are doing fine. It is nothing exciting but it is working. Some projects have more and some of them less lines covered with tests. Bugs in production are rare. They occasionally happen, but not very often.

Working in company like that can feel that you are there as just one of the wheels and can’t really make a huge difference. To fight that, you have to be very proactive. You have to constantly come up with ways of improving code or process, but you have to be careful that solutions that you provide, really work.

Hectic Environment

Finally we have startup companies. This has two sides of the medal. One of the best part in working in startup is that you get to learn a tone of stuff and from different ranges also, and you get to learn all that pretty fast. The reason for that is that you have to learn fast. Startups are all about next release. Every single next release will be release that make investors millions. We all know that is bullshit, but that is how startups get their energy. Other side of the medal is that mental health can deteriorate quickly. Amount of stress in this situations is very high. That is why you have to be very careful and think about your health first.

Code written in this hectic environment can be very bad. Hackathon bad. Try your hardest to resist that. Resist to write bad code! Don’t be lazy! That deadline that you are given is never that strict. I am speaking from my experience. It will be worth more to the company that code is well struct and tested, then to have pushed it on time.

Real World

Real world programming is not like you see it on tutorials, where projects are written from scratch. You will be thrown into project that is already in production and making money or in best case scenario project that is not yet released but big chunks of code have already been written. Odds are that code will be bad. You will not use cutting edge technology, so don’t expect to rewrite some old PHP code to Go and I hope you are not thinking that you will change MySQL to MongoDB (do not do that even if you have opportunity). That’s expensive. Software that is working is rarely touched just for code improvements sake.

Even though, I am not big advocate for a code rewrite, and I would never recommend it, changing code just for code improvements is something you should try doing but in smaller incremental steps and that is essential into making your code better. I will be talking a lot about that in my eBook Living With Legacy Code and if you want to find out more information about the book and even get it for free just subscribe to my list and find out more.

Anel Bejtović

About the Author

Anel Bejtović

29 year old software developer and beer brewer from Mostar, Bosnia and Herzegovina, currently living and working in Frankfurt am Main, Germany.

Follow Anel Bejtović: