Junior Developer Koans
joecmarshall.com
joecmarshall.com
"Break it up" the teacher instructed.
And so the student broke the monolith into many pieces, and then became confused by how all the pieces fit together.
"Put it back together" the teacher instructed.
And so the student rebuilt the monolith, fat controllers and all, but she was not scared, neither of the many pieces, nor the size.
In the networking land if I saw someone's messed up VLAN config I'd sit down with them "Hey man I see what I think you wanted to do, let's talk about what we want to do here and some other ways to get you what you wanted here."
In the dev world (particularly online) I often see citations about something silly jr. dev does as just being "bad", but those things are what people do... while they're learning to do it better. So some guy fires up create react app to quickly put together an app, maybe he didn't have to, maybe it was somewhat less efficient to use CRA, but in doing so he learns a ton about react outside of the scaffolding and etc. Being a not so great dev is also what you do while learning to be better.
I'm not at all sure if the purpose of these Koans here so maybe I'm off topic, but that's just an observation of mine.
The Tao of Programming:
https://en.wikipedia.org/wiki/The_Tao_of_Programming
Rootless Root — The Unix Koans of Master Foo:
http://www.catb.org/~esr/writings/unix-koans/
And lastly, The Tao Of Backup:
The master jumped off his chair and landed head-first on the floor.
"What happened!" ask the disciple.
"I'm learning how to sky dive" replied the master.
Upon hearing this, the disciple was enlightened.
You/we lack the proper (production runtime) environment conducive to practicing and learning this particular technique.
You cant build microservices until youve built a monolith first.
well, you _can_, but IME having a reference monolith to excavate will likely net you significantly more reliable, holistic, and consistent requirements/specifications information than whatever the fuck comes out of the product guy/gal's mouth
> The student could not.
He could, how ever, BCC his team lead's boss that he's being put on useless tasks that only serve to give the team lead a sense of superiority.
Frankly I welcome someone who wants to teach me something I don’t know. As long as they’re not obnoxious (which is, thankfully, rare)
It must, however, come from the side of the mentee, not the mentor. If you _want_ to teach someone something, that will always come off bad, from my experience. As a junior dev, I used to hate this slightly senior dev (same position, but has been with the company a year longer) trying to teach me stuff, and saying things like "yea, do this, at least you'll learn how to do it", assigning me useless little things that I did not need in my daily work. In the end, I had to tell him that he's in no position to assign me anything, and I had to talk to my manager about this colleague thinking he can assign me things (practically, I said 'this has to end or I'm out). Things got significantly better after that.
"I used to hate this slightly senior dev [for] trying to teach me stuff"
Why do _you_ think you're being downvoted?
Fuck... This has angered me much more than I thought it would have. But ok, rather than thinking "huh, I wonder whether I came off as condescending to my less experienced colleagues", let's enjoy the mindless downvote and feeling of justification in one's old ways. In the end, that's what matters; no introspection, just confirmation.
As both lead and mentor simultaneously to a junior developer, the suggestions I give him are very _very_ different depending on which role I'm playing at the time, and I make it abundantly clear which role is speaking at any given point in time.
This is precisely the sort of suggestion many juniors need to hear from their mentors (because there is real value in understanding the difference between deep and shallow knowledge, and the role of tooling), but is of course a terrible task for a lead to give a junior (because it's a pointless waste of time as part of a production project)
I don't know what OP meant, but I assume that's what he was driving at.
The mentor/mentee relationship isn't usually a formal one enforced by your workplace — it's one built over time, when a less experience member of the team trusts somebody more knowledgeable, and seeks them out for advice. Any such suggestions are usually meant to be taken as as side projects, not as work tasks.
A lead giving you a task like that is probably inappropriate, because they should be focused on producing results. They should, instead, try to find low-hanging fruit that's within your reach. For a mentor, however, it's entirely appropriate to tell you to do something "useless" because the real goal isn't the end product, but the learning experience.