▲ | globular-toast 8 hours ago | |
That's kinda like saying you can learn to drive by just getting into a car, crashing then thinking about how not to crash it next time. In reality both things are necessary. The car analogy doesn't hold for road driving because we drive well within the limits, but for racing it really is necessary to know exactly where the limits are. I don't think we should really be treating our profession like a race, though. But if you don't read it's going to be an incredibly long slow process and a lot of car crashes and mangled gearboxes etc. So I say read, read, and read some more. Even if you don't see the point of it right now your experience will later find a place for it and you won't end up descending a hill for the first time not knowing to shift to a lower gear. | ||
▲ | sim7c00 8 hours ago | parent [-] | |
you mention a key point. profession. programmer doesnt really imply professional programmer. I'd aay if you do it for a living, certain tedious chores must be learned. the best programmers i know (professional) can all read code. they spent many junior years learning to read it, being on code auditing desk.... nowadays idk how the landscape looks, but for all of them they had to review and read code to find bugs before they were allowed to produce code (they all worked at same company ofc... so my view is limited!) i do feel such discipline is needed. they can always poke holes on my code no matter how many holes i plug :) - i am semi professional. i write code for work, but not production code. (experimental). i never learned to audit code and feel that makes it impossible for me to truly create production grade code |