Sign up ×

I'm a beginner in programming and I've been reading books, studying, reading articles, and whatnot. I'm getting great results since I've started learning programming, and when I was a beginner I used to think I knew everything about programming, but as I learned more I realized how difficult this field is (In fact all fields are difficult, but that's not the point).

Nowadays, I've written functional software and I've learned the BASICS of 3 languages and I'm intermediate in just one language. When I look at advanced things like MYSQL, or OpenGL programming, or even visual studio C++ code it gives me headaches, and even when visualising HTML source code of many websites (Most source codes on websites, seen by google chrome seem very messy and unorganized) it makes me confused to the very limit of my brain. It all seems simple at first, yet when looking at these advanced things it just makes me wonder how can one learn so much.

The question, in a nutshell, is if these things become clearer to a programmer as he advances in his career. Do complicated topics as the ones listed above (OpenGL, MySQL, advanced html sites) become easier to read, write and understand as you learn more, or does it just get more complicated as you go by? How can you combat this feeling that you're an ant in the programming world and this stuff is the foot about to squash you?

share|improve this question
I suggest you read this: – James Poulson Feb 18 '12 at 18:03
Very useful link. Thanks – Bugster Feb 18 '12 at 18:08
Like anything else, yes. Until the technology changes on you. :-) – MathAttack Feb 18 '12 at 18:22
As long as your "experience" isn't reading the same things over and over. Stretch yourself with new stuff. – JeffO Feb 18 '12 at 18:39
"when I was a beginner I used to think I knew everything about programming." Been there and the more I learn, the more I realize how little I know. – Lieven Keersmaekers Feb 19 '12 at 11:07

12 Answers 12

up vote 116 down vote accepted

Short answer: no.

Long answer:

Reading code of other people becomes easier, yes. But only reading. As you gain experience and skills, your personal requirements as a developer grow.

  • You don't want to just write code. You want to write beautiful code.

  • You don't code for optimistic flow. You start to think about all bad things which may happen when running your code, handle exceptions, think about hardware problems, network latency, and the problem grows as your skills grow.

  • You don't read and write code in the only language you know. As a skillful developer, you know that to solve this specific problem you have right now, functional programming is a much better alternative, so you must now read and write code in functional programming language.

  • You don't limit yourself to a small set of libraries you know. If you code in C#, you want to know and use the full power of many libraries of .NET Framework.

  • You don't use notepad any longer. You need your powerful IDE, and you want to know how to unit test code, what are code metrics about, and what is the meaning of hundreds of options and windows your IDE can show to you.

  • You don't want to modestly limit yourself to a basic set of tools the language gives you. In C#, you want to use generics, code contracts, reflection, event-driven development, functional aspects with LINQ, Reactive extensions, and ton of other stuff you learned, all in a single project, if those things help you to write better code.

  • You don't start writing code. You spend 80 to 90% of your time gathering requirements, creating the architecture of your application, writing unit tests, writing documentation, etc., and only 10 to 20% of your time writing actual code.

  • You care about security. You know the legal issues which may arise with the data manipulated by your applications. You know what is ITIL. You know some ISO standards and you apply them daily in your work.

Yes, you gain experience and skills, and it becomes easier to solve a given problem with all the knowledge and intellectual abilities you gained. But problems you must solve grow too, and you're just not excited at solving the problems of the level of those I've solved when you started programming.

While gaining skills, you also gain in insight on the complexity of the software development, learn the aspects you couldn't even imagine when started to learn programming, and you want and need to apply all the stuff you learn daily.

In short:

  1. The first day you start to learn programming, the task of listing all numbers from 1 to 100 divisible by two is very complex: you just learned how to make loops and display numbers on the screen, but you have no idea how to find if the number is divisible by two.

  2. Ten years later, the same exercise appears to be extremely simple. But also, ten years later, you're writing applications which must use transactions, are hosted on several servers and must handle session state properly between servers, and is storing bank account details of your customers, with all the resulting security and legal aspects.

  3. ... And you are wondering yourself "How could I possibly do that?" in the exact same way you did ten years ago when you had to display numbers to a screen with a loop.

When everything becomes easy to you in a domain, it means that either you achieved perfection in this domain, or you just don't care any longer.

Achieving perfection in a domain as vast as software development is impossible, no matter how smart you are.

