Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

1990 is calling and wants you back... But seriously, many of us simply don't remember that sort of book learning.

If it comes to you naturally, fine, just realise that people are different and have different skills, memorization techniques and care about different things.

Some programmers are like you (a tiny minority afaik) and can read a dry spec or a book and remember all the intricacies and gotchas. It takes a certain type of mind to do that. And I would note that none of the people I knew who could do that were particularly good programmers.

Others, most as far as I've seen in my more than a decade career, learn by making, experimenting and adapting examples.

This is made worse now in some ways because back in the day many editors used to have fantastically well written and edited help, and that has generally disappeared.

Press F1 on a type or function and you'd get reams of well written examples and explanations.

Now most programming languages don't, the documentation is sparse and they simply rely on Stack Overflow and Google to provide all the examples for them.

However, that means that old ways of writing things can stick around as often no-one edits a SO answer to correct it.



> many of us simply don't remember that sort of book learning.

You mean you haven't heard of books, or can't read, or can't be bothered? Presumably none of these so what are you saying?

> just realise that people are different and have different skills, memorization techniques

Fine, I agree totally, use those! But here's what the original poster said "generally accepted best way to perform this operation that leverages the standard library and there is seemingly no other way to discover what that is". If you can find the answer on SO, that's fine - you have your answer! But that's not what he said. He said there's no way of finding it. I said it's in books, you say it's on SO, so there clearly is.

> Some programmers are like you and can read a dry spec or a book and remember all the intricacies and gotchas

Which I can't and don't. Please re-read my penultimate sentence where I said it's ok not to, nor was there need to. Kind of twice in fact ("You're there to deliver results correctly to the business, not deliver idiomatically perfect code." -and- "There's NO shame in not crawling into the furthest, darkest corners of a language.")

> And I would note that none of the people I knew who could do that were particularly good programmers

Oh noes, I haz been trolled :)

> Now most programming languages don't,

No language I've ever used ships with a tutorial (oh wait, delphi's did. Rather crap but it was there). Python's online docs are ok (not great, ok). So pick a book. I already recommended one. Reading is the same whether it comes from paper or phosphor. Just don't complain it needs work. It does. Sorry.

From experience: not knowing how your tools work is a recipe for vastly increasing your workload. Reading a book is a boring, tedious shag but will give you the greatest savings of time overall.

> learn by making, experimenting and adapting examples

Yup, that too. Books AND that. You're quite right. I should not have overlooked that.


Sorry, phrased that badly, I meant that being able to reel off tech specs wasn't an indicator of being a good programmer. For example, one guy was pretty good, but another was literally terrible, couldn't actually program, just able to talk about it.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: