It is a lottery. You may meet awesome experts. You may also meet people who know less than you do, but have high status within the company, because they were hired 1 year before you and they suffer from a strong case of Dunning–Kruger syndrome. Often it’s something in the middle: people who have lots of experience and lots of strong opinions, some of them wrong, but they generally get the job done.
I am not sure how typical is my experience, but I learned most when I first spent some time in a team that worked with some technology, and later was alone or almost alone on a different project (sometimes in a different company) that used the same technology. Within the team, I learned what are the right tools to use, and what can be done with them; later alone, I had to connect all the pieces, and fully understood the big picture.
Without previous team experience, I wouldn’t know which technologies to use. It is difficult to make a good opinion on a technology without using it first, and there is not enough time to try them all. You need luck; or a trustworthy expert who already tried them. Popular opinion is unreliable, because many people are stupid, so they praise or condemn things for wrong reasons. Also, if many people complain about X, it may be because X is shit, or it may be simply because many people use X (probably because it does its job well).
On the other hand, if you work with a more experienced team, the important decisions are made by someone else (sometimes before you join the team), the infrastructure is already set up, and you can develop within the existing project, but you never know whether you would be able to set up a similar project from scratch—and that’s a difference between junior and senior developer.
Make notes. Remember that when you change jobs, you will never see your old code again. Today, if you need to make e.g. another controller, you probably look at the one you made a month ago, and follow the same structure. One day, this will not be an option. But if you make notes and keep them… you create something like your personal Stack Exchange. (Don’t copy existing parts of code, especially ones containing business logic, that would be illegal, of course.)
If you have enough free time, try getting information from sources outside your job, so that if your colleagues do some things right and some other things wrong, you have a chance to get a second opinion. On any topic, there probably already exists a book; read it. Read the official documentation. Read the ancient classics, such as The Mythical Man-Month, Clean Code, Design Patterns.
Try to create a “hello world” project at home, using the same technologies you use at work, or replacing commercial tools with free ones (e.g. PostgreSQL instead of Oracle Database). This project you can legally keep after you quit. Now you kinda play the role of a senior developer, only without the stress and deadlines. If you can’t solve something, it means you don’t understand the same thing about the project at work, so you can explore it, or ask your colleagues. You can also try new technologies at home.
The disadvantage is that doing this seriously takes a lot of extra time. When you get older and have kids, this will not be an option anymore. Hopefully by that time you will have accumulated enough knowledge and experience to survive on 8 hours of work a day, maybe even retire early. This is a reminder that if you work hard, you should also negotiate for your salary hard, because your current level of hard work may be unsustainable in long term.
It is a lottery. You may meet awesome experts. You may also meet people who know less than you do, but have high status within the company, because they were hired 1 year before you and they suffer from a strong case of Dunning–Kruger syndrome. Often it’s something in the middle: people who have lots of experience and lots of strong opinions, some of them wrong, but they generally get the job done.
I am not sure how typical is my experience, but I learned most when I first spent some time in a team that worked with some technology, and later was alone or almost alone on a different project (sometimes in a different company) that used the same technology. Within the team, I learned what are the right tools to use, and what can be done with them; later alone, I had to connect all the pieces, and fully understood the big picture.
Without previous team experience, I wouldn’t know which technologies to use. It is difficult to make a good opinion on a technology without using it first, and there is not enough time to try them all. You need luck; or a trustworthy expert who already tried them. Popular opinion is unreliable, because many people are stupid, so they praise or condemn things for wrong reasons. Also, if many people complain about X, it may be because X is shit, or it may be simply because many people use X (probably because it does its job well).
On the other hand, if you work with a more experienced team, the important decisions are made by someone else (sometimes before you join the team), the infrastructure is already set up, and you can develop within the existing project, but you never know whether you would be able to set up a similar project from scratch—and that’s a difference between junior and senior developer.
Make notes. Remember that when you change jobs, you will never see your old code again. Today, if you need to make e.g. another controller, you probably look at the one you made a month ago, and follow the same structure. One day, this will not be an option. But if you make notes and keep them… you create something like your personal Stack Exchange. (Don’t copy existing parts of code, especially ones containing business logic, that would be illegal, of course.)
If you have enough free time, try getting information from sources outside your job, so that if your colleagues do some things right and some other things wrong, you have a chance to get a second opinion. On any topic, there probably already exists a book; read it. Read the official documentation. Read the ancient classics, such as The Mythical Man-Month, Clean Code, Design Patterns.
Try to create a “hello world” project at home, using the same technologies you use at work, or replacing commercial tools with free ones (e.g. PostgreSQL instead of Oracle Database). This project you can legally keep after you quit. Now you kinda play the role of a senior developer, only without the stress and deadlines. If you can’t solve something, it means you don’t understand the same thing about the project at work, so you can explore it, or ask your colleagues. You can also try new technologies at home.
The disadvantage is that doing this seriously takes a lot of extra time. When you get older and have kids, this will not be an option anymore. Hopefully by that time you will have accumulated enough knowledge and experience to survive on 8 hours of work a day, maybe even retire early. This is a reminder that if you work hard, you should also negotiate for your salary hard, because your current level of hard work may be unsustainable in long term.