4 ms·
Exactly! I find many (not all) younger developers respond extremely well to this more present mentorship. Also let's be real, the average project now is 10x th
by JackMorgan 2y ago
Exactly! I find many (not all) younger developers respond extremely well to this more present mentorship.
Also let's be real, the average project now is 10x the complexity of the projects when I was getting started in the late 90s. I remember my mentorship was little more than being given the pocket guide to Perl and told to read it. Also told to use emacs.
But we had no code review, version control, docker, container orchestration, no React, TS compiler, no HTML+CSS+Tailwind, no build pipeline yml, no ORM, no OOP, no unit tests. We "deployed to prod" with ftp. We ran jobs with cron.
We had a maybe 1000 lines of Perl scripts and a production database.
So it's not like there was a lot to learn. Of course a year in I still barely knew what a function was. After a year I learned PHP and made a basic website that talked to a MySQL database I on our one server.
The expectations were extremely low, there was plenty of time to putter and rework over and over.
So I try to be empathetic that this is a job that needs an extreme amount of on the job training.
- pavel_lishin 2y ago> But we had no code review, version control, docker, container orchestration, no React, TS compiler, no HTML+CSS+Tailwind, no build pipeline yml, no ORM, no OOP, no unit tests. We "deployed to prod" with ftp. We ran jobs with cron. My neck hurts from alternatively nodding in approval, to shaking my head vigorously side to side, as I go over the commas.
- JackMorgan 2y agoHaha fair enough, maybe you're not using all these things. I suspect though if you aren't doing a webstack then there is complexity elsewhere, like external API calls, message queues, enterprise service buses, s3 buckets, ML pipelines, k8s, monad transformers, SSO integration, security, distributed tracing, etc. Many systems are vastly more complex than 20 years ago. Even just system integration is a complex web. It's our duty to train our employees. I disagree with the philosophy that hires someone with <5 years in the field just to throw tickets at them like they are fully trained. I've seen so many talented engineers wither away and quit from this lack of mentorship. It's disrespectful to them. If you are a tech lead, it is your duty to spend the majority of your time training. If there are high level tasks that need to be done that only you can do, have a Jr team member to it. They obviously cannot, and will need to research the subject, learn the area, and then you can use daily review and pairing to ensure they complete it successfully. I'd prefer to have a Jr dev take a 3x to accomplish a Sr level task like SSO integration while learning the area deeply than they fiddle with some CSS while I do the SSO integration. This builds resiliency in the team. Now two people deeply understand the SSO integration. At the same time another Jr dev maybe was adding our first message queue for job processing. Again this is far too difficult for a Jr dev, but they are getting little bits of feedback throughout the process, I'm getting the message queue we need, and the team now has two people who deeply understand it, instead of one. If I'm on vacation, my entire team should be able to handle any issues, because they built it all.
- pavel_lishin 2y ago> Haha fair enough, maybe you're not using all these things. Oh, I am - just not very happily :) Not to get too into the weeds here, but I could live a long and happy life if I never had to read or write yaml that controls our build or CI pipelines, or troubleshoot layers of Helm and Kubernetes to figure out why our database migrations fail but only when running `alter` statements, or if I never had to manually search for `<FooBar` to figure out where some parameter is being passed from through twelve layers of React components down to FooBar itself. But I also remember working in a world where Junior Engineer me FTP'ed code directly to production, hoping that `index_new2.php` was the latest, correct file on the shared network drive, and that nobody erased `index_old.bak` over the weekend because I still had to port some functionality over on Monday. (Joke was on me, by Monday the numbers had already come in, and it turns out that using Javascript to do financial calculations was a Very Bad Idea, and the functionality was no longer relevant. Plus, by then, I'd forgotten whether it was in `index_old.bak` or `index2.php.bak`.)