4 ms·
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
by supr_strudl 8y ago
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.
- scarface74 8y agoToo many people take the path of least resistance and want to deliver quickly.... Isn’t that the entire m.o. of the VC fueled Silicon Valley culture?
- supr_strudl 8y agoI hope not. I mean if you're doing another photo sharing, then who cares :)
- mondaygreens 8y agoThe 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 8y agoExactly this.