Eh, I agree with most other commentators, saying that it's quite dissappointing and fairly confused why it got 300+ upvotes. Probably the influence of google.com domain. I even double checked the URL if it's not some publicly editable page that happened to be under google.com.
If I had to pick one tip for a junior developer, I'd say slow down when it comes to adopting methodologies, techniques and use your own judgement. What's the benefit of doing? What are alternatives?
When you learn about OOP design patterns, it's easy to suddenly see them everywhere. Factory here, singleton there, and with a bit of imagination observer goes here. Not everything should fit into one pattern or another. One of the benefits of the patterns is that it might make the solution cleaner, easier to understand. If it increases the complexity - don't (or at least think more about it)!
When you learn about Agile (although nowadays it's a very ambiguous term and loads of stuff goes under this label), it's tempting to start organizing standup meetings, plan everything under sprints, assign story points, do TDD, etc. But think twice before going for it. What do you get back? Maybe the morning standups are not beneficial for the team, and just distracts everyone? Maybe story points are not worth the overhead of agreeing on, allocating them, etc and your team can do just fine without them?
If some methodology doesn't really stick to your team, maybe it's an indicator that they are totally fine without it? For example, maybe you haven't had a morning standup for a week and no one has brought it up, everything's going smoothly. Not saying that the listed methodologies are wrong, they are not, just sometimes they are not beneficial.
Same goes for a new language, a new promising framework, etc.
If I had to pick one tip for a junior developer, I'd say slow down when it comes to adopting methodologies, techniques and use your own judgement. What's the benefit of doing? What are alternatives?
When you learn about OOP design patterns, it's easy to suddenly see them everywhere. Factory here, singleton there, and with a bit of imagination observer goes here. Not everything should fit into one pattern or another. One of the benefits of the patterns is that it might make the solution cleaner, easier to understand. If it increases the complexity - don't (or at least think more about it)!
When you learn about Agile (although nowadays it's a very ambiguous term and loads of stuff goes under this label), it's tempting to start organizing standup meetings, plan everything under sprints, assign story points, do TDD, etc. But think twice before going for it. What do you get back? Maybe the morning standups are not beneficial for the team, and just distracts everyone? Maybe story points are not worth the overhead of agreeing on, allocating them, etc and your team can do just fine without them?
If some methodology doesn't really stick to your team, maybe it's an indicator that they are totally fine without it? For example, maybe you haven't had a morning standup for a week and no one has brought it up, everything's going smoothly. Not saying that the listed methodologies are wrong, they are not, just sometimes they are not beneficial.
Same goes for a new language, a new promising framework, etc.
Be critical.