This applies especially to large enterprise projects where there are lots of moving parts, and lots of business logic to learn. You are brought on a team, and you are told that there is a lot of load currently on the lead, and ideally, you will be helping alleviate some of that load off the lead. Turn-over is high at these projects, and any gained subject matter is lost when the resources leave. Turns out, your lead is a one-trick pony, who became a lead due to his technical skills, but his documentation keeping skills are abysmal, and his mentorship, and teaching skills are even worse. The lead has conveniently placed himself in a position over the last 10 years, where he's worshipped by the business for his vast knowledge. You, hopeful young Padawan, eagerly pick up all the given tasks, hoping for growth, but that's never going to come. You're being purposely given donkey work, without any context. Your lead wants someone he can unload tasks to, but you will be working on things where you don't even know why you are working on them - like an insignificant little cog in the machine. After months, or perhaps years, everything will finally "click," and you will tell those who are junior to you to be patient, and that it takes time for it to all make sense. This is oftentimes bullshit. It's not so much that it takes time, but rather, an inordinate amount of effort which was put in by you to just hang on, without switching jobs. There was a better way, an that better way was a lead who was actually involved, and interested in your progression. A lead who actually set up systems in place by which information could be digested in a progressive manner. Perhaps, an actual system-analyst like role at the company whose job was to not simply write oodles of SharePoint documentation, but have ScrumMaster like qualities, where they checked in on whether the team was actually growing or not. Management needs to understand that this is an opportunity which can not only get resources up to speed faster, but also curb attrition. The lead is taking his sweet time, letting you coast (which is not doing you any favors), and staying in his comfort zone, while wasting company resources. And when you are not up to par, who gets to be put on the chopping block? You. Not the lead. It's never the lead. The lead will simply restart the cycle with a fresh batch of eager junior devs. Every so often, a blackened soul among these junior devs will rise within the ranks, and repeat the same practices that his absentee-mentor "taught" him....
Time to get a new job lol
literally me đ© I want my time back
I try to "give back" by giving junior devs the direction/tutorials that I never got.. saving them DAYS of pain...
Yup! Same here! After a decade it has 'clicked' but maybe too late :( I too try to give all the unsolicited advice to junior devs warning them of this exact same trap
used to be on a team of ~15 with two distinct factions: 1. the people who had been at the company for 8+ years, who were nice people but instinctively hid information and would not document anything 2. a rotating cast of 2-4yoe devs who used it the job as a springboard management was upset that new people wouldn't stay but if you don't onboard people well and don't invest in their careers...
You hit it on the nail, with that example.
Dude, you have the code base right there in front of you, just start learning portions of it. Sure, bad documentation might slow you down but it should not block you completely. You should still be eventually able to understand it. And its completely fine to complain about poor documentation when you join, but if youâre still complaining about it one year down the line then youâre part of the problem.
Few more tips: GIT commits are stored as history, you can always look at the leadâs code changes in the past to understand whatâs going on. Start correlating it with JIRA tickets and try to understand the code changes.
This isn't a stand-alone program where the "code being in front of you" is all that you need. There are heavy dev-ops concerns, multiple access requests, and tickets which need raising in a specific format. Caveats which apply.... I could go on.. but the point is.. that you are not given this information in an easy to digest manner. You are given bits and pieces... Yes.. it will all make sense in a year... but it *could* have made sense in a LOT less time. That's the point of the post.
TL;DR ?
TL;DR: Invest in a proper learning progression for your devs. There ARE ways to save months of that learning curve with proper instruction.
TLDR/TC/GTFO
World Conflicts
Yesterday
468
Why I Find Free Palestine Inspiring
India
Yesterday
662
'Hindutva': The Radical Hindu Ideology That Seeks to 'Push Christianity Out of Indiaâ
World Conflicts
Yesterday
533
Is "From the River to the Sea" So Wrong?
Personal Finance
Yesterday
1212
Thank you AAPL and NVDA
Tech Industry
Yesterday
1664
Do people underestimate E6 role at meta?
get good lmao
That's exactly what the lead would say.... But it's hollow advice - and it doesn't hold the lead accountable, whatsoever. "Getting good" in some places involves jumping through made-up hoops, and purposely placed obstacles. That's the entire point of the post.
got it