ProgrammerHumor
whyDoTheyDoThis
Discussion
If they estimated learning-the-app to 3 months,.maybe you oversee something?
Instead of being bored, i suggest looking only-for-you on some of the DEV taks and try to solve them locally. If you're sucessfull, you're ready. If not - well .. you still have your "learning time", and nobody is mad.
this 1000%
I think the main problem here is that you seemingly have unguided testing. If you don’t know that some functionality even exists, you’ll hardly be able to just start using it blind.
This. When I started an internship, first thing they did was tell the interns that it's release time and here's a list of a few thousand scenarios we need tested manually (they had very, very good test infrastructure and documentation). Didn't touch actual code until the final month of the summer.
Another issue with unguided testing is honestly the other direction as well; You don't get to know anything about the people working on it either.
I've had projects that felt like "We worked on this for 2 years, test it for 2 years before you know shit", just to find out that even people working on it only know how everything works if you happen to get the right 2-3 people in the same call.
Fresh starts are absolutely overconfident, but the same applies to people working in the tech field for decades when it comes to how high up the ladder they are.
Is there anyone more overconfident than a fresh CS major?
A director that has hasn't touched code in 20 years and never on the current stack.
Bonus point for "I pushed a fix directly in prod during a meeting". You know it's half baked, not documented and didn't go through the normal pipelines.
You don't know what you don't know check it again.
Yeah, was supposed to complete job security training day one and then test for a week, maybe two. Day 3: Hey guys, can we set up the dev environment? I'm pretty much bored... :D
Ive never had that. Both at very large companies and startups, from a junior and onward, the day 1 onboarding process included setting up the dev environment and opening a PR for a minor change.
Same, the concept of being tester for months after being hired as a developer seems insane.
Woah, that seems pretty crazy to me. Maybe if the whole app itself is overall pretty simple, but it seems frankly irresponsible to start a junior working on really any code without a good understanding of the app.
Well, that’s what peer reviews are for
I mean, that’s true, but come on. Should you really be writing code you couldn’t remotely comprehend?
If it is something so simple that this is appropriate, then I really don’t see the benefit. This is what onboarding is for, and it’s very important.
I mean my colleagues write code they can’t comprehend all the time so I don’t see the problem.
Seriously though, I don’t think it’s that big a deal depending on what you’re doing. Yeah contributing to a finlegal’s business logic is probably a no-go at first but making sure some text is translated is a fairly employer agnostic task that anyone should be able to tackle fairly quickly.
Yes, otherwise how will they learn?
Our onboarding has dev env set up on day 1, with an expectation to have them make a PR by the end of the first sprint. The task will usually be really simple (maybe a copy change, or fix a very simple bug, or a very easy UI change).
They will undoubtedly get lost, but that’s what their buddy is for. They’ll submit their PR and walk through it with a senior on their team or their lead.
Reading documents is fine, but having to figure out the codebase is much more valuable in building context of how things work. It exposes them to patterns in use, lets them see our coding standards in reality, and ultimately lets them familiarise themselves with the way our code works.
The PR isn’t merged until it meets standards anyway, so it might get sent back a few times before all stakeholders are happy.
Our codebase is >3 million lines in the main monolith alone. There’s dozens and dozens of additional services (depending on team).
If the code you're working with is really that incomprehensible you should maybe get your company some better coding standards.
No, even on apps with millions of lines of code with high security requirements. Its not irresponsible to get a junior to fix a typo and have the change peer reviewed.
They required us to fill out a form for every PR, explain why the typo fix wouldnt cause a security issue, fill out the details of the ticket, write a good PR with a description, etc. It was great practice to learn the workflow and no risk.
Even for a minor typo fix, the change had to be reviewed by a team lead and peer, go through 8 hrs of unit tests, and run overnight for integration tests on multiple platforms before going into staging. Then it'd go to the QA team before moving to the next steps.
Just "use the app for a while first" then commit whatever would be irresponsible.
And in the last week you'll realize you completely overlooked an entire set of cases, or found a feature you were unaware of or was poorly documented, or you made a mistake when configuring your environment and you're missing parts of the service, or....
This actually sounds like a great idea to get juniors to learn the product
Start writing scripts to improve your debug and development
Opposite for me. I had code in prod by the end of my first day, it's been a whirlwind trying to figure everything out.
You should join my company. You would be expected to push your first real PR to prod in the first week and you are primary oncall on your second month.
When I did that, I was running actual unit and regression tests so I actually was learning settings and expected behavior.
As an added bonus, we had really good test procedures, so most tests clearly failed if not set up precisely as written, so when I went too long without asking for help with a failing test, they came to check on me, and eventually decided “you know what you’re doing because you’re getting through all the tests without failures”
Quite often software is written to solve complex problems. If that software has been designed well, you are lucky and you will find yourself in a situation where you can sometimes resolve issues without having to understand the full picture. But quite often, to achieve good results it is actually better to have a good comprehension on the actual problem space. So learning the product before you actually start coding makes a lot of sense. If you are not interested in the product you are going to be maintaining and improving then maybe you are not in the right place.
Yeah I was on my current team for about 2 days before I’m like yeah just give me shit to figure out. I lead half the team now but I’m a senior lol
I guess you didn't find the bug yet.
Find at least one bug, then setup a dev environment and see if you can fix it.
At least they've let you learn the product.
Bro holding it in for far too long atp
You don't know what you don't know. Leaving a Jr. with a production codebase to "learn it" by themselves is recipe for disaster.
Bro bout to blow prod up the first day after 3 months and do 3 months worth of testing in a day
If bro can do 3 months of testing in a day, then it seems like they wasted 89 days.
When you
feel like your ass is about get fired for the first time at your first jobhave "external motivation", you can achieve incredible, superhuman feats in a day. :PThe 10x engineer secret?
2x maybe. Not 100x. That's the difference between looking at the pool, and jumping in. Which is exactly my point. Better to let them try and ensure failure isn't catastrophic than to keep on teaching them without practice hoping you'll cross the threshold when all you're doing is convincing people like OP that this place is slow and boring and there is no need to be awake.
Many organizations have good guardrails in place and require a commit to production on the first day.
Like all things...it depends I guess. But agreed that it needs more guidance in any case - not "here's 90 days, now go test"
I worked on an extremely domain specific product where devs needed to understand the components involved, purpose etc - not in terms of code, but function in the product/value to the end user to contribute anything meaningful.
To that end, getting them to do manual QA was useful because they had to understand and test stuff from the pov of the user while simultaneously understanding in that context what code caused that bug.
If we want to get their feet wet with just code, then sure, we can get them to commit something minor.
Cool. So what does manual QA mean, and how is it more valuable than triaging a bug in your scenario?