[almostgotcaught]

Controversial take: reading books to get better at software is like reading books to get better at swimming. Like people don't get better at math by reading books about math... So you should go read code. But reading code is boring if you're not also writing code (same goes for math) so my real recommendation is to go find a big OSS project in an area you're interested in and start contributing. If you don't know how to start doing that, pick one with a GitHub and go look through the issues. Any serious project will have a label like `easy` or `first PR`, respond to one of those and tag one of the contributors asking something like "can you give me a code pointer so I can get started". And off you go - guaranteed to make you better at software if you do it for long enough.

[bubblyworld]

I agree with the gist of your comment but I think people can benefit from books about maths. A classic example that comes to mind is Polya's "How to Solve It". It's about the meta of doing maths (or the tacit knowledge of a great mathematician), not about specific fields or theorems.

[almostgotcaught]

Yes if you know absolutely nothing about writing proofs then polya's book is good. But that's it - after that "onboarding" you're never going to see a professional mathematician reading another such book.

[bubblyworld]

I still got stuff out of it during my PhD (in mathematics, though I never finished). I think you might underestimate the value of tacit-knowledge-type stuff, especially from skilled mathematicians like Polya. It's interesting to see how they tackle hard problems, and to compare it to how you would do the same - at the very least I have a much less developed philosophy about it. Terrence Tao has blog posts about his problem-solving meta as well, that are interesting (to me) for similar reasons.

[cdrini]

I think both are useful, and generally if you have the time to do both, you should.

For example, my go to when using a new framework or library that'll be a core part of a project, is to read its documentation in its entirety. I did this with eg Vue. It's a _huge_ time saver, and the big key, is that it reveals things you would never have known existed! They're things which you wouldn't have stumbled on yourself, but which come in handy in certain moments. Or they're things that would waste your time googling, and which might be difficult to understand out of context. The docs also let you understand the "spirit" of the tool you're using, which will let you work much more smoothly with it, and avoid unintentionally fighting with it and how it was designed to do things.

This is also true for more abstract concepts in CS, which might not come up often, but which are smart abstractions that can come into play at key moments in your projects.

Also with math, most math learning is done by books -- books with exercises, yes, but still books.

But at the end of the day, I think what matters is don't get stuck in one mode. Don't _only_ learn from books, since that won't give you the skills you need. But also don't _only_ learn by doing, since then you'll basically be wasting your time re-discovering the last 100 years of programming/CS experience. Do both!

I think an artist in YouTube summarised this best many years ago. He describes 3 ways to improve at something: innate improvement, inspired improvement, and developmental improvement. Innate improvement being by volume--i.e. if you do it every day, you'll get better even if you're not consciously trying to improve. Inspired improvement is using those bursts of inspiration/interest to propel your skills forward. And developmental improvement being the more traditional, sit down with a book and learn/practice approach. All are useful and contribute to improving, so use them all where possible! Jazza recommends making projects that allow for all three possible types of improvement.

Video: https://youtu.be/Bu3ulVhO3z4

[d0mine]

it is not either or. You can do both.

I'm sure a swimmer who reads books about swimming in addition to swimming is better all else being equal than a swimmer who just swims.

[almostgotcaught]

> who reads books about swimming

Can you show me such a book? Ie a book that teaches one to swim (different strokes etc) aimed at a professional swimmer (athlete).

[remixff2400]

I think your point makes sense, but the comparison of programming to swimming loses the thread of thought a bit. Swimming is not my forte, but there are books by professional marathoners on how to train for marathons, for example, that are valuable to read for forming proper training plans as opposed to "just figuring it out".

I think your opinion on OSS/large codebases makes sense, but I don't think it's an either/or situation: reading should _support_ actual coding, similar to how studying a grammar textbook for a foreign language is there to support actually speaking/listening/communicating in that language.

[noufalibrahim]

Can't show you one for swimming but if you're a karateka, then you can do worse that spending some time reading books like the Bubishi

[intelVISA]

It's like reading books in order to get better at writing them... sure it kinda works but not really. You get better at SWE by building things!!

The field has a lot of gurus who trick newcomers into falacies like 'clean code' when, instead, they should be out there banging together rocks like a JavaScript caveman seeking fire (Lisps).

[mewpmewp2]

I do think sometimes reading books about coding might actually make you worse since you might misunderstand the rules gained from there and try to use them everywhere even if they don't make sense.

So you need some sort of built experience that will allow you to consider those rules critically, and only add them to your toolset if it does seem to make sense for you and you understand why, you have past experience where you think "oh - that would have helped me a lot".