I would argue that without reading, you’re wasting a lot of time. “Good people borrow, and great steal”. I know few software engineers, who don’t read and yet still write amazing software. But there are very few of them. I bet you’re not one of them, actually. And most of their time, they do waste some time too. Very few of us solve unique problems. You’re probably not the lucky guy either.
In my opinion, you won’t be very good and well respected, unless you read.
I just came back from a “meetup”. Small informal mini-conference which people around here organize. It happens on a monthly basis. You get free talk, free pizza and sometimes get solicited to help someone. Or they try to recruit you. But in general: it’s a free-though meeting and idea exchange.
One talk was by a book author. A question was raised on why her book topic touches “Swift”, a popular programming language, instead of being more general. The author replied she had picked a topic she knew would have a shelf life longer than 6 months.
This made me think.
Not the first time technical author expresses a worry that topics in computers change rapidly, and they can’t keep up with writing the material.
But here’s the secret: it’s 10% true.
Most of the rudimentary topics don’t change and won’t change. The reason? Underlying hardware, software and algorithm principles don’t oscillate or get outdated. Not unless we get completely new paradigms, like quantum computers. But right now: it’s all 0s and 1s flipping back and forth, very quickly.
It’s all the same stuff, wrapped differently.
It’s like getting a candy packaged in a red silver wrapping. And then getting a candy packaged in a green silver wrapping. On the surface it’s very different, but it’s the same candy.
The problem is that new books (lets say 2010–…) are mostly about wrappings. Older books talk about universal values. Example: the publisher Morgan Kaufmann made so many great books in the past. The new ones are often a collection of conference papers. Many authors, inconsistent style. Not worth a buck. Keep buying older books.
Authors have to struggle with it. In my opinion: if you’re a writer and you like this kind of stuff, it should be great for you: keep writing about candy wrappings, and people who are your audience and who want to stay up-to-date will keep buying your books.
Think of Donald Knuth or Richard Stevens books. Stevens taught me UNIX and I have Polish and English edition of each of his books. And he delivered high-quality examples, in a source code form. And it’s still very useful. If you know any other authors whose work you like, let me know. For a writer and a publisher: it’s terrible. I baught these books once, and that’s it. I don’t new copies ever again. Poor business.
If you’re a reader, my suggestion to you: start selecting literature so that things you learn are universal.
It’s fine to get a book on some particular technology. I have a book on Rails 4. Rails 5 is around, but still most of the stuff in the book is true. In 2 years it won’t, but I’ll be a part of the active “Rails developers community” by then, so I’ll notice.
Which things are those? It’s pretty easy, if you look around.
Some stuff you may want to read about:
Methodology doesn’t change. Read book on it. There are some new inventions every now and then, but most of experts know they don’t bring even 2x improvement in productivity. Maybe 20% improvement. Or 5%.
Process doesn’t change (much). Read book on it.
Coding style and its importance doesn’t change. It’s a universal software engineering stuff. It’s slightly different for each technology and even a project, but its principles don’t change. Read book on it
Networking concepts don’t change (much). If you have time, read TCP/IP Illustrated. This stuff isn’t going away.
Software architecture and patterns don’t change. This is like grammar for software engineering. You can make a prose with made up words, but 99% of software has signs of being architected according to a well-known patterns.
Testing doesn’t change. Read book on it.
UI design doesn’t change (much). Read book on it If you pick book on old Win3.1 UI design and it’s principles, it’s pretty much the same.
Databases and data models don’t change much. Read book on it One of the things I slightly regret is that I wasn’t paying more attention during my databases courses (didn’t like it back then) Now I do, and I’m catching up. But these concept re-surface everywhere: in embedded databases (Realm), Rails (ORM) and everywhere else.
Read a book and take a break. Technical stuff isn’t prose and your brain will burn more calories processing stuff.
If the book has source code examples, retype them and try them out.
Never copy and paste stuff from ready-to-use examples. Unless you write stuff with your own hands, I guarantee you that your recall will be maybe 10%.
Do the homework. If the book has exercises, try to do them. Challenge yourself to go through them and see how much and why you were off.
Fiddle with content in your head. Keep asking yourself questions and trying to answer them. Find additional material on Google. Find YouTube videos, podcasts and animations showing concepts you’ve learned about. People recall video best, then podcasts and then text. It’s best to have multi-media source of knowledge to stimulate your brain. And there’s research on that.
Try to mix it up. I find it hard to read two software architecture books back-to-back.
Don’t read more than one book at a time. I get confused and discouraged and it’s hard for me to come back to the context at which I’ve left of.
There’s some new stuff which I think isn’t very well covered. For example distributed computing isn’t very well covered. If you’ve asked me, I wouldn’t know what to recommend. It’s weird, because it’s around for a while, but I think it’s (a) a domain of big companies with busy people who don’t like writing books (b) it changes quickly due to increasing demand for bigger systems (c) is tied to companies. Google, Facebook and other big companies have their own distributed software frameworks.
Reading is important. You’ll be better of reading, as it gives you more experience, more perspective and makes you a better expert. You gain more tools in a box, and you’re more appropriate for doing interesting work which may come your way by accident.