Recovering interrupter with occasional relapses, lover of spreadsheets, blogger, programmer, adept debugger, conjurer of analogies, and probably other things.
If you love building, then learn about patterns. I don't write or program Java but "Head First Design Patterns" was one of the best introductions to those. Learn the language of talking about programming; I found Martin Fowler's book on refactoring quite useful.
If you're afraid of performance, learn about bench marking and tracing. There are so many bottle necks for speed, and it's often "all of the moving parts" that creates the un-realized friction that slows the system down. (e.g. sending too many files, not compressing things, bad looping logic, missing database indices, disparity between assumed bandwidth and available bandwidth, etc.)
And as someone who's been coding for quite awhile now: practice and write. Practice writing tests of different varieties (unit, functional, integration, smoke, etc). Try writing documentation first then coding. Get good at articulating what "done" looks like. For myself, when I can say what done looks like, it becomes rather easy to get to done.
Don't go chasing new things at the cost of learning the lessons of the old things. Each new thing addresses the problem of something that came prior; learn about what that prior work solved. I have seen many folks jump from new to new, without internalizing the humble yet critical lessons of maintainability and sustainability.
Recovering interrupter with occasional relapses, lover of spreadsheets, blogger, programmer, adept debugger, conjurer of analogies, and probably other things.
If you love building, then learn about patterns. I don't write or program Java but "Head First Design Patterns" was one of the best introductions to those. Learn the language of talking about programming; I found Martin Fowler's book on refactoring quite useful.
If you're afraid of performance, learn about bench marking and tracing. There are so many bottle necks for speed, and it's often "all of the moving parts" that creates the un-realized friction that slows the system down. (e.g. sending too many files, not compressing things, bad looping logic, missing database indices, disparity between assumed bandwidth and available bandwidth, etc.)
And as someone who's been coding for quite awhile now: practice and write. Practice writing tests of different varieties (unit, functional, integration, smoke, etc). Try writing documentation first then coding. Get good at articulating what "done" looks like. For myself, when I can say what done looks like, it becomes rather easy to get to done.
Don't go chasing new things at the cost of learning the lessons of the old things. Each new thing addresses the problem of something that came prior; learn about what that prior work solved. I have seen many folks jump from new to new, without internalizing the humble yet critical lessons of maintainability and sustainability.
Okay, I will read his book, kinda interesting for me.
Bench making and tracking? Kinda learned that at college. Definitely learning that right now.
Never documenting before doing any of my projects before. Probably the habit I should avoid.
I agree with you, sometimes older stuff can be useful when learning something new.
I keep grinding though. Thanks for the tips. I appreciate it👍
I saw you favor Java, then definitely grab "Head First Design Patterns".