
Ask HN: How to work with a developer who avoids reading? - scandox
Someone recently joined our team as a junior dev. Their work is good, but I noticed that when they&#x27;re learning something new they generally watch a video. Often it seems to me to find out how to do something that is effectively a couple of lines of code. I asked them about it and they said they remember things better when they visually see the effect it has.<p>Also there are times when I ask a specific question like &quot;What does such and such a library function return?&quot; and they&#x27;ll say &quot;two strings&quot; but don&#x27;t know if it&#x27;s a list or a tuple, of if it ever returns None, or whether it raises an Error etc. So at that point I&#x27;ll open up the library documentation and read it with them. But they will never on their own initiative open the docs. They do read SO and tutorials.<p>I&#x27;m struggling a bit to collaborate with them because I have a strong bias towards reading (docs or books) to understand and they seem to have the exact opposite. They seem almost sad when I send them a link to raw information.
======
scarface74
_What does such and such a library function return? " and they'll say "two
strings" but don't know if it's a list or a tuple, of if it ever returns None,
or whether it raises an Error etc._

I program in three languages in any given week, not to mention using
CloudFormation where every resource type has its own configuration. Why would
I try to remember what a function returns off the top of my head?

For instance, I do a lot of work with Python and Boto3 - the SDK for AWS
([https://boto3.amazonaws.com/v1/documentation/api/latest/inde...](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html)).
Why memorize what any of the literally hundreds of functions return when I can
just call the function and inspect the response within the IDE?

~~~
that_jojo
I think OP's point was that the person gives a vague answer off the top of
their head instead of checking the doc to see what the actual concrete type
is.

~~~
danielg6
If a dev stopped me from working on something to make me look up some
documentation for them that they can easily look up themselves, I’d be sort of
annoyed.

If the extra info in the documentation wasn’t actually important to the code
implementation, I’d be more annoyed.

If the goal of asking is to help me grow as a dev, please directly tell me
what it is I need to learn.

It seems like the OP is just as vague as the junior dev when it comes to
communicating.

If the senior dev saw something in the junior dev’s code and thought it was
important to look at the documentation, why not just tell the junior dev that?
Why does the senior dev have to tiptoe around and ask leading questions?

~~~
markbernard
It's called "training". Teach a man to fish or give a man a fish.

~~~
danielg6
Yes, why not actually train the junior dev?

------
manjunaths
> Also there are times when I ask a specific question like "What does such and
> such a library function return?" and they'll say "two strings" but don't
> know if it's a list or a tuple, of if it ever returns None, or whether it
> raises an Error etc.

I am curious to understand why you need to do this step? Is it possible to
have a more hands off approach?

Give them a task and a deadline and then let them come back with the work. If
they have a problem, then they can come to you, but if they have not done
their home work, then they need to solve it themselves. Is it possible this is
too much of involvement in their work?

> So at that point I'll open up the library documentation and read it with
> them. But they will never on their own initiative open the docs.

How about telling them that they need to look it up (either in front of you or
after they need to return to their station)? Would that work for you?

> I'm struggling a bit to collaborate with them because I have a strong bias
> towards reading (docs or books) to understand and they seem to have the
> exact opposite. They seem almost sad when I send them a link to raw
> information.

Maybe they associate this and what follows with a negative experience? Is it
possible to take a more hands-off approach? Sometimes it helps to appear dumb
to the person we are mentoring. Let them figure out the steps that are figure-
out-able like reading API docs etc., Only help in steps that really need your
expertise and experience, but not effort.

I think this is because this is how the current generation thinks. I am
mentoring some interns and my own kid thinks looking up YouTube for the
solution is the right thing to do. They in fact search on the YouTube app on
their phone and then go to Google.

------
mooreds
The real question is are they effective? If not, that is the thing to focus
on, not how they learn. If so, who cares how many videos they watch.

I will say that I think it nay hinder long term career growth and should be
given as feedback either way. But that can be more informal (a conversation
like "I noticed you seem glum when I send you a link to the docs. Was
wondering why?").

~~~
GVIrish
Who knows, maybe they have dyslexia or anxiety with reading or something.
There might be a good underlying reason for the avoidance.

Either way I think the most relevant factor is as you said, are they
effective? If they are, it's up to them how they learn.

The only other thing is that I might explain to them why it's important to
read documentation so that they don't get surprised by gotchas.

~~~
azeirah
Yeah, before I got diagnosed with ADHD (and got meds), I would only read
documentation in special situations, as a last resort; ie, almost never.

------
0xDEFC0DE
>"What does such and such a library function return?"

I'll just say that I usually don't memorize library functions intentionally. I
let it happen naturally. If I use a function a lot, it'll get remembered.
Usually an IDE/auto-complete module will have that information anyway. C# has
spoiled me immensely.

That said, you should really promote reviewing the docs for a particular thing
after watching a video. Ask them to experiment with this and see if they like
it. I think this will help that type of learner cement their knowledge. Use
both, not one or the other.

The other concern is potential security gotchas which usually aren't covered
in videos/tutorials and not mentioned in auto-complete, especially if they are
skimming the material to just get work done: they will disengage as soon as
their brain gets what it wants from the video. Ask them if they are checking
the dates on these things, because it could easily be out-of-date but still
stuck high on Google's results.

~~~
raducu
I've found that I usually don't even memorize class names and method names
even when I use them somewhat frequently; what I memorize is
shortcuts/keywords that help me navigate to the actual code.

------
rygxqpbsngav
As an experienced dev, I can glance at an API documentation and start coding
to use or work with it instantly. But when you take a junior dev, they don't
have enough knowledge of basics to comprehend the documentation. E.g let's say
the documentation mention concepts like CORS or closure etc, they have to
understand those and this only comes from experience over the time. What they
are doing, like reading SO and tutorials help them to collaborate in-line with
the timeline with experienced devs. As and experienced dev, you can slowly
coach them through discussions to develop his overall basic knowledge on a
tech or concepts which over the time help him take your approach.

------
danielg6
Based on the OP’s comments and word choice, it seems like the OP needs to work
on his communication if he wants to work effectively with the junior dev.

Have you directly told and then shown the junior dev that reading
documentation might make implementing a 2-line code change easier or quicker
than watching a video?

Do you want to know what a library function returns for your own benefit? If
so, look it up yourself. Why ask the junior dev?

As a senior dev, if the point of asking what a library function returns is to
help the junior dev grow, why not just explicitly tell them what they need to
look for (different outputs, errors being raised), explain why those things
are important, and then show them how to find/use those things? Maybe the
junior dev seems sad because you just randomly send them a link without
providing any guidance in how to parse it? Maybe they seem sad because you’re
communicating to them in ways that show to them that you doubt their
abilities.

You said that you have a strong bias towards reading and the junior dev has
the opposite. But you said that the junior dev does read in the previous
paragraph. Hmm.

Can you imagine this same post being written from the junior dev’s point of
view?

------
hprotagonist
Encourage them to read and REPL side by side.

Someone once taught me that the right way to read a math textbook is with the
book on the left hand side of the table and a pencil and stack of paper on the
right.

Coding seems similar.

------
jperry
I don't understand the problem at all.

You say that the quality of their work is good so why does it matter if you
learn things in differently?

------
nelsonic
The simple fact is that while learning from videos is " _nice_ " it's _not_
the most effective way of learning _advanced_ topics which are usually not
covered or diving into code/docs to gain a deeper understanding that is
_never_ covered in videos.

Three _irrefutable_ facts worth reminding the "junior dev" of:

1\. Most learning is not captured in videos. (so if you rely on them as your
only source of knowledge acquisition, you will _always_ be "behind" your peers
and have incomplete knowledge)

2\. Videos go "stale" when new versions of code come out, "living" _textual_
docs can be updated and thus always current.

3\. Text-based knowledge is far easier to find/reference than videos which
makes it easier to lookup quickly when needed. Trying to remember which video
you vaguely learned something 6 months ago so you can look it up again and re-
learn is super time-consuming.

~~~
scarface74
Learning to write code in any language is not an “advanced topic”. Advanced
topics are around architecture, concepts, and ecosystems those can easily be
taught by a video. It’s much easier to watch a video where the screen is split
between the code and the results of running the code.

2\. If a framework is bring iterated so fast that a less than year old video
is stale - that framework is probably at the “peak of inflated expectations”
part of the hype cycle and most likely should be avoided.

3\. Most good videos also come with a corresponding git repo.

------
Ahmed90
Some people are visual learners and some people are readers, you can't make
him/her change to 100% reading just like that, it's how their brain functions,
suddenly switching to reading is harder than you think.

I'm a visual learner myself, I would watch a little video on x2 speed or go
directly to a code snippet and move on, yes it's bad and I've got my ass
bitten by this few times in my early days, so I forced my self to read the API
references, the docs, and/or source code at least around what I need to use in
my code and it's getting better with time.

Don't be upset and don't try to force it, he's/she's a junior, advice/push
them to read the API references or the source code, keep sending them the raw
info they will adapt, just don't hate the fact that they are "visual learners"

~~~
fooblat
Are you aware there is little to no evidence to support so-called learning
styles[0]? While it is true that some people may have a preference for a one
modality over another, there is no indication that anyone learns more or
better when taught in a preferred style.

0\.
[https://onlinelibrary.wiley.com/doi/abs/10.1002/ase.1777](https://onlinelibrary.wiley.com/doi/abs/10.1002/ase.1777)

~~~
Ahmed90
Where did I say "they learn better"? I almost said the same thing it's how
their brain works "aka enjoys/likes to receive information"

I really hate the "throw a research paper at them" approach we are talking
about a human... a preference of watching vs reading if someone is not
comfortable with reading you don't hate/force them.

I'm a 5th-grade dropout... I'm not used to reading large books I get bored
after 10 min and I won't learn shit if I'm bored, even videos are boring for
me that's why I use x2 speed.

It's not a black and white subject there is dyslexia, ADD, ADHD, and a huge
list...

------
agildehaus
Why in the world would you care if someone knows the exact return type of a
function? I intentionally don't try to remember such useless things.

------
radicalbyte
I've always been a reader but for the last couple of years I've found that the
videos on Pluralsight do a far better job of introducing a new framework in a
concise way when compared to the best rated books.

My experience learning compilers and automata theory was similar. I had
trouble slogging through the Dragon Book but I flew through the Coursera
compiler and finite automata courses. After that the Dragon Book was an easier
read (although I never finished it as there are better modern books on the
subject).

Once you're up and running the documentation is usually better.

I assume that this is because most books are either targeted at inexperienced
developers or are purely API reference material.

------
durnygbur
Ability to filter the knowledge one injests is one of the skills which makes a
capable engineer. Reading with understanding and fluent expressing oneself in
writing are essential. I did encounter many, non only junior level,
developers/contributors learning mostly from the first 1-2 pages of Google
search results returned on 2-3 keywords - articles from Medium (someone is
looking for a job and posted bunch of articles for visibility), video with the
latest framework-influencer, or from the latest Cloud-provider marketing
event. So called blog/influencer-driven development - it's exhausting.

------
dazhbog
I think it this is normal. I remember early on I would watch videos and shitty
tutorials about servers and libraries, but slowly you begin to seek and trust
the spec/standard. But only when you are more advanced you can do that.

As a beginner you are not looking for the source of truth just yet. You are
not ready to look into CPU registers and read the code. All you want is to
discover what you don't know. Hence you look at videos and SO questions that
have _meta-data_ and advice attached to them, like "dont use goto/eval" etc.

------
jmilloy
I think it would be helpful if you gave a better example of a time where you
struggled to collaborate.

The examples you've given serve well to demonstrate that you prefer manuals
and documentation while this person prefers examples and videos, but they are
not really examples of attempts to collaborate nor of a struggle.

Folks here have been critical of these examples, but a more generous
interpretation would be to acknowledge that _of course_ it can be difficult to
mentor or work with someone with a very different approach.

Sounds like this could be Python. Since this person remembers things better
see the effect, I think an improvement over videos would be exploring new
material in ipython or a Jupyter notebook, where they can discover through
autocompletion and get immediate visual feedback. Another would be to pull up
specific bits of documentation through an IDE. Maybe you could show them how
to do those things, so that they can get the information they need efficiently
but in a way that they are comfortable with. But this would only be an avenue
to help you depending on the actual things you and this person are struggling
with.

------
supr_strudl
I had the exact same problem with a junior dev. I blogged about it here
[https://hadalin.me/blog/how-to-become-a-better-
programmer](https://hadalin.me/blog/how-to-become-a-better-programmer)

Too many people take the path of least resistance and want to deliver quickly,
because hey, who wants to spend time reading the docs, it's so boring. But
that's just one of those things you have to do. The best programmers I worked
with all share the thirst to go deep when they start using a library or
framework. They spend a significant time reading the source code and the docs
until they have a clear mental model how the thing works. The outcome of such
approach is very few surprises when running the code, because the code behaves
how you think it should behave.

My advice would be to mentor the dev of potential problems that would arise if
you only partially understand how the library works. The most obvious are bugs
or worse, you go against conventions and end up rewriting the whole app
because it becomes unmaintainable.

~~~
mondaygreens
_The outcome of such approach is very few surprises when running the code,
because the code behaves how you think it should behave._

And when it doesn't, you know exactly where to look to find the problem and
often its solution.

For me that's the biggest payoff of reading the documentation or skimming it
multiple times, it's a huge time saver when things inevitably go wrong.

Then there's also the ability to think within the whole scope of the lib as
opposed to the specific thing you pulled it in for.

~~~
supr_strudl
Exactly this.

------
Angostura
What's the culture and workload like? Do they have the time and space to think
about learning things for their own sake, rather than to solve an immediate
problem.

Perhaps sit them down and explain that being a junior dev is job of two halves
- delivering immediate value to the company, but also developing _themselves_
and their craft so that they can do away with the 'junior' tag.

------
arandr0x
I'm also a reader, and in my experience devs who don't feel comfortable with
reading (most of them) tend to get better information flow through talking,
unfortunately they're about as likely to be shy as other devs and sometimes
don't get a lot of professional development because of this.

Get in the habit of talking to them about code casually. ("Have you seen the X
library", "I implemented another splay tree today, whoah!") I also send
juniors youtube links unless they've expressed they don't like video, there's
now a bunch of solid technical content there, better than books in terms of
being up to date I would say.

A ton of people watch videos sped up 1.75x or 2x, and young people often are
in the "classroom" mindset that everything where they are a passive receiver
is made of gold and benefit from being explicitly told they can skip parts,
watch vids out of order, speed up and then slow down, etc. This may help
conserve his time.

------
DarkWiiPlayer
Give them some code to debug that fails on a technicality of one of the
involved components. This is good practice and will help them understand why a
formal definition of what something does can help you where a tutorial or
stack overflow answer often can't.

------
watwut
Let him learn his way and don't micromanage that. Don't go out of your way to
search for videos for him either. When you have good text that cowers what he
needs, sent that text.

You two should not need to learn the same way and have same preferences to
collaborate.

------
Insanity
I have been in your situation.

Honestly though, not everyone learns in the same way. I have known this person
for about 15 years and I can't say it has hurted his career at all.

(I have worked with him on several projects in these 15 years).

Just let them learn how they prefer to learn. ;-)

~~~
AnIdiotOnTheNet
> Honestly though, not everyone learns in the same way.

I'm not really sure this is a true statement. In my experience people merely
_remember information_ with different efficacy for different techniques. I
suspect we all _learn_ \--that is, create an effective mental model of
things-- in more or less the same way, which is by supposition, testing, and
refinement. Maybe that's just me being biased towards my own mechanism though?

~~~
Insanity
Agreed, I should have perhaps said a different _preference_ :)

------
CareyB
Two things:

1\. We read much faster than we speak, so watching a video is massively less
time-effective. If the junior is doing this on company time, they’re costing
money.

2\. There was an article somewhere about a dev exhibiting these ‘symptoms’.
Turns out they were barely competent. Their entire method was to copy code
they found on the Internet, and paste it in. They were entirely incapable of
writing code from scratch. The article went on to elaborate that, after
extensive (expensive) coaching from the senior dev who authored the article,
the person turned out to be a pretty good developer. They just started their
career trying to advance by gaming the system.

~~~
scarface74
1\. It depends. If I’m learning a new framework, language, or technology, I’ll
generally watch a video to get an overview. This will generally tell me the
_what_. When I start working, I might not remember the _how_ but I’ll look
that up. Whether it’s fair or not, a lot of companies look down on learning on
the job - especially watching a video. I’ll ususlly watch videos at home and
just read docs for specifics at work. Most of the time you can cobble together
the template of a solution from code you find on line and modify it if you
know what you are looking for.

2\. The poster said “Their work is good...”. If their work is good, why does
it matter the how?

------
tyingq
Have them write unit tests for a few functions until they reach some high bar
for coverage maybe? That would seem hard to do without reading formal docs.
And might show why they are _sometimes_ important.

------
scarcely
Do you RETAIN the answer you find in books? Maybe they only need to watch the
video once and can retain it forever because the rich visual stimuli gives
them so many different neural pathways for recall.

------
aqibgatoo
The problem is today people learn programming by watching videos. When they go
in a professional environment this knack of learning by videos remains there.
I have suffered from it, and i attribute it ti video tutorial for everything
sickness, but it hurts when there is no tutorial for the thing you are trying
to achieve, then oneself is forced to read documentation to do the thing.

------
gremlinsinc
I'm the complete opposite and always have been, i can't get past 1-2 videos,
before I'm tired/bored. Give me a project/task and then some api docs or
guides and I'll read/scan/trial and error the shit out of it till I accomplish
my goals.

------
fiblye
Videos are an effective way of learning for many people. I personally hate
them, but I also sometimes end up struggling with trying to figure out
concepts on my own when it would've been 10x easier to look up a video and
have someone more experienced casually explain it in 2 minutes.

------
anonytrary
If he's not effective, then you should probably let him know that his methods
are wasting time. If he's effective, then you're the one who is wasting time.
I don't think it needs to be more complicated than that. One of you is in the
wrong, the question is who.

------
arethuza
I think you are being a _bit_ harsh people have very different learning styles
and if you are using an environment that has very fully featured IDE support
(e.g. C# and Visual Studio) a lot of need to reference web based documentation
is removed, at least most of the time.

------
edburdo
If they are learning... and learning effectively and efficiently. It doesn't
matter. If you think the videos take too much time... you could suggest he try
a "video speed-up" plugin... watch things at like 130% or 140%.

------
w8rbt
I find this to be largely generational. Younger people tend to be more visual.
As long as the source of the videos is accurate and complete, I would not
worry about it.

~~~
ceejayoz
I do find for basics that video tutorials often delve more into the _why_
someone's doing something than dry documentation often would.

I've been coding for two decades, so that's not something I need, but I can
see why it'd be appealing to someone just starting out.

