5 things you learn as a budding software engineer
You love and hate the job at the same time. If you imagine that programmers only write clean, working code, your imagination is impressive. Programming is actually a tedious occupation. The number of lines of code is sometimes inversely proportional to the time spent thinking about the complexity of a particular problem and coming up with the solution. Sometimes the most effective code consists of two lines, and a task with the unassuming title "Simple changes to the user interface" takes eight days on a back end - and a single new column in a table is the visible result. This is not an exaggeration, it really happens that way.
Software development may be perceived as a convenient, stress-free, and well-paid office job. If one only performs this work for a short time, they will quickly realize that this is not the case. Maybe it is a question of inner attitude, but often times it is difficult to leave the office when the code is not functioning properly. We need small successes in order to motivation, "1:0 for me." Alternatively, we have the support of our colleagues. If something does not work out, then that is unfortunate. QA will most likely press Reject without hesitation. We must improve through our mistakes and after some time we will learn many things. You will acquire a variety of technical skills, experience the true meaning of teamwork, and discover some things about yourself.
Here are the most common things you come across in a few months as a software developer:
Project size
During your studies, you will have to work on several projects. In addition to your dissertation, you will have several more or less complex tasks to complete throughout your academic career. However, none of them is usually even remotely close to the systems you tinker with in the working world. It takes 57 people to develop a product. There are almost 200 repositories. The excerpt of the project you are working on - an administrative function of the main product - is so extensive that you will not have the opportunity to look at all files and functions for months.
Only finding the right place in the code to start bugfixing takes more time at first than fixing the bug itself. Conclusion: Keyboard shortcuts in an editor, fuzzy search, or plugins for certain tools are an absolute must.
Start in the middle
It would be best if we started from the beginning - even a child in kindergarten knows that. Unfortunately, that's not always an option.
When you start working at a company, you work on code that someone has been working on for years - possibly even multiple people. We add new features, fix bugs, the old code needs to be revised, another code block needs to be deleted. It's completely different from getting ECTS for completed courses during your studies - where we get a finished problem and then come up with and implement a solution.
It is also entirely different from agency work, where websites or applications are specifically made for the customer. The budget is set, there is a vision of the desired effect and a limited time. After one project, the next one comes right away. Each project starts from scratch - you choose the right tools or create a concept and off you go.
At a large company, you join the IT project of the company in the middle. And you will basically always stay in the middle.
When to ask for help and how to solve problems?
Junior Developers must have a sense for WHEN to ask for help. On the one hand, you don't want to be the one who constantly asks dumb questions. On the other hand, you don't want to waste a bunch of time with problems because you're too afraid to ask questions.
It is often said that one should first spend 20 minutes working on a problem before asking for help. Maybe you'll find the solution. If not, then it's okay to ask before any more time is wasted. However, it becomes more difficult when, after the 20 minutes are up, you don't even know WHAT to ask.
The rubber duck debugging method is useful in situations like this. Though it may sound like a joke, the point is to explain the code or issue to someone with no programming knowledge. Oftentimes, simply trying to provide a layman's explanation will help you see the matter from a new angle.
And then, when you show the problem to another developer, you have to offer a concrete explanation again. After all, it also doesn't help much if someone else has to listen to your incoherent babbling. In this way you are already getting closer to the solution. You wouldn't believe it!
Breaking down the steps into writing or creating flowcharts can be helpful in solving problems. It is also a good foundation for discussing with another developer if you need help with something.
One should not worry too much about something. First, deal with the issue briefly, then you can ask questions. Reasonable questions do not hurt anyone. Newcomers to the company often lack specific information that they would never have come up with on their own.
Collecting tips, useful information, or interesting code snippets can be helpful. If a similar problem occurs again, you can compare it with previous solutions. And later on - if a team mate has a similar problem, you can eventually help yourself.
Believe in yourself
Fresh out of college, you might lack the self-confidence that comes with professional experience. And, to make matters worse, you probably know some people who are really good at programming. This can make it hard to believe in yourself—even when it comes to something as simple as an IF statement.
But there are tons of languages, frameworks, methods and further nuances. It is not possible to know everything.
Was the study and the practical knowledge? The strongest hands-on projects during the study of software development were approximately as realistic as the game Need for Speed is helpful for the driver's license test.
It is good to be aware that it is okay to not know something. Being able to find the best solution is more important than having loads of data and programming languages in your head. And even more importantly: Even if you don't know it, you still really want to know it. You can learn and it makes it easier to be surrounded by experienced people. The wheel doesn't need to be reinvented. Knowledge transfer and tips for best practices are what you learn when you join an active IT project in progress. Then it is time to develop your skills so that you can contribute to the team as best as possible. Speaking of ...
You'll never stop learning
There are so many interesting technologies out there that a programmer never stops learning new things. It doesn't mean that one should know all languages ever invented. I also doubt that I could recite all the functions in JavaScript/Python/Ruby one fine morning. However, it is good to be familiar with different languages, technologies, and tools from which to choose - depending on the current requirements. It is always good to stay up-to-date with the languages and tools that you enjoy using.
Before I started my job, it seemed possible to me to write clean, logical code and create complex websites. When I finished my studies, I thought I could run very complex queries in SQL, or I could design a huge database.
As always, you see something new, get to know it, study it and see that this is just the tip of the iceberg.
In IT you can't say:
All right, I'm going to learn Ruby on Rails properly one time now and then I'll work with it until retirement.
Something like that is definitely not possible. The IT market is changing rapidly. New technologies, trends and languages are emerging, evolving and leaving no room for boredom.
