Something like 2-3 years ago I've read similar thing with master foo but about git. Does anyone happen to know where I can find it? I've searched for it but failed to find :(
Educating people is awesome, amazing, and should be applauded.
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.
What I said was I said was I used to hate a dev on practically in the same boat acting extremely condescending to me. That's a huge difference. If this has become the standard of HN discussions, I'm really sad.
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.
Because it's not owed to you to not be condescended to. If someone more experienced takes their time to teach you something, you should learn. If you don't want to learn, fine. But complaining that you weren't spoon-fed carefully enough is to not realize there are millions going hungry. How many people out there are _desperate_ for a mentor, even a condescending one?
Mentor/student is not the same dynamic as lead/junior.
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)
For me, personally, of course I expected different treatment and different tasks when I was a junior. However, if I were given a task just for the sake of having a task (i.e. "create X, then feel free to delete it"), that would be hugehly demoralising (as in, "you don't trust me to do even a basic useful thing? We have to start at a basic useless thing?")
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.
There are teams, that don't need to use scaffolding provided by "create-react-app". Maybe they just need a small react powered widget on their site, it would be silly to scaffold whole separate project just for that widget. Also, if you are using React as your primary tool, you should actually know, how to set it up manually.
I only wish there were more. I have been thinking a lot about junior developers and how to meet them where they are. Once you've been around the block a few times it is hard to put yourself in that mindset, but in order to help them be effective and efficient (and to keep them around) it seems like you have to.
As a jr. dev who recently changed careers from something else technical to web development I have a bit of a concern about how the attributes of a jr. dev in web development are often portrayed as inherently negative. I feel like I see this far more in the development space compared to my past career (networking). This is just my impression, i'm a n00b, so I'm not at all sure how widespread it is.
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 young disciple entered the temple and prostrated 3 times before the master and asked - "I wish to know the way of Microservices. I wish to glean insight on how to build them as it will let us scale and build rapidly".
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.
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
33 comments
[ 2.6 ms ] story [ 78.6 ms ] threadhttp://thecodelesscode.com/contents
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:
http://www.taobackup.com/
> 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.
"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.
http://catb.org/jargon/html/koans.html
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 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