Ask HN: How did you master the art of programming?
Who qualify to be a master programming?
Anyone who can create websites, games, from scratch with their own brain and google help without following tutorials line by line.
So, how did you mastered the art of programming? If it was practice, what did you practice?
I was talking to a guy and he said to me that he has finished a DSA book thrice(fcking thrice) and solved same 500 problems thrice. That's how he mastered programming. Now he is able to solve any kinds of new programming problems He has built a game engine and physics engine of his own.
That too in c++.
I liked how honest he was about his journey. Most people seem to be telling "well I am just good at it..." and trying to hide their hard works.
What's your secret sauce?
60 comments
[ 3.2 ms ] story [ 109 ms ] threadI 'mastered' programming by your definition by having a 2 year long internship at a hardware company where I was asked to make a website, write code that interfaced with non-standard networking protocols, and automate the company's garden. I had a whole lot of help from some graduate students that were there working on hardware design and were kind enough to answer the 1000 questions I had.
The fact that I did not learn data structures & algorithms 101 well enough to pass a FAANG quiz means I would probably have self-identified as less motivated than many people.
What do you consider to be curiosity and motivation if not someone taking the time and effort to work through something like on their own? The way someone smiles?
I feel like too many people in this profession put down the hard work and effort people go through to study this kind of stuff, as if there's some kind of insecurity towards those who know data structures and algorithms, are good at leetcode, have side projects.
It's like all that matters to people is whether someone comes across as a nice guy they'd like to have a beer with and talks nicely.
[1]: https://v.cx/2010/04/feynman-brazil-education
What you learn in DS&A is nearly orthogonal to many tasks a programmer does in an enterprise setting including
- writing code and documentation optimized for readability by multiple audiences with varying degrees of familiarity - learning and integrating and interfacing with other systems - modeling business constraints - working and tracking project completion in a team
It's not the passion regarding DS&A that raises yellow flags, it's the lack of awareness (though that may be OP's omission) that DS&A familiarity is only one aspect of programming.
What I've learned from years of rubbing elbows with other skilled labor is that there's nothing special about bikes or software. It's all the same sort of problem all over. Intellectually understanding a problem is not knowing it in your bones. It's not acting on reflex and intuition without having to exhaust yourself thinking about what to do next.
I spent a few years cleaning hotel rooms and, in hindsight, I did some of the best programming work of my life during that time. In part because I would find insights into a problem by analogizing it to cleaning hotel rooms (many of the fundamental problems are the same, just in a different context), and in part because cleaning rooms is mostly automatic, physical, mindless work and it bought me 8-10 hours a day where I could just think about whatever I was working on at home. That taught me the value of letting your mind "wander" into solutions when you can't reason into one.
I'm quite skilled, but I have a whole lot more to learn. I think that's true of every expert programmer I've ever gotten to know.
I've been programming professionally for 30 years or so now, so the basic honest answer of how I gained the skills I have is that I've just done it a whole lot.
But I think that leaves out too much. I truly love programming and computers, and am curious about everything related. I would not be doing it any less if I weren't being paid for it (and, in fact, I have never stopped programming recreationally).
So I've spent countless hours studying, reading, experimenting, and just generally doing, because all of that was play, not effort.
When people ask me how to learn to program well, my answer is basically "just start programming". Pick a language, it doesn't matter which, and start. Branch out from there, learn other languages (especially ones that use different paradigms -- learn object-oriented programming, learn procedural programming, learn parallel programming, etc. Once you have learned how to work in a given paradigm, the difference between the languages in it becomes mostly a matter of syntax, and so they're easier to pick up).
Read constantly, and a wide variety of authors. Read programming-related things that are unrelated to the stuff you're currently interested in. Read other programmer's code. When you see something cool, take the time to look over how they did it -- even if it's in a language you haven't learned. You'll understand more than you expect.
Be a generalist. You'll probably have a favorite language, a favorite type of programming, a favorite type of problem, and so forth. Make yourself tinker with the stuff that isn't your favorite, and especially the stuff that is new. Even if you never do more than tinker, you'll learn new things and approaches that will improve the skills you've already honed.
Avoid ruts. Avoid doing the same thing over and over.
And realize that all programming is essentially an exercise in complexity management.
If I'd add another point, I'd say that many skills of a good programmer don't necessarily relate to programming itself -- even still on the technical side.
> And realize that all programming is essentially an exercise in complexity management.
I think this gives us a hint at this. If we're building more and more complex systems to solve problems (and that's what our job is, not producing compiling code!), there's also tremendous value in reasoning and extrapolation skills that allow us to "mentally leap into the future".
In his first session of "Beyond the Goal", E. Goldratt elaborates on four questions he insists one must ask about new technologies:
Along those lines, often we're given a problem and an existing system; and the best thing to do is just to identify why there is a problem (the limitation) and what (ideally simple) steps we can take to get rid of it. So less thinking along the lines of "add another form/button/algorithm/yaml file" and more "hang on, this problem just goes away if I correct some preconceived notion we just inherited without introspection".Edit: I have encountered situations where the last bit resulted in me mostly getting rid of code (and complexity) instead of adding more to a project.
I consider myself a master programmer because I have seen so many problems and solutions that there isn't a 1:1 connection between them. A diversity of problems and solutions means that you will see what underlying principles are common or contrasted between each approach. Then you can apply those basic axioms to make your own algorithms that are custom-suited to each problem.
I think a master programmer should have knowledge of the following areas:
- Something like Python (primarily dynamic types, primarily imperative)
- Something like Haskell (static types, purely functional)
- Something like Scheme (dynamic types, minimalism, lambda calculus)
- Something like Rust (static types, imperative, lower-level)
- Something like Prolog (logic programming, constraint-based)
- Something like Forth (stack and concatenative programming)
I would compare this to learning to be a chef. You can learn a lot of recipes from the best cookbook, but that just means you can cook a meal. To be an expert, you understand each component of the recipe and can mix-and-match, create substitutions, to create exactly what you want.
Edit: clarity
The secret is there is no secret. You keep hacking until suddenly you’re the one doing the answering instead of the asking. If you give up somewhere along the way then you were probably never cut out to be a programmer in the first place.
I'm glad I learned to program when computer time was costly (at least, for me, in terms of access time not in terms of money). I actually had to think about what I wanted my programs to do, design, consider. Not bash my head against a keyboard and pray like you did. This forced me to develop a model of the computer, language, and operating system that was fairly accurate (to the level of detail I needed at the time).
"Mastery" eludes most of us because programming has a very, very high skill ceiling. No matter how good you get in one aspect, there are other aspects that you still have a long way to go in before you get proficient.
Don't worry about mastery. Leave that to Knuth and John Carmack. Get good enough to build that thing you want, and then see how you can build it better (or a more complex thing). If you were meant to be a master, mastery will come if you follow the path, and you may not even know it when it does.
I was drawn forward into mastery by my pleasure. I like code, glitchy crashes and trippy stuff.
It's easy to become a master of X when you like X.
So step 1 is to like X.
Someone who's just repeated solving the same problems over and over again, has the latter, especially if they've only done it in a single language.
Or, to put it differently, progress needs to be measurable.
What I suggest is find some other interest that forces you to program. That way, the problems come from the subject matter, and you can't avoid the things that are hard. My interests were math, science, and electronics.
Either you have the skills to solve the problem at hand in a satisfactory way or you don't - but where exactly that line is is different for every problem.
One can display mastery over one set of problems and simultaneously have no mastery over another - maybe you know everything that can possibly be done using a tree data structure, but have never even heard of a bitmap.
Don't worry about "mastering programming" but rather worry about having sufficient knowledge of the right tools to solve the problem you need to solve.
Understanding the problem at hand such that it can be broken down into smaller and smaller chunks is really the problem.
After that it is refinements for robustness, maintainability, speed, size and so on, depending on the application, platform, language and approach.
The mastery defines the difference between a workable solution and an elegant solution.
I think that in my life I have met one person that I would call a master programmer. He was intimately familiar with C, C++, Java, Erlang, Perl, APL, Ruby, Python, Prolog, Haskell, Scala, and more. You could probably find a person that is more of an expert in any one of those, sure, but that’s beside the point. The reason this fellow qualifies as a master of programming, for me, is that he seems to have complete knowledge of where every language came from, how that influenced its semantics, what the pros and cons of each language’s design are, and could code more or less idiomatically in any one of all those languages and explain why it was idiomatic.
Based on that, I’d say that if there is such a thing as a “master programmer”, it’s probably someone so well versed in computational theory and language design that picking up a new language is just a fun afternoon.
I am sure others will have different viewpoints. This is my two cents.
Once I thought that there's no mastery in programming. That you just learn and kept of learning until you were ashes and bones. But that isn't true just as it isn't true for chefs, blacksmiths, painters, and other artists. If they have a certain standard where a practitioner becomes a "master" then so should programming.
I don't have a lot of experience/knowledge of how masters in other areas are judged but I see one common theme:
If you give a piece of rusted metal to a novice blacksmith, he wouldn't know what to do with it. Or even if he works it, it won't be something to be proud of. Give the same piece to a master and you won't believe what he makes of it.
Similarly, give an egg and some onions to a master chef and see what magic he brings.
Sure, knowledge about the trade matters and years of experience as well but if you strip all of that away, you'll see this steady confidence to be able to do anything (not bravado or foolhardiness) in their trade regardless of the resources and tools.
If we translate that to programming, we slowly realize that the toughest programmers are ones who can solve problems at every level, in any environment, under any condition. I am not saying that they are happy doing it (just as a blacksmith won't be happy working with rusty metal) but that they have the ability to just make things work and work in a good way.
All that may be very vague since its all just theory and I am basically thinking out loud but in these times when every one has the same access to the same information, I don't think it'd be a fair criteria to judge based on how many books you have read.
There's so much to be said on this to better classify the "mastery" of programming. In my opinion, masters of the trade are always rare. There are many who are close to this level of expertise but only a few you reach and surpass it.
Note: As I said, I am thinking out loud. I could be wrong and if so, feel free to point that out.
Start with a quest and use tutorials along the way if necessary. At some point those tutorials get in the way, drop them then.
Your first movie is going to be horrible. Your first game will be. Keep at it, make it better and better. Learn how others approach parts of games like you and understand how to apply them to your situation. At some point you will invest new ways.. share those, learn from feedback.
A game either starts with an epic idea and a struggle to create that vision or a cool hook that a game is built around.
What's someone like John Carmack then if not a master? I guess everyone's a master!