Intro

Teaching junior developers for several years showed me five topics in special that they need to learn. In this blog post, I will go over them and explain what they mean and how you can have a head start over a lot of junior developers. They are not ordered. All of them are important.

Scrum / Agile

Working in an Agile environment in Software Development is very common. I would even argue that you should ask in your interview if the team you will join works in an agile way. If the company says no, I would be very suspicious.

Coming back to the topic of Agile and Scrum. Agile software development is a methodology based on an iterative development process. The project is not planned thoroughly before software development even starts. You still have a common goal, but you adapt and inspect while working on the project.

One thing that developers struggle with is to understand that they are problem solvers and that they should implement the customer needs, not the needs of the stakeholder or their own. This is one of the main goals of Agile. To understand the customer needs and change the direction of the project if required.
One of the many workflows of agile is Scrum. Scrum is a lightweight framework. The industry highly adopts it, and you will work with the Scrum framework at some point in your career.

Scrum is a "Process Framework". It combines a set of best practices that must be followed to be consistent and achieve success.

"Lightweight" means that you don't have unnecessary processes and meetings. So you can maximize your productivity.

Do you want to know more about Scrum and Agile? About how a real-world workflow would look like? Let me know in the comments down below!

Cross-functional team

One thing I didn't mention in the Agile section is "Cross-functional teams".

Let's first define what a "Cross-functional team" is:
A cross-functional team is a group of people with different functional expertise working toward a common goal.

What does that mean for you?
It means that you will also work with non-technical team members and people that see things differently from you, which also includes that they see other things more important than you.

For example, in Scrum, your team will consist of

Scrum Master (SR)
Product Owner (PO)
Quality Assurance (QA)
Developers
(Optional) Architect
(Optional) UI/UX Designer As you can see, a lot of roles and a lot of different professions. You, as a developer, will also need to talk to all of them and understand them. QA will find bugs, and you will need to speak with them to get the bugs fixed.

The UI/UX Designer will speak to you because of the design and the actual implementation does not match. The PO will come to you and ask you about estimations and clarification for stockholder requests.

You will need to learn and understand all of them and also find a way to explain to them why something can not be done as they want or why it will take ages to implement. This leads us to the next topic

Handling Feedback

At University, the only feedback you got was the feedback from the professor and her/her research associate. You would get it in order and a unique way. Also, from someone who is knowledgeable in programming and does not care about UX or customer needs. This is different in the "Real world".

You will get feedback that you don't like or that will hurt your feelings because you got attached to your code, and you will think it is perfect. This comes back to the view and needs of your team members. A designer want's the website to look beautiful. QA wants to have more and better tests, and so on.

One of the tips I give to juniors is:
"Code is always temporary. Your code will change over time or will be removed completely."

Always have that in the back of your mind. This does not mean that you should write bad code. You should always write the right code that is well tested and readable. Still, don't get too attached to it.

Going back to talking to your team members. You need to understand them and learn to negotiate and explain to them your view while still assuming there point of view. I know that this at first is not that easy. In the end, you need to know that you work towards a common goal! The bring the company forward and the customer happy.

Business Savvy

One of the significant differences comparing coding at University and "Real life" is that now your software will be used by people you don't know and probably never will know.

So knowing this, you also need to understand how businesses operate and what is possible and what not. So you can increase the bottom line, and the company you are creating or working for can grow.

This also means that you have to think about what could be a quick win for the company and the end-user. This is usually done through understanding the industry you are working for. It does not matter if you have experienced it before or not.

You should get familiar with the industry you are working for. This will also help to find ways how you can improve the product your working on, and it is easier for you to think outside of the box where disruption is coming from.

We could talk more about this topic, but what you need to understand is that you now need more to think like a business, not like a student to pass a test.

Prioritization

Until now, prioritization was done by your University. The Schedule of your subjects and what you do when on that particular subject were laid out for you.

Now you are on your own. What framework to learn? What language to learn? How to learn it? How to manage your time. Also, at the business level, you now need to think about prioritization. Will you finish your task? What task should you pick next? Is this the right feature to do?

Here is what I do:

Collect a list of tasks
Identify urgent tasks and important tasks
Pick the most urgent and important task that is the least effort
Repeat until your done Would you like to know more? Comment down below!

I hope you liked that post! If you want a follow up, please comment, like and share. So I can know that you are interested in content like that!

5 non-technical skills you don't learn at university