Of course, programming jobs do exist where you do the same thing over and over again. And there's a threshold of skill required before you can automate some classes of things; and you also need a clear understanding of the task, to see precisely which aspects are mechanical, and which aspects are configurable. It pretty quickly gets into compsci research. And sometimes it's not worth the effort (it can take a lot of effort.)
But if you've ever called a method twice, instead of writing the code twice, then you have done some of it.
I feel that your question "start to make sense" suggests your thinking is all-or-nothing. Does no aspect of programming make sense to you - or do some "trivial" aspects make sense but they "don't count"? Does a print statement make sense to you, to some extent? Does a loop make sense to you? There's a continuum of mastery. If you only acknowledge perfect and complete mastery as "mastery", then you won't feel any satisfaction in mastery of one small bit of it. And without the confidence and encouragement of that success, it's very hard to be motivated to continue. (oh yeah, plus, of course, it's impossible to have perfect and complete mastery of programming anyway, for Turing's reason.)
I can't write code on my own, though -- unless the problem is trivial and the APIs I'm using I know like the back of my hand, I need an Internet connection to do it.
Part of this issue is possibly that competent people are disproportionately stalked by the worry that they're secretly incompetent.
It be interesting to see what the numbers are of people who need to be connected versus people who code in solitude.
It's probably slow because you're not having fun with it. You're probably not having fun with it because you're not solving a compelling goal. Ask yourself whether you're learning "just to learn it" or are you trying to solve a problem and this particular language/api/compiler/implementation will help you achieve that goal.
I might be presumptuous here (and I apologize if I'm wrong) but the times I've found myself stuck "learning" have been when I was just going through the lessons for the heck of it, without a real goal in mind, without something to accomplish.
Also, have a look at this: http://railstips.org/blog/archives/2010/01/12/i-have-no-tale... I found it inspirational.
Just trying to say, learning is not always fun. Get a job doing something you don't know how to do. Maybe that will motivate you. :)
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 these are the most critical tools you need to transform yourself from someone who sorta-kinda knows a few principles of coding to someone who groks software construction.
If I had to choose between a co-worker who truly groked the principles of re-factoring and a co-worker who had a PhD in Computer Science I would choose the former every time. It's really that important.
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.
However, eventually things start to click (though it took me several years). You'll get to a point where things make sense, and you can fathom how you'd go about writing most of the software you use on a daily basis.
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.
For a few years I only played games, and sometimes entered some example BASIC code and tinkered with constans in code to see what will happen. I remember that my copy of manual had error in some magic graphic system initialization code, so I've never programmed graphic on C64. It was very frustrating.
Then I've got PC when I was 15 and I played with Turbo Basic, then Turbo Pascal - then I've understood variables and it all started to make sense. Since then I only feel like I know less, and less :)
PS - the most impressive thing I've seen that encuraged me to keep programming was ASCII art adventure game written in windows batch files. I've thought - if someon can do so much witch bat files, I can do everything with my knowledge of Turbo Pascal :)
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).
I started programming (Qbasic) at the age of 12. My first programs were just some combinations of blocks of code taken from the help document. Until 18, I had been always an amateur programmer. Then Things changed. Programming can be flipped from fun to work. I can get paid to have fun, so why don't do it?
I was introduced to the real world and I discovered that my knowledge, as huge as it was (a little from everything) wouldn't really help building the smallest application. I also can't write code on my own. I need another application to copy from or re-use the code. My frustrations began, but they lasted short.
I started reading books. My target was Visual C#. I read a book about .Net fundamentals and another one about Visual Studio. I become a better programmer. It did took me months to understand OOP, but I finished by mastering it. And yay! I used collections.
I left Visual C# and decided to develop for the web. I planned to learn it from scratch. From the start to the end. First, I need a strong knowledge about the Client Side. That is HTML, CSS and JavaScript. The first two are somewhat easy to master and learn. JavaScript is very expressive and can take a while to master.
Actually, I felt in love with JavaScript and with it's prototypal and dynamic nature. I'm 19 and I already built 2 scripts that I'm selling on code canyon (I'm working on the third right now ;)) Suddenly while browsing on the web, I found a small niche, that can be valued to $100K/year. It's hidden somewhere and related to JavaScript. No one explored this domain (except low-quality Open Source solutions) I made my researches, grabbed a related domain and making a plan.
Learning Programming? Oups! I forgot about it!!!
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.
I'm certainly not saying you should go write up a design document complete with UML and everything. That would be ridiculous, damn it I'm an engineer not a bureaucrat! Just sit down and think (on paper) about how some of the important stuff needs to look. It'll help a lot.
As for the second point, C++ does seem like a weird place to start. Go learn assembly or C. Learning to write assembly is a process of continually solving tiny programming puzzles, as you figure out how to hand-roll a loop and such.
Maybe you need to stop 'learning' programming and just do it. Pick a task you want to complete, possibly even a task you've done before, and just do it.
I learned all those other languages and language variants starting with the same program: Sierpinski's Triangle. Why? Because I already knew the logic for it inside and out and it was entertaining to watch. Every new language I came across, I wrote another Sierpinski's Triangle program on it as my first program.
For some time it's not technical difficulty that prevents me from acomplishing my programming goals, but my laziness.
I am very good at learning new languages, APIs, programming techniques, etc, because that offers me fast positive feedback. I feel good because I've learned sth new.
But to achieve anything I have to sit down to real, boring work, and this I am to lazy to do. I prefer to try new cool languages than do any useful work in languages I already know. I feel worse programmer than I was when I only knew Basic and Turbo Pascal, no matter all the techniques, design patterns, languages, etc, that I now know.
Do you have similiar experiences? How do you deal with this?
Just when you think you've finally gotten a solid grasp on writing CRUD apps in PHP, someone shows you Haskell, or Prolog, and suddenly realized just how little you thought you knew.
That said, this all makes for programming being an excellent domain for both a career and a passionate hobby. Easy to learn (a tiny corner) and hard to master (a chunk you can really appreciate 10 years in) -- what more could you want?
"Programming, as a whole, is far larger than any one person could come to comprehend in a single lifetime (...) And to make matters worse, it is continually growing more complex at a rate no person could follow either!"
Isn't programming, essentially, the writing of instructions and providing them to systems that act upon them? Reading through that statement I wonder whether it's not programming that is complex, but many problems that exist in various fields of business or study—problems that need a programmed solution.
Please—if you don't mind—would you elaborate?
Unfortunately, it's both. ;)
While PHP is indeed a programming language (the term "scripting language" is a fairly meaningless label) when you work in PHP building web pages you're likely to spend most of your time working on things that are computationally tractable [1], but hard because it's just hard to translate the customer's problems into code within the available budget. Your customer has a problem, it's lots of work to map that problem onto code, it's hard to explain to the customer just how much work it is to turn the "simple" activities performed by (say) their administrative assistant into algorithms, and the result tends to be expensive to document, deploy, and maintain. So, yeah, it's the problems that seem to be hard, not the "programming" -- though, in fact, there is no hard-and-fast distinction there.
But then there are problems in programming that are difficult to impossible, all by themselves. The CS folks around here can point you at plenty of them, but here's a famous one:
http://en.wikipedia.org/wiki/Travelling_salesman_problem
which is a member of an entire class of famously hard-to-compute problems:
http://en.wikipedia.org/wiki/List_of_NP-complete_problems
which (I believe) are not particularly rare, but which come up in various disguises, and which must be carefully worked around.
On a somewhat more applied level, there are lots of difficult problems in code optimization that you can work on:
http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine
Or you can spend your day exploring a giant set of data-storage possibilities, each of which is right in its own way, and wrong in its own way:
http://en.wikipedia.org/wiki/CAP_theorem
http://www.allthingsdistributed.com/2008/12/eventually_consi...
One may suspect, of course, that this distinction I'm trying to draw between "difficult programming" and "difficult problems" is not real; it's just a matter of the degree of abstraction you use when describing the programming. And I think you'd be right to suspect that. Programming is programming, and programming is hard.
---
[1] Though it is very, very possible to put something that is computationally intractable into a "simple" web page. Web pages have no upper bound of complexity.
Be patient with yourself, don't let frustration get the better of yourself, keep trying, get immersed and give yourself some time.
For me, it took quite some time of interspersed half-hearted attempts, then accidental and incremental opportunities to do increasingly complex tasks that I could learn and scale (on different environments, SAP, NC, Excel Macros, JMP), then some big time immersion over 4 weeks with David Power's books (his style clicked for me). I am no expert now, but am doing stuff that I didnt' think I could.
Would have to disagree about the "Natural" part of your comment. Keep working at it.
Good luck.
Since then, I have picked up new languages that interest me far more rapidly. I don't focus on how it compares to any other language I know or use. I don't focus on it from the perspective of how classes and functions differ. I look at any new programming language from a grammatical and syntactic view--and once I have read enough code & documentation to understand its grammar and syntax, I can start coding productively. That's the point I begin studying classes, functions, built-ins, libraries--the grammar and vocabulary of implementation.
I am by no means an expert programmer. I'd never call myself that. But I do find that many would be better programmers if they understood the "language" of programming. Learn as much as you can stand about data structures & types. This is core--especially types. I have so often been frustrated by inherited code that didn't show a solid understanding of data types (e.g., strings, ints, arrays, etc.). Learn about classes, functions, inheritance, etc. These are the building blocks of language, if you'll permit extending the analogy--it's a bit like knowing how to structure a sentence, capitalize, punctuate, etc. Learn the language of programming before you ever try to learn a programming language. This is, perhaps, what you're missing. You're using a programming language to understand programming. Take a step back and understand programming itself first. Then sit back down with your language and do programming.
Regardless of chosen language, the task is the same and the result should (usually) be the same. The chosen language is really just an implementation detail. You can write a program in Ruby, Python, C, PHP, etc., and it's still going to be the same program. Most programmers, I believe, tend to choose the grammar & syntax they like best. But the job of programming remains the same.
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.
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.
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.
It's like any other thing really. Football, Soccer, Jiujitsu, Ping-Pong, etc.
Beating your head against a problem for hours is the best way to learn something (because you learn all the ins and outs of that thing, not just the part you were working on).
Take a look at http://users.evtek.fi/~jaanah/IntroC/DBeech/3gl_flow.htm and get the gist of the symbols, then chart out things like if, if/than, while, for, etc. Don't forget do/while, since this is also a fundamental, but its not always represented in your language of choice, and is sometimes simulated with things like an infinite loop with a break.
Move up to some simple programs. These symbols don't represent data structures (arrays, objects) so you can fudge that part.
When it clicks then stop using it. But keep in mind, when you run across something where the logic is confusing, or especially if you can't figure out a clean way to represent the flow, come back to your old friends, and you'll be amazed at how they will guide you. I still fall back on flow charts, they aren't a crutch, they are a tool.
IMHO all of the UML diagramming software are a bunch of crap but being able to understand a bunch of code as a picture should help allow your brain to see the forest for the trees.
Could you share with us what books and programming languages/tools you've been using? While there are certainly common ideas, different types of language take a different approaches to describing a program. Maybe whatever you've chosen doesn't suit your way of thinking particularly well, and you would find another tool more intuitive at this stage.
a) You don't understand what the problem means.
b) You can't describe an algorithm that would solve the problem in plain English or "pseudocode".
c) You could describe the algorithm informally, but don't know how to code it.
re "practice framing": I find that asking the question is very helpful for clarity - and then defining the key nouns in it.