Hacker News new | ask | show | jobs
by oysterfish 2613 days ago
Don't teach coding. I haven't come across a discipline yet where:

1/ there's such an astronomical disparity between students 2/ where it's more of a requirement to be an autodidact.

All the good devs i know just pick up books and start reading. If you look professional devs out there, if they all taught themselves how to code, then one must wonder whether you can even produce a good coder by teaching them directly.

Instead, pointing them in the right direction on their learning path at the right time is probably going to be hugely beneficial.

I know for myself i wish i'd spent more time learning than building things. It's been useful too building, however my ratio was off by quite a bit.
2 comments
traderjane 2613 days ago
It's possible that the state of education, documentation, and general programming know-how was so bad and fragmented before and so almost everyone had to rely on some self-learning.
link
kkarakk 2612 days ago
it is still fragmented. you can't point to a definitive source for "how to be [x] developer". you can just give them a roadmap at best.
link
xenocratus 2613 days ago
That's very true, at least in my experience - best devs seem to be the ones who can find their way quite easily without supervision.

BUT not all people like or are comfortable with that. For example, if you've started learning programming in a rough environment, I imagine it could feel difficult or even scary. So making them feel more secure through pair programming or something of the sorts could help them ease that out.

Plus there's the benefit of efficiency - sure, they might need to learn Java or C or Python by themselves (which you could state to them), but learning to navigate through the internals of a large codebase can be quite challenging and not necessarily useful right away. Sure, you might need to face the more hairy bits of the repo at some point, but figuring everything out right off is probably not ideal - or, not always.

And another issue is process - different companies (even different teams within the same company) have different processes - e.g. pick up ticket, read description and possibly discuss with lead/QA about what the acceptance criteria is, write code, open PR, get reviews, get QA review, check code coverage and static analysis.... you get the idea

link