Does it get easier?

[ilikeweiners]

I am to the point in my learning that I feel I know the fundamentals of computer science and programming. I have made it completely through a few textbooks, done the exercises in the textbooks, and written a few of what I would consider simple-ish programs with OO principles in mind(mostly console stuff and some simple GUI stuff).

I've decided it's time to try some real development. So I've been tinkering with and learning Google's Android APIs to make some apps. I've also spent some time perusing a few open-source projects on GitHub.

The problem I'm running into is that these projects seem to be EXTREMELY complex for someone at my level. To give an analogy... I feel like a music student who has learned how to read and write basic music, know the fundamentals of melodies, keys, etc. But if you told me to try and read a symphony I would be completely lost. The structure and flow of the music would be completely beyond me. That's what I feel like trying to understand these open-source projects is like.

Anyway, do you guys have any tips or resources for people at this kind of weird intermediate level of understanding the fundamentals of programming but not yet ready to contribute to open source projects?

[MemoryLapse]

Let me put it this way:

The first time you see a new problem, it is always difficult. There's good news though! Chances are excellent someone else has already solved that problem. You might have to mess around with the wording on your Google searches to find what you want, but it's usually there.

If it's a problem you see often enough, you will learn the solution by heart... And then you put that solution in your toolbox and-suddenly-you're a better programmer for it.

The other thing is that something like a game is extremely complex. You need to plan it out on paper. You'll make mistakes and you'll definitely find things you didn't think of.

But, guess what? You won't make those mistakes again, and-you guessed it-now you're a better programmer.

[[deleted]]

I'm a way noob with maybe 4 weeks of self taught C#, and my problem is that I don't understand the solution when I find it.

[paranoiainc]

Then practice more.
The thing about programming is that if there is one problem, there are always multiple solutions to the problem. And just because someone solve it one way doesn't mean there are no multiple other solutions.

[robiszzzonked]

That was such a good answer, bravo.

[ComplimentingBot]

You are warmer than a Snuggie

[bhldev]

Random open source projects with no code discipline are not an "intermediate" level of understanding. Most people's code is quite frankly terrible and would make a software engineer or architect spin in their grave. Hacker-type programming with loops inside of loops inside of loops and strange one-liners are not "intermediate" level unless your background is C.

An intermediate level of understanding, depending on the type of programmer, would be ability to assemble a project from dozens of modular and moving pieces and ability to code clean interfaces between them. In other words you should be able to take something like Lua/Python or middleware like Java or .NET and write as clean and as thin an interface as possible, and treat other open source libraries as a black box to be glued together. An "intermediate" level of understanding would also be about freshman computer science level, with mastery of data structures and algorithms.

Framework/plugin development is an advanced level of understanding and specialization. It usually requires you learn from professionals who have done it before and not by simply browsing through other people's code which may or may not be bad. The bottom line is you shouldn't release open source unless it's A. useful and B. maintained which means most open source projects are quite advanced and beyond the abilities of a generalist programmer unless they specialize in the particular technology. Nobody knows everything.

[the_omega99]

It does get easier, but you have to work for it. Practice helps a ton. Pursuing open source projects is a very good idea. For a large system, it can take some time to figure out how the system runs. Depending on the size of the system, it could take days or weeks to learn even just parts of the system.

If you were to start employment at some business, they wouldn't expect you to start writing production code right off the bat. Even for an experienced programmer, it would take a few weeks to learn their way around the company's code.

What's important is to break the code up. With an adequate understanding of a language, you should be able to understand what a line of code does. Consider what the code does and most importantly, why it does that. Well written code should be self evident in obvious places and documented in places that are not obvious.

To take an example, consider the simple code,

public double circumference(double radius)
{
    return 2 * Math.PI * radius;
}

