I remember all too often getting caught up in the process of completing feature after feature. It’s easy to check a box, complete a task, and move on to the next one. But don’t forget: you’re not a human code generator nor a specification-document paster. A button here, a reverse chronologically sorted list there… buy why? I’m constantly reminding myself to take a step back to ask myself — and my team — why we are even doing a task in the first place.
The biggest challenge I had as a junior was justifying why we were implementing features to begin with. With maturity that changed, but I’m still surprised that so many juniors come into the world of software and are excited to just… close tickets. These folks must be wired differently than me.
I’m still surprised that so many juniors come into the world of software and are excited to just… close tickets
Because a) we want to prove that we can do work and get things done b) we want to learn new things and get experience. Not all tickets are opportunities to learn something new, but many are. Moreover, the productivity of a junior engineer is more directly correlated to how many tasks they finish than a senior engineer’s. The more you advance in your career the less it matters, but I’ve had more success as a junior engineer in terms of raises and getting respect by closing tickets efficiently.
The biggest challenge I had as a junior was justifying why we were implementing features to begin with
This is a skill that is learned with time, as you said. For better or for worse, in many companies the junior engineers are not tasked with deciding whether a feature is needed or not. In more traditional or downright bad cultures, a junior asking why we need to build X at all (as in, discussing its necessity, not just out of curiosity) might be seen negatively. It’s usually the person above the junior engineer who’s the one that decides what feature gets put on the sprint or what is not worth our time.
–
Note that I still agree with the article - you should know why you are building every feature and not work in a vacuum. But as to why people don’t question every feature and just want to close tickets - most people just want to do a good job, get experience, get paid, and go home. So we close tickets and go home.
I’ll emphasize your answer by saying that not all tickets/features deserves challenges from a junior. Sometimes, you just trust more senior people on the subject, and trusting your peers is a great skill to learn too. You just have to be careful not to code without understanding the context (but sometimes you can just skip this part and still learn many things as stated by the previous commenter)
The biggest challenge I had as a junior was justifying why we were implementing features to begin with. With maturity that changed, but I’m still surprised that so many juniors come into the world of software and are excited to just… close tickets. These folks must be wired differently than me.
Because a) we want to prove that we can do work and get things done b) we want to learn new things and get experience. Not all tickets are opportunities to learn something new, but many are. Moreover, the productivity of a junior engineer is more directly correlated to how many tasks they finish than a senior engineer’s. The more you advance in your career the less it matters, but I’ve had more success as a junior engineer in terms of raises and getting respect by closing tickets efficiently.
This is a skill that is learned with time, as you said. For better or for worse, in many companies the junior engineers are not tasked with deciding whether a feature is needed or not. In more traditional or downright bad cultures, a junior asking why we need to build X at all (as in, discussing its necessity, not just out of curiosity) might be seen negatively. It’s usually the person above the junior engineer who’s the one that decides what feature gets put on the sprint or what is not worth our time.
–
Note that I still agree with the article - you should know why you are building every feature and not work in a vacuum. But as to why people don’t question every feature and just want to close tickets - most people just want to do a good job, get experience, get paid, and go home. So we close tickets and go home.
I’ll emphasize your answer by saying that not all tickets/features deserves challenges from a junior. Sometimes, you just trust more senior people on the subject, and trusting your peers is a great skill to learn too. You just have to be careful not to code without understanding the context (but sometimes you can just skip this part and still learn many things as stated by the previous commenter)