Ask HN: How to work with a developer who avoids reading?
Someone recently joined our team as a junior dev. Their work is good, but I noticed that when they'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.
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. 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. They do read SO and tutorials.
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.
62 comments
[ 3.1 ms ] story [ 115 ms ] threadI 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?").
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.
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"
0. https://onlinelibrary.wiley.com/doi/abs/10.1002/ase.1777
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...
But if you're learning a new framework or a whole new concept a video of someone doing the work will give a better/faster general idea of what's going on
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.
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. ;-)
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?
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.
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.
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...). 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?
It sounds like two inexperienced developers just struggling to communicate.
This is not how developers work from day to day. Sure we might draw an architecture on the board.
An IDE isn't going to help you with an effective whiteboard interview question. If someone is asking you about specific APIs in a whiteboard interview, they're likely doing the interview wrong.
The first time I encountered an interview test like that, was for a company that had a SAAS for railroad car repairs. The coding itself wasn’t that complicated in an abstract way, but the business requirements were insanely complex.
This is just a preview. Going down the rabbit hole of rules around railroads is like going to a tvtropes article.
https://www.railinc.com/rportal/documents/18/260641/Guidefor...
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?
I'm genuinely curious.
But we are talking about the return value. While because of the crazy way that you have to instantiate Boto 3 in Python, an IDE can’t give you intellicense and you have to look up the docs to know the arguments, you can still assign the response to a variable, put a breakpoint on the call and see the response.
Alternatively, you could use the REPL.
You say that the quality of their work is good so why does it matter if you learn things in differently?
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.
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.
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.
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.
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.
You two should not need to learn the same way and have same preferences to collaborate.
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.
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?
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.
Isn’t that the entire m.o. of the VC fueled Silicon Valley culture?
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.
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.