Hacker News new | ask | show | jobs
by aethr 2415 days ago
A big mistake I made when I started mentoring other developers was making the answers to their questions too easy.

I spent a lot of my early career crawling around on linux servers trying to fix weird bugs in pretty typical web stacks. Later on, when other developers needed help diagnosing an issue on a server I would say something like "sounds like X problem, look at the log file in Y". After several years of this, the same devs were still asking the same questions. I was helping them solve immediate problems quickly and easily, but I was not mentoring them.

Developers don't grow by being given the answers. They grow by trying things and experimenting and solving problems themselves. These are the skills and the lessons that will serve them well as they level up their career. Not giving them the answers but giving them the tools to find the answers.

These days, if there's no urgency, I would say something like "where are the places in the stack where a problem like that might occur, and what can we do to narrow down the set of likely issues?" I might give them some ideas, but let them do most of the legwork.

5 comments

I can echo this experience. I guess this comes down to the Socratic method of teaching people: https://en.wikipedia.org/wiki/Socratic_method

I have yet to see a more effective method of teaching developers, as this encourages understanding and learning about underlying concepts and problems

While I agree, I think there is something to attest to watching someone solve.

When I first started, I was really shit at finding bugs, didn’t understand the total scope of parsing (used in almost every oop method / solution), and general searching how to solve a problem.

I started watching some coders, specifically geohotz, on how they search problem parameters to find solutions, and how they implement solutions. There seemed to be a gap in my investigative research that was filled by watching others investigate and solve sophisticated problems. Ie; implementing ai api in python, really showed me how to take the general knowledge you can learn from documentation ie git or more official places like Microsoft docs and apply it to specific problems that may not have been directly related.

I think, if there is a way to explain and show a junior your thought process and problem solving process while keeping a great mix of allowing the junior to solve themselves as well, there can be great benefit. The hands on approach as described above requires a lot of time and attention, maybe time most senior devs do not have. It can be very beneficial. Maybe some paired programming sessions where the senior works on his sophisticated problems and allows the junior to watch, while also introing the junior to the scope of problem trying to be solved.

Yes, the best teachers ask questions of their students, engage in a dialog and provide "guard rails" for the student to gain mastery of a topic. The end result of learning is not merely knowing answers but being able to ask strong questions (pithy, but true).

This is also part of the reason why Stackoverflow is in such a negative light lately. SO is extremely good at providing answers to narrowly-focused well-defined questions, people forget or aren't aware that this IS NOT a good way to learn subject-matter. It leads to frustration from users because they're expecting someone to give them pointers on how to move forward on general problems and it's frustrating to point-mavens because they aren't empathetic enough to see what the problems are.

SO answers are really good learning place. That is if you read the whole thread instead of copypasting the accepted answer.

Usually, at least for .net, there are explanations not only how to do something, but why do it this way.

I learned quite a bit from SO, it at least pointed me towards right direction in docs. Nowadays i just read the docs instead, but i still google for SO answers for new problems.

Maybe there is an API i have no idea about ,nor my colleagues do? Maybe there is a better way to solve problem XYZ?

Instead of skimming myriad of blogs i can just read the answers on SO and then read up the docs.

SO is as good, or bad, as you make it - if you just copypaste answers, or provide an answer in form of code with minimal explanation why - then that's on you.

SO is a great place to go when you're in a jam at work as a pro doing your stuff. It has specific answers to specific questions. Sure, if you have enough background expertise to navigate the answers, you can "learn something" (1) along the way.

The kinds of questions that people ask when they're focused on learning something new, however, are DEFINITELY NOT what SO is intended to handle. It is why SO is actively hostile to people that try to use it to learn by asking questions.

(1) For .net in particular, Jon Skeet's answers are magnificent resources. He even made the content from his answers into a book. The book, of course, has context and coherence. It's not just the answers copy-pasted into a text. Sadly, Skeet is the exception rather than the rule. For everyone putting up nice answers to questions following the example of Skeet, there are dozens of smug, persnickety jerks making people feel like shit in a hundred different ways for daring to ask a question.

>> The kinds of questions that people ask when they're focused on learning something new, however, are DEFINITELY NOT what SO is intended to handle. It is why SO is actively hostile to people that try to use it to learn by asking questions.

Exactly, at this phase of learning go and read other questions and answers related to your topic instead.

Jon Skeet is a goddamn national treasure.

StackOverflow is in a negative light? What did I miss?
People have complained for years about over-moderation on SO. Here's a good overview article[0]. You may also want to look into recent controversies about licensing[1] and how they treat their community moderators[2][3] (both of which were on the front page of HN).

[0]: https://hackernoon.com/the-decline-of-stack-overflow-7cb69fa...

[1]: https://meta.stackexchange.com/questions/333678/was-the-retr...

[2]: https://news.ycombinator.com/item?id=21113344

[3]: https://news.ycombinator.com/item?id=21176712

I really like this style too. When I get asked to do 1 on 1 teaching sessions I often find myself teasing out answers by asking a bunch of questions using the Socratic Questioning[0] strategy.

A couple of years ago I wrote a blog post on "Would Socrates to use Docker today?"[1] which uses Socratic Questioning to help pick a tech choice. If anyone is curious on how to apply it to technology, that post goes into a bit of detail. It could also be directly applied to solving specific programming problems too. I use it to make a lot of decisions.

[0]: https://en.wikipedia.org/wiki/Socratic_questioning

[1]: https://nickjanetakis.com/blog/would-socrates-use-docker-tod...

To add a concrete example, one of the best uses of the Socratic method I've seen, teaching binary to 3rd graders - https://news.ycombinator.com/item?id=2446316
Cheers for the link, that's an amazing page.
Teaching developers how to find the answers to their problems is a crucial skill, and one that's often approached the wrong way - either new developers get all the answers easily and don't learn, or they spend days trying to unblock themselves. I recently wrote about that challenge in an article for junior developers. [1]

[1] http://www.pearlleff.com/seven-tips-for-a-junior-developer

I agree, but what do you do when others don't co-operate? My experience is that most people absolutely hate this. Only occasionally do I run into someone that appreciates figuring it out for themselves. More often, they feel like you're playing games with them, or being condescending. You become the jerk for withholding information, instead of them for wanting others to do their work for them.
I'm assuming that's due to the mental framing of the relationship. When a Junior Developer identifies the student/teacher relationship, you can encourage their growth in a way that you can't with a peer-to-peer relationship. The questions asker needs to understand that they're getting help LEARNING and not just an answer.
Naw, that's just the way many people are. If you can't give them the answers they want they'll assume you're incompetent (aren't you a senior engineer?), if you refuse to, they'll just think you're a jerk (quit playing games and tell me what I need to know). They don't want you to treat them like a child, because you're "trying to help them learn". Some people just hesitate to run with the premise, it'll look like you're making them jump through hoops, and wasting time.
This applies not just to developers but all the way "up the ladder". The problems will change but the effective learning and mentoring will be the same.
The trick is to play the question back at them: “What is your guess?”

If they got used to your service this might annoy them, but if you explain it beforehand..?

When I was a junior dev and was stuck on a problem (had to cap myself at 1 hour max because otherwise I'd spend the entire day) the first question my mentor asked was 'what have you found out?' and 'what is your thought process?' By regurgitating and trying to condense the things I figured out he could already point me to the right path and/or correct some wrong assumptions I made. It really helped me grow as a developer to not just be handed the answer.

But yeah, he did sit with me beforehand and explained how he mentors people.