31–40 of 57 posts
If you really want to learn programming. 1. Buy SICP and put it on your book shelf. 2. Don't read it, instead read random StackOverflow posts talking about the content. 3. Spend the next 10-50 years trying to understand what people are talking about on various related forums. 4. Add more legendary books to your shelf over these 10 years, like The Art of Computer Programming. Fawn over their greatness. DON'T READ THEM…
Edit: also did 200 Codewars katas to practice, then started to build things.
Plus a certain amount of raw intelligence, but less than many people think. If you're asking, you've got that one covered.
The temperament, though. Can you spend hours to weeks trying to find the stupid and obvious thing you did wrong, and feel good about it afterward? If so, welcome to programming. Enjoy your stay.
Data structures and algorithms. I don't have a formal education either but after 25 years of programming, IMO everything boils down to data structures and algorithms - the former more so than the latter. I think everything else comes from experience gained from on the job training because you need to train the pattern matching part of your brain. A good foundation in data structures and algorithms simplifies that pro…
Other posters are saying "just build stuff and you will learn", which isn't wrong, but there's a reason every CS student learns data structures and algorithms first. They are literally the building blocks for everything else. Then, once you've got that foundation, the "just build stuff" advice is sound but if you skip that step you will always be at a disadvantage.
DDIA is a great book but definitely not for a beginner and is only applicable to backend web engineering at a certain scale.
Data structures and algorithms. I don't have a formal education either but after 25 years of programming, IMO everything boils down to data structures and algorithms - the former more so than the latter. I think everything else comes from experience gained from on the job training because you need to train the pattern matching part of your brain. A good foundation in data structures and algorithms simplifies that pro…
And from Fred Brooks...
> Representation Is the Essence of Programming
> Beyond craftsmanship lies invention, and it is here that lean, spare, fast programs are born. Almost always these are the result of strategic breakthrough rather than tactical cleverness. Sometimes the strategic breakthrough will be a new algorithm, such as the Cooley-Tukey Fast Fourier Transform or the substitution of an n log n sort for an n2 set of comparisons.
> Much more often, strategic breakthrough will come from redoing the representation of the data or tables. This is where the heart of a program lies. Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious.
Brooks Jr., Frederick P.. Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition
Replace "flowcharts" with "code" and "tables" with "data structures" (or leave it with "tables" for a database centric view) for more modern terminology.
---
I would also reminded of Algorithms + Data Structures = Programs by Wirth... which in turn brought me to his quotes.
> "Good enough software" is rarely good enough. It is a sad manifestation of the spirit of modern times, in which an individual's pride in his or her work has become rare.
Craftsmanship is something that is lost. It's written and it's someone else's problem once it is deployed. Be that a "its operations problem now" or "this contract is done, the next contractor will need to deal with it."
The third virtue ( http://wiki.c2.com/?LazinessImpatienceHubris https://news.ycombinator.com/item?id=39385228 ) of programming is often forgotten and lost.
> Hubris: Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. (p.607)
I started writing minecraft plugins[0] and now I can write software as low as ioctl firmware and as high as web development. The more you write the more patterns you will start to notice and the better you will become.
Do not seek answers, do not seek solutions[1]. Stack overflow and guides are your enemy (documentation is fine[2]).
Want to learn x86 assembly? Throw a random exe (notepad.exe) into x86dbg (or CheatEngine) and start debugging[3] from the beginning. See what each instruction does and how it affects the hardware registers. Look at it long enough and you will start to understand assembly and be able to write it.
Programming is special for me - I was the dumbest person you could find as I even struggled with basic multiplication at school, but with years of programming I've also noticed how I've started doing much better at school without putting in the extra effort usually required.
So in the end - just write code, see where it takes you. Follow your interest and see where you end up.
[0] With no education, no knowledge and a slow computer with a free eclipse IDE. The only guides I ended up using the most were on how to setup bukkit plugins in eclipse.
[1] For specialized software, otherwise try to figure out what the library does that you want to use yourself by looking at what it does and how it does it. Finding out how to use any kind of particular software is typically fine, but it's better to play around with it and figure it out yourself.
[2] Unless you're reinventing a wheel (don't invent a sorting algorithm).
[3] Single-step program entry-point until the application is running and you notice a repeating loop.
You need problems to solve , but most importantly, problems that are highly relevant to you and your interests so you won't give up easily if they become unexpectedly difficult. You'll be forced to learn new approaches, new tools, perhaps even new languages to solve these problems if they're challenging enough, and don't worry, you'll almost always assume something is easy when it turns out to be a lot harder than yo…
Find the Hard Work You're Willing To Do http://www.cs.uni.edu/%7Ewallingf/blog/archives/monthly/2018... ( https://news.ycombinator.com/item?id=26209541 )
The final two paragraphs of the essay (from a university undergrad advisor in a CS department):
> Maybe this is what people mean when they tell us to "find our passion", but that phrase seems pretty abstract to me. Maybe instead we should encourage people to find the hard problems they like to work on. Which problems do you want to keep working on, even when they turn out to be harder than you expected? Which kinds of frustration do you enjoy, or at least are willing to endure while you figure things out? Answers to these very practical questions might help you find a place where you can build an interesting and rewarding life.
> I realize that "Find your passion" makes for a more compelling motivational poster than "What hard problems do you enjoy working on?" (and even that's a lot better than "What kind of pain are you willing to endure?"), but it might give some people a more realistic way to approach finding their life's work.