One of the points in the article really jumps out and again, I use martial arts as a lens for comparison. Talking to other programmers extensively accelerates your growth. If I had tried to piece together the knowledge my Sensei taught me through "Youtube, books, & self-study", I would have not gotten as far as I have. There's something about having a mentor that can warp-speed your progress. Anyone who has mentored under a master in their field would attest to that.
The programming culture is one where you're encouraged to go out and figure it out. Yes, there are teams and pair programming but I don't see most companies emphasizing mentorship as much because its not directly tangible on the books. Its more of a long-term investment and they see employees jumping around every couple of years, so why bother?
It would be interesting to see master programmers (30+ years of exp) offer year-long intensives for serious students who wanted to accelerate their growth. I bet you would get some excellent programmers.
[0]: https://www.khanacademy.org/talks-and-interviews/conversatio...
I basically built up my career around my code foo and the way I was taught on IRC. Even if it may seem like a harsh environment in the beginning, they proved to have a point with the semantic perfectionism, only through which one can convey all nuances of what one is trying to say - and do.
One advice upfront, look your stuff in the original technical documentation. The C Standard, the infamous Intel Developer's manual. Learn some assembly, be it on an old 1980ies personal computer.
It's one of the big lessons how you start organizing your code flow, function and data so that you can effectively get things done and make something more from something less with what compares to hammer and chisels. I find myself fixing python code under comparable viewpoints today; being thrifty of what types an object may take, being explicit with comparisons, etc.
The thing that lets this compare to training Karate I once heard in the context of chess; "It's you who is manufacturing your own checkmate". To have a comfortable, easy to modify codebase is infinite work, but the more intention you put into the detail, the less you need to care about the bigger picture. Good code is equivalent to but the intention behind it.
So many "learn to code" sites, books, and programs lead people to believe that the journey essentially ends there when it's actually the beginning. Sure, people understand that further experience is needed, but without some kind of guidance it's very haphazard.
So, to me, making programming interesting is one of the keys. I know I have a common learning and work style that heavily favors the experiential and interactive. Other promgrammers I have worked with can Zen focus and design for days before touching code. I can't. I like to interact, prototype, outline with code, think in smaller bursts, and then iterate. I have learned to be more patient over the years, but that is still my default paradigm.
I think I generally agree with Norvig here. Most of the criticism of his article is misplaced. He isn't saying you should only learn to program in 10 years, but that it is a hard discipline with immense depth.
What is funny, after programming professionally for about 30 years, Is I want that job in the call center answering telephones. Even more ironic, it takes 1 month of intensive training to do that job.
In some call centers, you will be following a script about 90% of the time and that takes very little training. In others you actually have to think and troubleshoot issues, those take a bit more time to get up to speed on.
All that being said, I can assure you that you do not want to work at a call center. I'd take whatever programming job you currently have over the call center I last worked at. For whatever reason, call centers attract the worst kinds of managers in this day and age.
Having worked in a call center, I can say with roughly 99% certainty that you do not want that job. It's got to be one of the most mind-numbing, soul-crushing occupations on this planet.
If I could retire today, I'd probably go back to selling video games in Best Buy.
But, lo and behold: https://web.archive.org/web/19980206223800/http://norvig.com...
It's a very different article, but at the core, it's the very same idea. Pretty fascinating that it apparently has been "ghost-edited" to stay current.
Though still, 95% of the time, I walk away from my check-ins feeling like my code could be a lot better, but not seeing how until much later.
Does the (1998) in the title maybe not mean it was written in 1998?
Turns out it was a lot more than just "5 nanosec".
For example, compare programming pedagogy to the typical way in which children are taught to read. We begin learning to read at such a young age that the actually utility of reading is more or less completely factored out of the equation--we go to school, reading is a part of what we do there, and so we sort of just accept that and spend a great deal of time engaging in the activity intimately--exploring its nooks and crannies, playing with it, joking, discussing it with classmates. In the case of programming on the other hand, a lot of autodidacts have selected the discipline not for any love of the game (of course there are several who do have a genuine love for it) but rather for some perceived use-value it provides. For example, if I learn to program I can get a better job, or I can offload some menial task, or I can ultimately do some other thing that happens to require programming (e.g. making a video game is what I really want to do, and if I have to learn to program to do so, so be it). This sort of utilitarian frame makes it very easy to engage in behavior that frustrates learning--reading for information only, rushing through material, copying and pasting examples, seeking out solutions to exercises when stuck rather than exploring and working through them. In general it's much harder to be a good learner if you've attached some ulterior motive to your learning activity.
There's a lovely German word Mitgefuhl, which is often translated as compassion but literally means "feeling with". I think it's a fundamental concept underlying a great deal of successful human endeavors--just as you need to exercise compassion in order to really understand someone's emotions or perspective, I think there's a lot of merit to dwelling with, or, as ancient monks practiced, ruminating (chewing the words) intellectual material. Taking one's time is important, as is checking in periodically to ensure you're still consuming things consciously. When I read a book, no matter its subject, I like to imagine I've signed a lease to rent out an apartment with its author--to really get to know the consciousness behind the words--not in any psychological sense, but in a purely epistemic one, to achieve a better understanding--to learn how myself and this consciousness might live in harmony, to imagine conversations--to 'feel with.'
As someone who is self-taught when it comes to programming myself (and still has an incredible amount to learn) I can say my own experience of learning and the rate at which concepts solidified definitely increased once I broke my interest in the practice free from any concern over utility and decided it was simply something I found interesting--something I valued irrespective of its practical application.
~17 years later that has definitely been my experience.
It’s possible to be very productive in a language after 6-12 months. The code might be decent, or with some talent and hard work, even good. It really doesn’t take all that long to learn enough to produce some cool things. However, I’m almost certain that if you look back at the code you write today in 12 months, 5, or 10 years, you’ll see many things you’d do differently. This is partly because In 10 years you will see many more problems, and solved them in many different ways. Personally, that’s one of the things I really love about this field.
24 hours is not even how long I had to file a metal block until I was deemed ready to use heavy machinery during secondary school. I filed it for 3 weeks, 5 days a week, 9 to 5.
21 days is not enough to master metalwork, even though I was allowed to use heavy machinery, I borked up more than one piece until I eventually got it right at the end of the school year (which was about 6 months of metalwork).
And I think I am still way of from mastering it, not that I want to.
Programming is, IMO very similar. Sure, you can get a hammer and start hammering on a metal sheet and that'll probably produce something in the right shape. But learning to program, mastering it, takes time, 10 years is IMO a good estimate. I've been at it for 8 years now and I still got very much to learn.
Of course people can become good with a programming language, just like you can get good at filing a metal block in 3 weeks. But it doesn't mean you've mastered all the tools yet.
At any rate: lately I've been having to interact at work with some folks from another company whose entire outlook of what "programming" is revolves around web CRUD stuff and some interactive-looking front-end... web stuff. So "I learned some new programming skills" to them is closer to "I learned how to make an HTML5 caroussel using jquery and Laravel" than "I learned how to calculate road distances using GIS LineStrings and Djikstra's algorithm". Their whole world looks like a CMS. There's a threshold of "meta" they cannot cross.
I think this is both why PHP is so popular and so despised: it attracts people who wouldn't be able to grok concepts at a higher level of abstraction (say, Python @decorators) so they don't need it. PHP -- and really, Laravel, whatever that is -- is all they need.
I’ve had to teach quite a few people the basics of HTTP: a user-agent makes a request and a server replies with a response, that both requests and responses are composed of a header and an (optional) body, and some of the important information that might be included in the headers (cookies, character encoding, caching information, etc.).
everything is running synchronously in the current thread on the same machine (or can be roughly abstracted as a single machine where all backend is simply 'invisible')
like a tv.
This is the reason lots of people learning programming try few months of Javascript/Ruby , then they got stuck to solve any real life programming problem. The reason is that they have not mastered the "basic core concepts" of programming such as traversing an Array backwards, nested loops, two indices one activates after another ete..
"but becoming this good programmer in first place will take years."
> Learning to program is not mastering a new language. A good programmer can wrap their head around any language in short time but becoming this good programmer in first place will take years.
