21–30 of 53 posts
It means you're pushing yourself out of the comfort zone, staying current.
But it's also important to detect when you should "give up" or not invest time in something that is just too painful (I personally gave up on EJB, or temporarily on C++ to go back to Pascal, then back to C++ a few years later).
Immediately.
Like in the first 5 minutes. When I was seven years old.
And frankly, if it didn't happen like that for you, you're pretty much screwed.
Every good programmer I've ever known started doing it young and immediately just "got it". Most mediocre programmers I know followed the path you're on, learning it in a class in school, fighting to get things done, eventually coming up with ways to solve particular problems, but never attaining fluency.
Try not to feel bad about it. It's just about the way your brain is wired. Good programmers have a specific something wrong with their brain that makes them ridiculously good at logic, and, sadly, not very good at much else. We can overcome the "everything else" part through hard work, though we'll never be as good at it as you. Similarly, you can overcome the programming part through hard work, but you'll never be as good at it as us.
Sorry to be the one to break the news.
I cannot stress this enough: learn refactoring , http://www.amazon.com/Refactoring-Improving-Design-Existing-... You will simultaneously learn: - terminology and models relevant to software design and construction at every level - principles of good coding and how to tell good code from bad - the ability to redesign code as needed - the experience and knowledge necessary to approach coding with confidence All of thes…
I don't think that's good advice for a newbie. To the OP: practice, practice and practice. It will take a long time. Months to start getting it, years to go anywhere. 10+ years to be good. If it's too hard, choose another profession. 99% of folks out there would hate programming.
But more than that, refactoring provides the mental models and the vocabulary to talk about, reason about, and understand code. It provides well-worn expert advice about the characteristics that make good code good and bad code bad, heuristics to be able to recognize good and bad code, and basic techniques to transform bad good into good safely and effectively.
There may be some advanced techniques in the book itself which won't be useful to beginners, but that's true of any programming book, and that's easy enough to skip over and return to later (especially with the organization of the canonical refactoring book specifically).
A beginning programmer who has learned even the simplest of refactoring techniques (extract method, insert/remove cached value, etc.) will be able to look at a piece of code and see the ways it can be changed, and will also have a reasonable idea about which changes are more likely to improve the code. They will also have the mental models and vocabulary to talk about, reason about, and understand the code, even if only to themselves. These tools are hugely important for beginners. They can transform coding from a task filled with uncertainty, fear, and irregular advancement born from experimentation to a task filled with confidence, knowledge, and curiosity.
Certainly practice a lot, but don't just blindly stumble about on your own, there's lots of good material out there, learn the techniques and then practice applying them, build up your toolkit a bit at a time until you feel more and more comfortable with coding.
You're not going to like the answer, but: Immediately. Like in the first 5 minutes. When I was seven years old. And frankly, if it didn't happen like that for you, you're pretty much screwed. Every good programmer I've ever known started doing it young and immediately just "got it". Most mediocre programmers I know followed the path you're on, learning it in a class in school, fighting to get things done, eventually…
Try not to feel bad about it. It's just about the way your brain is wired.
What got me through was learning to break problems up into tiny pieces, practicing and learning patterns, and ignoring advice like "if you don't get pointers straight away you'll never be a programmer".
For example, a pattern you use all the time is open a file, read some data, close the file. More than half the people I've interviewed as programmers can't do an adequate job of this from memory in their language of choice. Practice just that until you have it memorised and can type it out at speed.
Look at programs as collections of patterns, and look for excuses to practice dumb simple stuff (like scales in music). Something I knocked out over breakfast on Sunday morning to price a collection of stocks: I have a file containing a list of symbols. The program reads this data. It splits it into tokens. It uses a yahoo web service to look up prices for them. It collects the data in an object. I pass that to a formatter. Then I print it. I built each pattern independently, and then stiched them together. Some people do test-driven development to force themselves to construct software in this way, and you might find that useful (I just do it that way without formalising the tests).
amorphid wrote,
Maybe I'm the opposite of a natural.
amorphid - I don't know what your problems are specifically but maybe some of that will be useful.
Edit: I made a claim at the top that I couldn't reference. Removed.
If that doesn't help, then maybe you need to take a good CS course. If you have only programmed in C++, then it doesn't sound like a comprehensive background in CS.
You're not going to like the answer, but: Immediately. Like in the first 5 minutes. When I was seven years old. And frankly, if it didn't happen like that for you, you're pretty much screwed. Every good programmer I've ever known started doing it young and immediately just "got it". Most mediocre programmers I know followed the path you're on, learning it in a class in school, fighting to get things done, eventually…
You're not going to like the answer, but: Immediately. Like in the first 5 minutes. When I was seven years old. And frankly, if it didn't happen like that for you, you're pretty much screwed. Every good programmer I've ever known started doing it young and immediately just "got it". Most mediocre programmers I know followed the path you're on, learning it in a class in school, fighting to get things done, eventually…
Try not to feel bad about it. It's just about the way your brain is wired. No. I spent an entire summer staring at C and getting blocked on ridiculous basic stuff because I had dumb learning techniques and kept being too ambitious. I know a solid guy who did first-year C three times before he passed. What got me through was learning to break problems up into tiny pieces, practicing and learning patterns, and ignoring…
Sounds like we're just using different definitions for "good". You seem to define it as meaning competent, so yes, you and your friend fall into the category of people who have successfully taught yourself to program computers despite not being wired to do it.
I was talking about the Fred Brooks 10X types when I said "good". Those guys didn't drop Comp Sci 101.
Again, please try not to take it personally. They're not better people than you. They just took to computer programming like everybody else takes to breathing.
For some people programming can make sense, for others it's just a craft that's in the hands. When I was at the university lots of people struggled with "understanding" programming and they wrote little code, trying to more to come to terms with what programming is rather than trying to do it. The people that succeeded in learning to program wrote lots of code even though it was hard to write the code and to understand. Some of the people that didn't never entered their programs into computers and just ran the code by hand on a piece of paper (to what practical use is that?).
For me programming is in the hands. When I learn a new programming language it's total chaos for 1-2 weeks and then the new regime settles and I can understand what I have been doing. After half a year of being exposed to a new programming language even more of the teachings settle and I can begin understanding more, but programming it's a practical art. I suppose it can be different if you are more mathematically minded than I am.
I suggest doing ALL the exercises in a programming book - as fast as you can without trying to really understand what is going on behind the scenes. The secret is that you don't have to really understand what the hell is going on behind the scenes, you just have to know enough to stay out of trouble and that knowledge comes from experience. In the beginning of a programming career it'll be impossible to guess what weird bugs might occur so just code and see what happens.
In short, you have to have a lot of practical knowledge of programming to support your theoretical knowledge, otherwise you cannot do anything with either. A chicken and egg situation, so it's best just to jump into the deep waters and try to swim to the surface.
Earlier quoted context omitted.
Try not to feel bad about it. It's just about the way your brain is wired. No. I spent an entire summer staring at C and getting blocked on ridiculous basic stuff because I had dumb learning techniques and kept being too ambitious. I know a solid guy who did first-year C three times before he passed. What got me through was learning to break problems up into tiny pieces, practicing and learning patterns, and ignoring…
I spent an entire summer staring at C and getting blocked on ridiculous basic stuff because I had dumb learning techniques and kept being too ambitious. I know a solid guy who did first-year C three times before he passed. Sounds like we're just using different definitions for "good". You seem to define it as meaning competent, so yes, you and your friend fall into the category of people who have successfully taught…