share|improve this answer
Walking on water and developing software from a specification are easy if both are frozen (it shows that "You don't start writing code. You spend months gathering requirements" is a bit unrealistic) – J.F. Sebastian Feb 19 '12 at 0:04
"functional programming is a much better alternative" is debatable. – J.F. Sebastian Feb 19 '12 at 0:11
I certainly hope the "functional programming" bit is just an example of "use the right tool for the job" rather than implying that functional programming is actually better for general use. – Ben Brocka Feb 19 '12 at 0:51
I'll also note that "months gathering requirements" with no development is only going to happen in basically an idealized Waterfall model. If you're not iterating you're killing yourself and the project. – Ben Brocka Feb 19 '12 at 0:53
"It never gets easier, you just go faster." /Greg LeMond/ – daGrevis Feb 20 '12 at 8:51

As a child, you learn to speak and then to read your native language. The plain mechanics of it are a struggle at first, but at some point it comes fluently. However, you still have an infinite supply of books you haven't read, and on some topics you have to increase your vocabulary first just to be able to understand the book.

The same goes for computer programming. At some point the language itself stops feeling like a foreign language, but there's still a lot of stuff written in that language that you don't know yet. But everything is accessible to you with some effort.

Some programming jobs are very repetitious, basically re-implementing very similar software for different customers. In those jobs you might feel like you hit a plateau of learning. Other jobs you are doing something new and unique all the time, and never stop learning new things.

share|improve this answer

There are some really good answers here already but I thought I might add a couple more short points:


This is called the Dunning-Kruger effect. It is extremely common amongst beginner programmers, and in fact, beginners in many fields.


Did the people who wrote those web sites want you to be able to understand them? Probably not. It is in their interests to have code that is difficult to understand.

it just makes me wonder how can one learn so much.

By specializing. I am an expert in an extraordinarily narrow field: the design and implementation of C# compiler semantic analyzers. If I'd spent fifteen years studying OpenGL or XML or HTML or whatever, I'd be an expert on that and mystified by semantic analyzers. But I didn't, and thus I have only a very basic understanding of OpenGL, XML and HTML.


Yes, because you start to see the larger patterns. Take OpenGL for example. You've probably seen a bunch of "API libraries" -- big pieces of related code where the way you interface with the code is by calling a bunch of named functions with particular arguments. And you can get a basic understanding of OpenGL merely from understanding that it is an API.

When you've gotten more experience and seen a bunch of different programming techniques, you realize that seemingly unrelated technologies -- say, OpenGL and LINQ in C# -- have commonalities. Both are APIs where you build workflows that pipe data around, and that you can run optimizers and other transformation on the workflow in rich and interesting ways. Once you have that concept in your box of tools, suddenly it becomes much easier to tap into the full power of any API that uses that pattern.


They become both easier and more complicated. Easier because, like I said, you start to recognize the larger patterns of thought that underly the design of the system, which enables you to use the system more effectively. More complicated because now you can use the system to solve more complicated problems, and you then start to run into the limitations of the system.


You're an ant; we're all ants. But the stuff isn't the foot that squashes you; it's the world that you get to explore, live in, benefit from, and improve. You, ant, only get to explore a tiny, tiny part of it. Pick a part you like where you can add real value and become an expert in it.

share|improve this answer
Thanks alot for this answer, it's above the rest of ones because it doesn't just answer my main question, but also opens my eyes on certain things. +1 – Bugster Feb 19 '12 at 17:40
@Eric: What would you say to a person in this kind of topics where he says "specialization is for insects, not humans"? – Joan Venge Mar 9 '12 at 1:32
@JoanVenge Would someone say that? Usually people are all about specializing and being unique, and much more so if they feel the need to distinguish themselves from animals (or insects). – Matthew Read Jun 4 '12 at 17:45

Short answer, Yes.

Given time and exposure these things become easier to comprehend.

Remember when you are looking at sites from the dev tools in your browser they are often generated by a framework. Let that be any number of things...ASP.NET, JSP, RoR, Django,...who knows. Some of these frameworks produce cleaner code than others.

In closing...exposure leads to proficiency. There is no way to quash that feeling. Just experience and learning. It takes time to move in, gain domain knowledge, and learn the skills your environment uses.

share|improve this answer
There is some truth to this as long as the person who wrote the code was using good practices and the usual idioms of both the language in particular and of programmers in general. Bad coding and/or deliberate obfuscation can slow you back to a crawl. Try dropping by CodeGolf.SE. Even the "in the clear" versions can be tough slogging because good practices have been sacrificed at he alter of the contest metric. – dmckee Feb 19 '12 at 21:14
@dmckee Even bad code becomes vastly easier to read with experience. I notice this in particular in C++ (and I’ve had to read lots of bad code). Of course it’s an extreme hurdle but it nevertheless becomes much easier once you start spotting patterns of bad design and common errors. These also form a kind of idiom that you will learn. – Konrad Rudolph Feb 20 '12 at 11:49