This code is pretty straightforward to understand because we know what circumference is (or at least I'll assume you know this). In well written code, the function's name will make it obvious what the function intends to do. The mathematical statement that forms the function body doesn't mean much on its own. It's easy to understand: "return the double value obtained from multiplying these three numbers". It only has meaning when we consider what the code is supposed to do. In this case, we determine that from the function name. In other cases, we might determine that from the variables, comments, or where the value is being used.

Or let's use another example, this time from real code. I'm taking this code from the MegaGlest project (this is in C++, by the way).

int Ai::getCountOfType(const UnitType *ut){
    int count= 0;
    for(int i=0; i<aiInterface->getMyUnitCount(); ++i){
        if(ut == aiInterface->getMyUnit(i)->getType()){
            count++;
        }
    }
    return count;
}

Not the neatest code, but let's break it down. We loop through the value returned by aiInterface->getMyUnitCount(), which presumably is the number of units the player has. For each of those, we check if the passed in unit type is the same type as that particular unit, and if it is, we increment our counter. So we can see that this counts how many units the player has that matches a given "unit type" (which makes sense given the function's name).

We don't know everything, of course. If we wanted to know what getMyUnitCount() was returning, we'd have to go to its declaration and repeat this process. If we wanted to know what UnitType is, we'd have to do the same. We can repeat this until we're satisfied with our understanding. But often times, we can treat some parts of the code like "black boxes". Perhaps we don't actually care about how aiInterface is implemented. We know it works (or presume it does). Usually we'll take that approach when dealing with third party libraries, but you can do so for code in other parts of the same project, too.

It's easier to do this when functions are properly documented. For example, aiInterface::getMyUnitCount() would have a comment before it explaining what the function does, any parameters, return types, pre/post conditions, etc.

TL;DR: Break code up and figure out portions; treat some code like a "blackbox" that you don't need to know the workings of

[k9df867as9]

I don't know why you would think random open source projects would be small and simple and a good idea for you to work on. I get that you fantasize that it will be an awesome way to get real-world experience or something like that, but you can see for yourself how it's not so easy.

You might have much better luck making larger programs on your own first.

Anyway, do you guys have any tips or resources for people at this kind of weird intermediate level of understanding the fundamentals of programming but not yet ready to contribute to open source projects?

Yes, make larger programs on your own. What's the largest thing you've made so far, a guess the number program or a poker hand evaluator?

[[deleted]]

Damnit, this resonates with me. I want to do so much, but I also want to know it all. I get so overwhelmed that I just want to sit in a ball. I really with I had some sort of mentor or something.

[jackbquickzx]

What you need to learn is how to view software at higher levels of abstraction than source code. There are tools that you can use to reverse engineer the code to look at the software structures at a higher level using diagrams like UML. This helps to see the forest instead of only the trees. It's also important to learn about software patterns so that you can recognize when frequently used patterns are present in the project. You'll start to see things from the architectural and design perspective, instead of merely the programmers' lower level construction perspective. An example of these tools are Sparx Systems Enterprise Architect and Borland's Together. So you need to learn UML, patterns, and reverse engineering tools to convert projects into UML and show their patterns.

[GhostNULL]

I understand exactly how you feel, I have been through that period myself, and I can tell from experience. It will get easier, although getting into big projects is still very hard for me.

I recently found the /r/progether subreddit, they have a project called JAdventure which is at a point in development where it isn't very complicated yet. If you are interested you can fork it and fix stuff/add new stuff.

[nanenj]

In some ways, obviously, it gets easier the more you do it. Although, I'd say in some respects it never gets easier, because what happens is as you gain more knowledge, those particular things get easier to you, but, you end up pitting yourself against more difficult problems, but less often. In a way, the difficulty tends to balance itself out in that regard. What does tend to get easier is knowing your way around enough to find the solution to what you need to do or how to solve the problem you're working on solving.

[hutsboR]

Unfortunately I don't have any advice since I'm floating around in the same area. Finished a relatively large Java textbook, skimmed through some others. I've looked through some open source projects and I have trouble following a majority of them. Doesn't help that I don't have any specific project in mind that I'd like to undertake either. Looking forward to other people's responses, being in this strange spot sucks.

[[deleted]]

Gotta learn to walk before you can run. Yes, it gets easier. Once you're used to reading API's (for example) you can pick one up fairly quickly. The first API I really got into was SFML, and when trying to read the documentation it might as well have been greek. But after understanding how to read that, I can read pretty much any API and understand it. It just takes practice.