
Junior Developer Koans - webappsecperson
https://joecmarshall.com/posts/junior-developer-koans/
======
llamataboot
The student gazed at the giant monolith and was intimidated by its size.

"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.

------
duxup
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.

~~~
theyoungwolf
I would assume its the rise of the 8-12 week bootcamps that essentially mock
all those who have spent so much more time in the field.

------
teddyh
More like this:

 _The Tao of Programming_ :

[https://en.wikipedia.org/wiki/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/](http://www.catb.org/~esr/writings/unix-koans/)

And lastly, _The Tao Of Backup_ :

[http://www.taobackup.com/](http://www.taobackup.com/)

~~~
Exorus18
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 :(

~~~
woodrowbarlow
is this it? [http://stevelosh.com/blog/2013/04/git-
koans/](http://stevelosh.com/blog/2013/04/git-koans/)

~~~
Exorus18
Yes! Thanks a lot !

------
statictype
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.

Upon hearing this, the disciple was enlightened.

~~~
ravedave5
This is so dang funny. I don't even get what the message is supposed to be
exactly but I just about fell out of my chair laughing.

~~~
plausibilities
Message:

You/we lack the proper (production runtime) environment conducive to
practicing and learning this particular technique.

~~~
ebg13
Are you sure that the message isn't "micro services don't help you build mega
services"?

~~~
statictype
You cant sky dive till you reach an sufficient altitude.

You cant build microservices until youve built a monolith first.

~~~
plausibilities
bingo

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

------
cstuder
Which reminds me that The Codeless Code hasn't gotten an update in multiple
years now. :-(

[http://thecodelesscode.com/contents](http://thecodelesscode.com/contents)

~~~
jacobush
A reader of HN commented that The Code _less_ Code hasn't gotten an update in
multiple years now. He was then enlightened.

~~~
cstuder
Thank you.

------
bigbadgoose
_sigh_ … the original AI koans never seem to get exposure. Lisp based, just
deeper. Closer to the metal.

[http://catb.org/jargon/html/koans.html](http://catb.org/jargon/html/koans.html)

~~~
stoksc
Every koan post I’ve seen has had these in the comments.

------
mooreds
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.

------
sevensor
Shouldn't a koan embody a paradox? These are more wry observations than koans.

------
_pmf_
> “Generate a react app without scaffolding” instructed the Master.

> 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.

~~~
pdpi
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)

~~~
BossingAround
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.

~~~
pdpi
Again, lead vs mentor.

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.

