How can I learn to program without understanding programming?

Question

I have learned programming by both at recognized school and self-studying. If there's a sample, I can develop similar thing easily. But I don't understand any single purpose there. For example, I haven't learned and done any j2se coding & today at work, I have told to make a screen and validate and so on. I just studied the similar screen in that project and just do copy paste. And yes, modify something. Then my task is accomplished. But I don't know some main things in those coding like mediator, logger and so on. I tried to figure out what are those but I don't get it just by theory explanation. One of my geeky friends explained me that Logger is to send message to system. And I think "Send Message, what's this?" And today, my supervisor told that it's for debugging! I lost my confidence by thinking am I too far away from programming?

Here's my question: Is programming like this? Can we do it without understanding every single line of coding. I want to understand those concepts well till I can use it. If I study theory, I can't write codes according to that theory. If I study coding, I don't know it's theoretical purpose. What should I do?

Answer 1

One of my friends hates programmers because when we approach a problem, "if we don't understand it, we abstract it until we do."

The way that works best for me to learn, and that fits with this quote, is to break everything down into tiny, tiny chunks. Don't know how to do something? Generalize it, make an interface for it, and come back to it. It also has the wonderful advantage of producing seams for unit testing. Then, eventually, when you come back to write that chunk of code, you only have to focus on that chunk and getting what you need out of it. You don't need to worry about how it fits into the program, that's already defined. You have a smaller problem to figure out. And this can be continued ad nauseum.

This is usually the way I approach problems, but everyone is different. You can try different ways, but it comes down to what works best for you. Don't be afraid to try a new approach for a while.

Answer 2

When you are working on a new or already existing project, it is sometimes/most of the time normal to not understand every API or piece of code you're using. Trying to understand it all is a very natural reaction to most programmers but it can make you loose very precious time that would better be used to finish your assigned tasks.

You have a good attitude because you want to understand the unclear pieces of code. I think the best you could do is isolate the parts you find interesting and try to understand once extracted from the bigger context. You could, for example, create a simple console application to see how the Logger library works and see by yourself what it is useful for.

Answer 3

You sound like you need to read a few books on the programming languages you use at work.

Start with a good Java book: Effective Java

Answer 4

I believe the only way to learn what those lines of code mean is to start 'doing' it. Read up, and then do it. Perform the task of programming. Start by small example. Small pieces and make your way up. You should be fine.

Answer 5

To be a programmer you really need the ability to Learn (and perhaps to use Google). A huge part of programming (especially early on) is figuring out what your client wants, and then learning how to do that. Don't just stick with your own knowledge base.

Whenever I come across something new, something I don't understand, or something I'm not sure of how to do, I Google it. Most of the time I can find a simple definition or samples, and I can start from there. If I do start from samples, I hate just blindly copying/pasting. I always take the time to understand what the code does. It might be slower to start with, however once understood it makes me that much better of a programmer.

Answer 6

Its possible to code without understanding the code, but that's called 'programming by coincidence'. The problem with this approach is, when something breaks (that's when, not if), you won't be able to fix the problem because you on't understand what your program is doing.

It's hard not to feel overwhelmed as a beginner by the vast amount of information around but no programmer knows everything about everything and we are all still learners in that sense. When I come across something I don't understand I'll just go online and read about it. Then carry on - it doesnt matter if I don't fully understand what it means but just those 5-10 minutes of reading are usually enough to give me a basic idea.

The first most important step when extending or maintaining code that isnt yours is to figure out which bits are relevant to your problem. Then go and try to find out when each bit does and why.

So keep learning and good luck :-)

Answer 7

One thing that may be a challenge for you is taking what everyone says to be precise and literal. So logging generally refers to recording a log of stuff that happened. Sometimes it's in a plain text file, other loggers interact with the system (for example the Windows Event Log) for enhanced functionality. One person described this to you as sending messages and got you all tangled up with Send Message as an official meaning. Another person said it was a debugging approach (since if the app isn't working, looking through these logs can give you some insight) and got you confused because it has nothing to do with running an application under the debugger.

It is a great skill to be able to open something you don't really understand, change the parts that are important, and ignore the parts (in this case, Logger) that probably aren't important. It's also a great skill to be able to slowly absorb architecture, infrastructure and plumbing that others have put into place, so that you can work with it when the time comes. And it's a third great skill to recognize a metaphor or analogy and not expect that all answers are precise and specific. The tone is more important than the words - they both told you that how Logger works and even exactly what it does isn't important in the context of the task you were given. But remember the second great skill -- eventually you should understand Logger and the rest.

Answer 8

To benefit from theory, you need to be able to apply it to your code. Why doesn't work for you can have many reasons, but judging from your logger example, one problem might be that the theory you receive is too high level for you to see the link to your code. If that is the case, you need more concrete theory; if it is unclear to you what a message is in that context, ask!

Simply copy&pasting code won't help you understand it, and will not empower you to fix any bugs or shortcomings that code might have. To become a good programmer, you must understand.

As for sources of information, I personally prefer authoritative sources over what anybody has put on the internet. In the case of Java, that would be:

• The Java Tutorials
• The Java Language Specification (hard to understand by new programmers, but accurate)
• The Java API

Libraries (such as the logging library) often have tutorials and reference manuals on their home page. They also have Javadoc.

Answer 9

Wait, you don't understand really anything about programming at all, and you are employed in programming? You aren't cut out for this. If no matter how hard you try, you cannot understand both the theory AND the application, you are in the wrong industry. Work at a fruit stand.

---

UPDATE

I'm realizing that my first answer was pretty bitchy, so let's try this again. I was once like you (where the things that 'cool' programmers did seemed like a foreign language that I was never going to be able to understand). How did I change that?

1. Go through lots of tutorials on neat, abstract things, even if they aren't immediately practical.

2. Surround yourself with people who are at least 5* smarter than you are. This one is really important! The only reason I got into programming again, and improved, is that one of my friends (@jtbandes) always made me feel completely inadequate with respect to my ability to reason about software, not by means of any ill-intent, but only by means of his total awesomeness.

3. Try to build something that matters to you. Please, start small. I tried to start big, but quickly my projects were limited by my weak ability to do things properly. Even now, I won't touch many of the projects I started on at the beginning. But right now, I'm actually building my first Mac application, because I had a need, and I'm going to fill it. Find something like that, and start simple.

4. Keep hanging out on Stack Overflow. 95% of the people here are complete idiots, but the remaining 5% are TITANS. Listen to what they say, but don't be afraid to disregard it; chances are, you'll figure out where they were coming from and internalize why they were right. Making mistakes by yourself in a controlled manner is extremely important.

5. Once you start making things that you are proud of, write a blog about them. This will help you be more rigorous about your reasoning (because now it is laid bare in front of a large audience), and will motivate you to do really cool things. Mine is here: http://jonsterling.github.com/.

I truly wish you the very best of luck in your journey; initial self-disgust is the first step on the path toward something to be proud of. I truly apologize for my initial, rather unhelpful response: sometimes, after seeing so many hair-brained questions on Stack Overflow, I often forget that my duty is to be helpful, not bitchy.