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!
👋Say Hello! Instagram | Twitter | LinkedIn | Medium | Twitch | YouTube
Top comments (6)
I think the first one you don't really learn at varsity or need to relearn is communication. Especially how to communicate technical concepts to non technical people.
True, you need to learn how to communicate.
I covered this a little bit in the cross functional team section :)
Proper use of Code Editors! I've never seen classes that would give the programmer to be a good overview of the different editors and teach their proper usage. When people are left on their own, they often fall into the IDE crutch programming style. It's a crutch because they can't seem to be able to use other, non-IDE based editors. In my opinion, this slows their ability to adapt and grow.
Good point and yeah begging efficient at using editors is also a must.
At my university, it was not a subject but professors would show us how to do things without an IDE and then teach us how to do it in an IDE so we could do it faster but we first needed to understand how to compile for example java code in the command line and then setup the IDE later.
I actually think that you do learn "handling feedback" at some Universities. I know this is not popular for developers, but doing other activities during college can help provide this. Something like a competitive club sport will give you this and sometimes in a more intense way than you get after college.
Yeah but it's not like a subject at university.
And usually, the only feedback is from the professors because other students kind of doesn't care.
I did sports outside of university ;)