Thanks, this is a nice POV, and sounds about right. Once I’m there (wherever that is), what should I strive for? Being in a small team with a dedicated person to ask things? Or being alone so that I ave to do everything myself, i.e. learn to do everything?
That’s the problem I see with going small, by the way. I think having a ‘mentor’ (or something as close to one as possible) would be really good for my learning, but show me a startup that can afford more than a week or two of onboarding time; I’d be afraid they just show you the basics and leave you to struggle alone.
My current model is that people usually learn better by having to figure things out IF they don’t just break down under the stress. If you aren’t too stressed out by feeling lost and confused and having to figure it out on your own, and/or you can handle the stress, then that’s probably the way to go. But for a lot of people, one or both of those conditions do not hold.
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.
Thanks, this is a nice POV, and sounds about right. Once I’m there (wherever that is), what should I strive for? Being in a small team with a dedicated person to ask things? Or being alone so that I ave to do everything myself, i.e. learn to do everything?
That’s the problem I see with going small, by the way. I think having a ‘mentor’ (or something as close to one as possible) would be really good for my learning, but show me a startup that can afford more than a week or two of onboarding time; I’d be afraid they just show you the basics and leave you to struggle alone.
My current model is that people usually learn better by having to figure things out IF they don’t just break down under the stress. If you aren’t too stressed out by feeling lost and confused and having to figure it out on your own, and/or you can handle the stress, then that’s probably the way to go. But for a lot of people, one or both of those conditions do not hold.
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.