It seems you feel that you learn by doing instead of reading, which is fair enough. Let's take networking for example, there are two ways which you could learn

It seems you feel that you learn by doing instead of reading, which is fair enough. Let's take networking for example, there are two ways which you could learn by doing, a bottom up approach focusing on the foundational tech, or a top down approach. Each are valid and have pros and cons. 1) Bottom up. Pick a project in a language of choice like transferring text/audio/video over the network between two peers. Write it using TCP, figure out why that's a bad idea for live streaming, do it again in UDP. You'll have to learn how to program against socket interfaces and other fundamental network stuff. 2) Bottom up extreme edition: write the underlying TCP/IP stack also. 3) top down. Write a toy networking application using something that provides an abstraction over sockets like ZeroMQ. Then you turn your toy application into a behavioural test suite by swapping out the calls to zeroMQ with your own library which is API compatible. Your library passes when the toy application works again. Then you go read the zeroMQ source to figure out all the concepts and edgecases that it's normalising for you that you didn't think to consider in your replacement. This means you still employ the fundamentals needed in the bottom-up approach to get things working, but after reading the source you're also mapping out things which were unknown unknowns to you so you have a better mental map of where you might have opportunity to learn more.