Hi everybody, I just got a friendly reminder – an annual HR talk with my boss – that my graduation is now more than two years in the past. Time again to reflect upon what I learned during the last two years and how that differs from what I expected.
What I expected from my first Job
Phew, maybe I should have written this two years ago. If my mind is not playing tricks on me, I remember that I was a bit afraid of what I have to learn and all the things I don’t know. I already knew that I am going to write a lot of code with a framework (Spring Boot) that I had no previous experience with.
Also I was quite aware that there will be a lot of people in the team that I didn’t know back then. At least I got to know one of the developers in the past since we went to the same university (although graduating in different years).
So what did surprise me during the two first years. And what I would consider 10 things nobody is telling you when you get your Computer Science degree:
1. You can learn things pretty quick in a supportive environment
I would say the developers onboarding me did a good job introducing me to the tech stack. What they did after pairing for a while was to just throw me in at the deep end.
After around a month I got a task to write my first own service. To be totally honest, I guess it took me way longer than I and others expected. Still it taught me a lot of valuable lessons. During this time all developers were very supportive. I just wanted to make sure to make a good impression and was reaching out just when I was totally stuck or needed some feedback. This loop of building things and getting feedback of others while also having the duty to review pull requests really helped me to learn and grow a lot during the first and the following months.
2. It is not only code
Ok, I think I could fill the rest of the article just repeating this. But I want to give you different perspectives on this statement. Just let me say for now “It is not only code”
3. There is a business to understand
Besides the technology, there is also a business which will be new to you. For me this was the connected cars industry and the whole ecosystem around it. They were so many providers of APIs. There where APIs to get user data, to get data about vehicles, there was an API for everything.
Sometimes people tend to talk a lot within well accepted acronyms or technical terms. That is not any issues – only when you are new and have no clue.
When I started out, I wrote many of them down and noted what they meant. I already lost that piece of paper but I make sure that when I use them everybody understands it. Sometimes I am also not aware of this gap when talking to new people in the project, but normally you should see it in their faces if they came along something they don’t know the meaning of. Also it helps to regularly encourage new people in the project to just ask in case they don’t understand something.
4. It is also about people
You will interact with people to plan, discuss and do your implementation. There will also be meetings with different stakeholders of the code you are writing. You will have to report to your boss, you will have to gather requirements from other peoples, you have to adjust your implementation with your colleagues. All this will be part of your everyday job. One day it will be more meetings and one day it will be less.
5. You need to protect your time
As mentioned in the previous point, there will be a lot of interactions with other people. What I didn’t understand at the beginning is that you have to be really protective of your time. Your time while being on the job is limited. To a certain degree this is a blessing and a curse.
When you are not protective about your time you will not finish much while being on the job, probably taking work with you at home or having peer pressure because work you are assigned to is not getting finished on time.
6. There are different kind of schedules for different kind of people
Think I had to learn this the hard way: There seem to be different kind of schedules for different kind of peoples. An awesome article which really impressed me and left an impression about this topic is “Maker’s Schedule” by Paul Graham.
He describes the difference of a Manager’s Schedule and Maker’s Schedule in a way that a maker (e.g. a software developer) is more affected by meetings. For managers it is more often “just another meeting”. He probably can have a lot of back to back meetings and is still not feeling too bad about it.
When a Maker has a meeting, it might be affecting the whole day. This is because he is planning his day in bigger blocks of time because more often it feels hard to do anything meaningful within an hour.
Lessons learned:
- Protect your working week to have at least a few 3 to 4 hour blocks to get stuff done.
- Try to plan meetings at the “edges” (start or end of your working day), prefer back to back meetings over meetings with 30 minutes gaps.
7. Office Politics – A game you can only win by not playing
More often you hear things being said and discussed on the hallway or just at the water cooler. I am not standing here and saying I am not involved in discuss things and things about people there. But: You should always be aware of it and be really cautious about what you say to whom. I try to keep away from such things, since in my eyes there is not a lot to win there. What I like to discuss in such spots is things about tech and ongoing projects and tasks.
8. Enjoy the silence, do some deep work
This might be harder than you think. If you have your own office this might be not an issue. But trust me, I work in an open office environment and for me it is sometimes hard to concentrate. This is because there, you often get interrupted by colleagues asking some nuances or the in general high level of noise.
If you need to ask your colleagues a small thing, try to switch over to asynchronous ways of communication. Write them a mail or write them in a text based chat tool if possible. This gives them the possibility to come back to you when they are finished focusing on their own task.
When your office environment is too loud, you could try to get some headphones with active noise cancellation. These are awesome when it comes to blocking out distracting sounds from your environment. Also they are a good indicator to other people to leave you alone for a while and better use some asynchronous ways of messaging to reach out to you. Sadly I have to admit that I for myself try to get away from the habit of just directly asking colleagues. It is just too easy to ask questions in such an environment. The laziness to save a minute might kill many more minutes of your colleague’s productivity.
9. You will learn to love things you didn’t know you will love
For me this was about taking responsibility for our architecture. At my workplace I am currently leading our Backend Guild. In general this is about organizing the guild meetings, discussing with other developers about how we want to implement things and also to make sure that we stick to the things that we agreed upon (e.g. Best Practices or Standards).
What I love about this is that I can help people when they are stuck. Often when people get stuck it is either a very thankful thing to help them or it is a really hard problem to solve. Either way – it is really satisfying and rewarding.
I think I more or less picked up this duty when we had the issue that our lead developer was more involved in another project. Instead of complaining about it, I tried to make the best of it and helped by stepping in. Overall I do not regret that decision.
10. Tests, tests, tests
Tests are so important. Even if you think you don’t need tests because you tested your code properly by hand. A manual test is fine for verifying your logic. The thing it is not helping you with is regression. You can not test all previous things you implemented each time you change a single character in your code.
What you actually can do: Write tests which do that for you automatically. So for me, tests are not only proving that your current stuff is working, but also that no further modifications will break your implementation unnoticed.
Keep in mind: Tests are protecting you against regression.
Bonus: You should think about Code you write
Last point, I promise. For me it was kind of a mindshift when I realized that I will come again and again back to code I have written in the past. The best code is code you didn’t write. Meaning that you verified your requirements and then realized it doesn’t make any sense to do it. When I need to write some code, my priorities shifted from writing clever code to writing code that is clever in a way that it is “easy to understand”.
When doing code reviews, most of the findings I nowadays have are about lacking tests (or the lack of them), or just too complicated logic which is hard to understand. I like the sentence “Don’t make me think” when it comes to understandable code.
Summary
During my first two years I learned a lot about different aspects of software engineering. After my two first years I think I can say I am glad that I ended up with programming and also with my current employee.
I hope you will have or had already a similar experience. Wishing you the best!
In case you think I could add something to the list – feel free to reach out via twitter.
Kind regards,
Marcus
About the Author:
