5 ms·

I'm still cleaning up after the unsupervised junior two years later. To me, the definition of junior is someone who needs guidance. If you don't have a good pr

by rvense 2y ago

I'm still cleaning up after the unsupervised junior two years later. To me, the definition of junior is someone who needs guidance. If you don't have a good process of defining tasks before they're worked on and real code review before things get merged, you are not set up to work with juniors, and hiring them is doing both yourself and them a huge disservice.

grumpy_coder 2y ago
100% this; unfortunately also often seeing junior devs called staff after job hopping for 3 or 4 years never really learning anything. Junior job titles are nearly as much of a mess as interviewing them. Particularly in recent hot topics like AI the reality is you want both experienced and less-experienced devs. Most AI teams I see actually lack AI experience and keep falling for the same issues (like quickly getting to 80% working and thinking just a bit more data to 99.9%)
- theshrike79 2y ago
  1 year of experience 4 times vs 4 years of experience
  - rvense 2y ago
    Yarh, I thought about this a lot when recently our electric cargo bike passed 10.000 kilometers. It is used, almost exclusively, to bring our son to school, 5km away.
- f1shy 2y ago
  In the Company I work, I constantly find architects, senior and chief architects, who come directly from the university, without any real world experience… sooo nice to work with them
gavmor 2y ago
Seems to me like "the unsupervised junior" isn't participating in the "Socratic method" the article discusses, but your experience does impugn the author's hypothesis that the burden of Junior Developers will drive out a better process ( as a forcing function) eg your "real code review" and "good process of defining tasks".
- rvense 2y ago
  It might in a lot of places - if anybody even notices that there's a problem and if they then have the political capital to change it. In this case, nobody really kept an eye on how things were being built, and the person was actually remarkably productive. I really don't have a bad word to say about them: they were given vague tasks and came back, for most of them, with working implementations. We're only a handful of people and everybody was busy elsewhere, but what little guidance and review we could offer was always accepted with much gratitude. They lasted about 18 months before moving to somewhere that offered more support, and I can't blame them at all. What happened is predictable: things that ought to be in one place end up distributed in little pieces, and existing features got invasively modified to add new features even when that wasn't necessary. Poor separation of concerns, design patterns applied wrong, all of the stuff that over time adds up to a codebase that's hard to work with. I think a lot of the refactoring we do would make a good book, actually, if any of us were the type to write about programming.
  - gavmor 2y ago
    > I really don't have a bad word to say about them ...doesn't quite square with: > I'm still cleaning up after the unsupervised junior two years later. I can appreciate that misfactored code now helps "flatten the curve" and skirt under whatever deadlines you were respecting——even at the cost of a long tail of reactors——but its a shame that junior dev isn't around to learn from their mistakes, and also that they weren't paired with a more senior dev who could've coached them through those reactors at the time, enriching both the codebase and the human capital.
    - rvense 2y ago
      They did as well as they possibly could in that environment. The mistake was our lack of supervision, nor their lack of experience.
randall 2y ago
amen to this
runeblaze 2y ago
This is a bit confusing to me because I am quite sure nearly everyone <10 YoE needs guidance one way or another. Similarly almost every dev needs real code review. Without code review everyone breaks things all the time.

by rvense 2y ago

grumpy_coder 2y ago

100% this; unfortunately also often seeing junior devs called staff after job hopping for 3 or 4 years never really learning anything. Junior job titles are nearly as much of a mess as interviewing them. Particularly in recent hot topics like AI the reality is you want both experienced and less-experienced devs. Most AI teams I see actually lack AI experience and keep falling for the same issues (like quickly getting to 80% working and thinking just a bit more data to 99.9%)

theshrike79 2y ago
1 year of experience 4 times vs 4 years of experience
- rvense 2y ago
  Yarh, I thought about this a lot when recently our electric cargo bike passed 10.000 kilometers. It is used, almost exclusively, to bring our son to school, 5km away.
f1shy 2y ago
In the Company I work, I constantly find architects, senior and chief architects, who come directly from the university, without any real world experience… sooo nice to work with them

gavmor 2y ago

Seems to me like "the unsupervised junior" isn't participating in the "Socratic method" the article discusses, but your experience does impugn the author's hypothesis that the burden of Junior Developers will drive out a better process ( as a forcing function) eg your "real code review" and "good process of defining tasks".

rvense 2y ago
It might in a lot of places - if anybody even notices that there's a problem and if they then have the political capital to change it. In this case, nobody really kept an eye on how things were being built, and the person was actually remarkably productive. I really don't have a bad word to say about them: they were given vague tasks and came back, for most of them, with working implementations. We're only a handful of people and everybody was busy elsewhere, but what little guidance and review we could offer was always accepted with much gratitude. They lasted about 18 months before moving to somewhere that offered more support, and I can't blame them at all. What happened is predictable: things that ought to be in one place end up distributed in little pieces, and existing features got invasively modified to add new features even when that wasn't necessary. Poor separation of concerns, design patterns applied wrong, all of the stuff that over time adds up to a codebase that's hard to work with. I think a lot of the refactoring we do would make a good book, actually, if any of us were the type to write about programming.
- gavmor 2y ago
  > I really don't have a bad word to say about them ...doesn't quite square with: > I'm still cleaning up after the unsupervised junior two years later. I can appreciate that misfactored code now helps "flatten the curve" and skirt under whatever deadlines you were respecting——even at the cost of a long tail of reactors——but its a shame that junior dev isn't around to learn from their mistakes, and also that they weren't paired with a more senior dev who could've coached them through those reactors at the time, enriching both the codebase and the human capital.
  - rvense 2y ago
    They did as well as they possibly could in that environment. The mistake was our lack of supervision, nor their lack of experience.

randall 2y ago

amen to this

runeblaze 2y ago

This is a bit confusing to me because I am quite sure nearly everyone <10 YoE needs guidance one way or another. Similarly almost every dev needs real code review. Without code review everyone breaks things all the time.