The short answer is YES but a lot of it depends on how you define experience.

I think there are at least 3 parts to development. As you get better at each segment, certain things become clearer.

  1. Understanding the BUSINESS requirements. This gives you a better bird's eye view of the application. The better you can understand why the business rules are what they are, the quicker you pick up on why certain things are done in a certain way. E.g. Your customers need to comply to government regulation X, which is why they need to prepare document Y, which is why they need this seemingly useless information stored.

  2. Understanding the TECHNICAL requirements. This is like #1 except its more about understanding why on a technical level. Some tools and technologies have their own quirks, until you have dealt with them before it's hard to understand why things are done in a certain way. This is more apparent when you deal with legacy systems. E.g. The application uses a particular service bus that only takes XML.

  3. Understanding the LANGUAGE requirements. Like others have mentioned, the more experienced you are with a language, the quicker you can read what the original coder was trying to achieve. Yet without #1 and #2, you will find that this increased ability peaks pretty quickly.

Try to be involved in multiple aspects of development because it really doesn't become easier until you have done all the areas at least a few times.

Remember that perfection (and purpose) in someone else's code is always relative to #1 and #2. These are the primary drivers of why the code is in the state it is in. Frequent changes in those two areas are the biggest reason why we get spaghetti code all the time. So unless you are adept at reading the business and technical requirements, the task of reading code will always be a royal PITA.

share|improve this answer

I think you are mixing two questions: 1) Does it become easier to read code? 2) Does it become easier to write code?

The answer to 1) is yes, because you get better a identifying patterns and guessing the intent of the code, even when it's incorrect.

The anwser to 2) is often no, because you move on to more difficult problems as you gain experience.

share|improve this answer
I did formulate both questions however thanks for the late answer, despite it has been answered it still helps. +1 – Bugster Feb 22 '12 at 17:41

I agree with some of the answers already given but I think they're also an underlying point not being discussed about reading code. When I first started looking at some open source code it seemed overwhelming and huge. But guess what? it's always going to be huge. At some point you realize you get better at extracting what you specifically want to know and moving on.

One example you gave was looking at a bunch of HTML code, however:

Why are you looking at HTML code? Probably not because you want to learn the HTML of the entire site. There's probably a specific trick you are hoping to pick up. In that case, just find the relevant HTML with a tool like firebug.

If you really want to learn how the whole site is made, you realized rendered HTML is not the way to do it. You would be better off looking at an open source project using similar technology. However, trying to learn an entire project's code is not as worthwhile as it sounds. It's boring, time consuming, easy to forget what you learned, and you have nothing to show for it at the end. You will learn less from reading other peoples' code endlessly and much more by using specific, interesting pieces of it to write plugins, feature additions, or as scaffolds and advice for your own projects.

Try to learn the absolute minimum to get something of your own working. Only go back to your reference points when you get stuck or want to learn a specific new thing. This goes against some conventional wisdom that you have to understand everything or else you're programming in the dark. But eventually you realize that goal is impossible and you learn to balance the goals of knowing everything and the goal of actually finishing what you're working on.

share|improve this answer


I'm going to take a slightly different tack than the other respondents; I believe that reading and writing code does in fact get easier as you do it more, and I'll demonstrate it with a simple analogy.

Think of when you first started playing sports. At the very beginning with the first sport you learned, basic coordination for the simple tasks of a single sport probably seemed really hard. As you got a little more experienced, you started mastering the simple tasks so that you didn't have to think about them any more, and you noticed that there were more complex tasks that you could pay attention to (like watching other players to predict their behavior).

Then, when you tried your hand at another sport, you probably found you weren't so far behind when you started out. Catching a basketball is much different than catching a baseball, but somebody who's mastered one of them will have a much easier time picking up the other than a person who's never done either one before. With your experience practicing a second sport, you discovered that the first sport gave you both specific and generic skills. Specific skills (catching a basketball) are useful only in their domain, but generic skills (tracking a fast-moving object approaching in three-dimensional space and developing a plan to deal with it) make you better at all related domains.

