A short story about the IT career

A short story about the IT career

Many people often ask what does it look like to work as a software engineer and what can you expect after being in the industry for a few years. I’m not going to focus on the actual job or the tools required to get it done, instead, I’ll present my subjective insight into the career in the broad world of the software development.


 

Let’s start from the very beginning – you start your first job (or an internship) and feel so excited about it that you can barely sleep. I’m talking here about writing the actual code either solo or with the rest of the team, which leads to the ultimate goal – creating an application for the end customer. You’re being thrown into this dark and unknown space – it’s not terrifying per se, as the more experienced team members are rather friendly folks in general.
Yet still, it’s like you would get out of the rocket after landing on the moon and was asked to collect some minerals without any practical experience. On the other hand, you could find here some Armstrongs walking around and doing their job properly – a good starting point to learn from. This is how the first real job looks like (not only for the programmers I guess) and at least for the next few weeks, or more like months, you feel like there’s so much to do and so much to learn about.

Hello there, rookie software developer.

Hello there, rookie software developer.

Depending on how big is the product you’re working on and what is the size of a team, you might get more or fewer responsibilities and the actual freedom in terms of writing the code and using the appropriate tools. Then, you start discovering the design patterns and want to use the repository everywhere along with the custom caching implementation based on the singleton. Isn’t it what you’ve just learned from all of the MVPs while studying the tutorials found online? You’re having a really difficult time to understand why the N in the N-layer solution doesn’t go towards +inf, as the more projects and more abstractions is the better, correct? Eventually, you tend to believe that you’re so good programmer that quite rarely need any help from the other team members.
There are some good sides, though – using the repository like Git seems to be a much better idea than sending the source files to your friends using the messenger, the build server are more suited for the deployment processes than directly uploading zip archives via FTP and following some of the methodologies like Scrum or Kanban might get you out of trouble and provide some sleep on the weekends. And most likely you’re getting the real money for the job, but sometimes you still don’t understand why not so much as the other guys.

Hammer is the best tool for solving all of the world problems.

Hammer is the best tool for solving all of the world problems.

What happens next? Let’s say after a year or two, you start to realize where you were at the beginning and why the team/management/boss quite often were not into some of your brightest ideas. The design patterns are not a hammer anymore that you’d like to use everywhere it’s possible, more likely they’re becoming a specialized tool that you start to choose carefully. Your solution structure has maybe 2, 3 or 4 layers – it turns out that the more doesn’t always mean the better and some of the “abstractions” in code that you wrote in the past now give you a terrible headache. The code doesn’t look like spaghetti anymore, however, it’s still far from being perfect.
What about the team members? Actually, not only they start to listen to your remarks and ideas, but actually, they might consider them as a viable solution, plus depending on the organization structure you might get an invitation to some meetings with the management. And yes, your salary is probably much higher now than it was before.

Later on, having 3-4 years experience you’re getting closer to becoming a senior software developer (honestly I hate this notation, years of experience don’t really mean much as you might as well have 5 years of so called “experience” doing the same thing over and over again or e.g. 5×1 year of experience which is much more valuable).
You’re almost one of the most important guys on your team, right after the tech leader and the rookies look at you like a kind of demigod. Although, by this time you should already know how to write a really nice, clean and maintainable code there are other tasks that you might or might not like.

This is the team. You either succeed or fail as a whole.

This is the team. You either succeed or fail as a whole.

Let’s talk for a while about the new responsibilities. At first, by being one of the most experienced developers in the team it is your duty to provide a help for the guys with much less experience. If you don’t like helping or talking to the other people, you should really consider changing your job (or going freelance solo in your basement), and I truly mean it.
How would you feel like if at the beginning of your career (while you were walking on the moon trying to collect the minerals) one of the Armstrongs in your team would kick you out and well, let the gravity take it from here?
So in general – don’t be a dick, try to be as patient and helpful as possible. The thing is that even after 4 or 5 years being a software developer there’s still so many subjects to study on that you don’t want the bad karma to hit you back hard while asking a smarter guy for advice.

And what are the next steps? That’s a very good question, especially because that’s the point of my life where I’m currently at. If I were to count all of my working hours during the last few years (regular job, freelance job, side projects etc.) I guess the outcome would be like 6-7 years of experience.
Do I feel like I “demigod” now? Yes and no. Yes – because after many years of writing the code, you tend to switch your mentality into designing the ideas that are sort of language agnostic.
I do believe that this is one of the most important aspects of a good software engineer – given the problem, you can think of a solution that will be the best fit to make it happen.
The implementation part is still important, yet since it’s your natural skill (just like using your regular language while talking to the people) you’re more attractive to the employers due to the fact, that you can actually become a problem solver (or system architect) on top of being a good coder.

You start thinking about the solution in general, not just a code.

You start thinking about the solution in general, not just a code.

And why there’s still some hesitation left? It may sound trivial, but the more you know, the more questions you start to ask and then realize that you merely know anything.
However, that’s a very good thing. Why? People often say that they feel burned-out. Personally, I’ve heard that burnout was a cool game created by the Electronic Arts.
Once you start to feel that your job makes you angry or you don’t like it anymore, just change your job. Take a few weeks or months off, learn something new and apply for another job. Maybe try to set up a company with your friends and look for the customers to make the software on your terms (and design patterns).
It’s that simple, and please, don’t say that you don’t have money or you’re afraid. It’s so easy to get good money in the IT, and if you don’t have any savings I feel really sorry for you.
Last but not least, about the “quitting your current job” part – no risk, no fun. Do you really believe that things will suddenly get better? Have you ever heard about the insanity? It is “doing the same thing over and over again and expecting different results.” – said by the great Albert Einstein himself.

To quickly summarize the most important points about working as a software developer in general and how to make your everyday job a pleasure or even start pushing your career to the next level, I’d like to point out a few important things:

  • Don’t act like you know everything – you don’t and you never will.
  • Ask for advice if you’re uncertain about something, this is what the team is for.
  • Be friendly and helpful to other team members and people in general. Don’t blame others for their mistakes – they simply might don’t know that something is wrong.
  • Just because you know a particular technology/language/framework/library/tool it doesn’t mean you have to use it everywhere. Don’t be afraid to try the new things.
  • Same goes to the design patterns and other programming principals in general. It’s great that you’re aware of them, yet it doesn’t mean that you always need to make use of them.
  • Working solo as a remote freelancer? Get out of your home and find some coworking space.
  • Don’t lie to your team or management if something can’t be done on time. Truth may be harsh, but it’s always the best choice.
  • Take responsibilities for your actions. Set up some standards or rules and stick to them – that’s what the professionals do.
  • Don’t like your current job? Simply quit it, but never burn bridges – don’t act emotionally even if you hate everyone in the company.
  • Don’t be afraid of change. Take some time off, get familiar with a new technology, improve your skills (not only programming, e.g. the soft skills are also very important), maybe try to find your own customer.
  • Start blogging, tweeting, posting your content on reddit or hackernews etc. Create your side project and even better make it an open source one (or contribute to the existing ones) – you may love it like I did not so long time ago.
  • Go to conferences, local developers group meetings and so on – talk to the people, and who knows, you might find a great opportunity here that will literally change your life.

1 Comment A short story about the IT career

  1. Georgy Grigoryev

    >Don’t be afraid of change. Take some time off, get familiar with a new technology, improve your >skills (not only programming, e.g. the soft skills are also very important), maybe try to find your >own customer.

    You can combine it with your pet-project

    Reply

Leave A Comment

Your email address will not be published. Required fields are marked *