5 year roadmap for young interns


(Les Way) #1

Hi all,

I need to create a 5 year plan/roadmap, that I can show to young interns, in which I detail all the things they should be learning in the next 5 years in order to master go.

So the first things that come into my mind:

  • go syntax
  • go formatiing & clean code
  • testing and CI/CD best practices
  • goroutines & channels design pattterns
  • datastructures & basic algorithms in go
  • code review best practices
  • general design patterns
  • common architectures of go web apps

Can you please help me with things that one needs to learn in order to become a good developer ? I fear that I am missing some chapters.


(Ivan Matmati) #2

Five years ? You can become the next world champion of Golang in five years. So it seems impossible to feed someone for five years of learning. But clearly they should learn project structure and building, cloud native app, interaction with other languages (as library client or library producer), web application (REST and RPC), os interaction (syscalls), …
I can’t imagine all you can learn in five years.


(Les Way) #3

Hi @imatmati

The goal is to become a senior developer starting from a junior (no experience) position.
Sure, “app, interaction with other languages (as library client or library producer), web application (REST and RPC), os interaction (syscalls)” are useful, but how do they synergize with other fields ?

I am trying to make a roadmap where there is a high continuity, like first you learn A, and then using that knowledge you can learn step B, and so on.

With the continuity and the senior developer goal in mind, what can one learn in 5 years. Surely not all the subjects mentioned so far (not enough time even if he learns on all his free time).


(catacombs) #4

I found this Go roadmap immensely helpful. It’s not in the five-year range you’re inquiring, but it does tackle things people should know about the language.


(Les Way) #5

Hi @catacombs,

This roadmap is very impressive ! I can clearly see that its authors have put in a lot of work and have produce somthing very useful.

But it stops at middle level, it seems that the are more things to be a senior level developer. Any ideas as to what to add to it ?


(catacombs) #6

If you mastered everything on the roadmap, I’d say you’re more than senior level in Go and an attractive candidate for employers.

Remember, the language is still fairly new, so there might be more features and uses that’ll arise as the Core team continues developing it. When those features come out, you jump on and learn them.


(Les Way) #7

Hi @catacombs,

No doubt that if you master, or at least have medium knowledge on the majority of those field in the roadmap, you are an attractive candidate for any employer.

But senior level means a bit more. For example it also involves some:

  • general IT non go skills
  • some people and communication skills
  • a little bit of architecture
  • deployment and maintannace
  • cloud
  • scalability
  • data handling
  • UX design
  • estimation theory

I feel this discussion is geeting more and more productive ! Lets add more to the list.


(catacombs) #8

I’d be happy to talk about Go, but everything else you listed is best suited for a different thread (perhaps on another forum) about how to build skills needed for senior-level developers.


(Sebastian Hennebrueder) #9

In my opinion, senior knowledge cannot be achieved sequential. Understanding design patterns for example meant for me

  • reading books and understanding the book but not the pattern as is
  • coding without design patterns
  • ‘over patterning’
  • seeing how to much pattern leads to overdesign
  • seeing other using to less and to much design pattern
  • doing code reviews
  • learning more about refactoring to design pattern
  • refactoring bad code
  • refactoring more bad code
  • refactoring more bad code with team members
  • seeing other team member dealing with over engineered code
  • reading the same books again
  • building a balanced understanding of when and when not to use a pattern

Those things repeated themselves multiple times. As I am coaching dev teams, this has a simple consequence that in order to build up skills in design pattern, it is good to have a long term goal and approach this goal over time from various perspectives.

IMHO it is useful as well to explore a bit what the items in your list mean. For example regarding design pattern: Just naming them can be achieved by a junior in very short time. It is more difficult to explain why to introduce a design pattern at a specific piece of code and which trade offs you will encounter if you do it.