What does this have to do with programming? The first line of code you read exposes you to a world built on certain rules. You learned those rules (that language's syntax and idioms) as specific skills, but you also learned some valuable generic skills: understanding how computers operate internally, and how to express your intentions in a way a computer can understand. Each new language you learn gives you some new specific skills, but it also strengthens your generic skills and helps you see the patterns shot through all computer languages like mineral deposits layered along a canyon wall. Once you get really familiar with a few different languages, you start being able to recognize the "shape" of most any code, if you'll pardon the vagueness, even if you don't know anything about the language it's written in.

For instance, all three languages you mentioned (MYSQL, OpenGL, C++) have some common features:

  • It's possible to compute small parts of an algorithm separately and compose them into a complete solution later on
  • The computer usually requires some amount of general preparation before you can start working on your specific problem (creating a table, initializing a canvas, or perhaps loading common libraries)
  • Earlier statements take precedence and affect later statements, i.e. the computer starts at the top of the code and works its way down

The more programming you do, the more you'll realize that no matter what the ball is shaped like, it's still just a ball coming towards you, and you know what to do with it without having to think too much about it. All programming is about attempting to express your intentions in a way the computer can understand; learn enough and you'll start to be able to read the intentions instead of the code.

P.S.- Each and every time, when you finally start feeling like you know your way around, you'll run into something that absolutely breaks your brain and makes you feel like a rank beginner. That's what we love about this job, there's always something new to learn.

share|improve this answer
This is also a great answer, thanks. – Bugster Feb 19 '12 at 8:47

It gets easier and more complicated at the same time!

Knowing others is wisdom;
Knowing the self is enlightenment.
Mastering others requires force;
Mastering the self requires strength;
He who knows he has enough is rich.
Perseverance is a sign of will power.
He who stays where he is endures.
To die but not to perish is to be eternally present.

translated to Software Development

Knowing lots of technologies is wisdom. ( Everything descends from ALGOL )
Knowing what you don't know is enlightenment. ( LISP )
Mastering lots of languages, frameworks and platforms requires lots of effort. ( Java )
Mastering only what you need to know and only that requires strength. ( and Google or )
Knowing when to stop coding and deliver something is when you know good enough. ( No Analysis Paralysis or Gold Plating )
Keep working at what you are trying to achieve, it requires focus and will power. ( Everything constantly changes, you are never finished )
Stick with one or two technologies and you will endure. ( COBOL still pays well, as does C )
To quit programming and move into management is to be eternally present. ( or leave a legacy of FOSS software that everyone will continue to use well after you are dead ).

share|improve this answer
So instead of being an ant you should be a cockroach and just get up when it squashes you, am I right? :-P – Bugster Feb 19 '12 at 8:48
"Analysis Paralysis" != "know when to stop coding". It's more "know when to start coding". – Ben Voigt Feb 19 '12 at 16:02

Short Answer: Yes, in general

However, you will not become a specialist if you generalize. Becoming a specialist also means realizing all the things you do not know: this is can be an overwhelming feeling.

As you move through time, you gain experience.

As you move through time, other languages/patterns etc are developing parallel to your development.

Another variable to your question, is if you are gaining meaningful experience in relation to the industry as it also moves through the same constant time. The tech industry is a moving target and unlike most other industries.

A good question might also be, are you spreading yourself too thin or to thick on a certain language.

share|improve this answer

Yes, developments in computer languages are always advancing. As you advance in your software development experience you will begin to see patterns in languages. Many languages are extensions or mixtures of the best parts of other languages. Many current languages use C based notation.

Sometimes it's best to go back and learn a root language before you try to do understand other languages.

In my experience, the first three programming languages I learned were BASIC, Assembly Language, then C. Once I learned the syntax of the languages and how interpreted verses compiled languages work, it became easier to read, understand and write programs in different programming languages.

In present times, when I want to learn a new language, I try to find a reference point of what I know and what is different in the syntax. Once you know the difference in the syntax, it makes it much easier to read, understand and modify code in other programming languages.

share|improve this answer


You've worded your question "...does it become easier to understand as I understand".


It all depends. It depends on the task. It depends on what you know. You can learn a lot from those ahead of you.


Read every book on the topic, talk to those ahead of you, take computer programming classes (even online) and learn design patterns. Design patterns are vital on so many levels.

share|improve this answer
"Someone" was the Apostle Paul (aka Saul of Tarsis), and the quote is 1 Corinthians 13:11. – Ben Voigt Feb 19 '12 at 16:05

protected by MichaelT Mar 2 '14 at 13:34


Would you like to answer one of these unanswered questions instead?
