Strategies for self-learners to transition into working on larger projects

Question

A common problem I've noticed many beginners (especially self-taught ones) run into is figuring out how to transition from working through tutorials and exercises to working on full-fledged projects. There seems to be almost a "cliff" of sorts that many find challenging to scale for a variety of reasons (that are probably not worth enumerating here?).

One way to make it over this "cliff" is to find a teacher that can help guide you through progressively more challenging projects. Of course, this isn't a path available to self-learners by definition.

The next best alternative is probably to find a tutorial or online course that does something similar. Unfortunately, these resources either appear to be hard to find or simply inadequate (?), based on my (anecdotal) experiences answering beginner questions on another forum.

Taking all this into mind: What concrete advice would you give to self-learners who are struggling to transition to working on larger projects?

Edit: To answer @BlackJack's question: by "larger project", I mean a project that:

1. Does not immediately follow from a tutorial or exercise: finishing the project requires a fair degree of independent work.
2. Is "large" and "challenging" relative to the expectations and abilities of a beginner -- for example, it might take a beginner a few weeks to complete a "large project", but an experienced programmer might be able to pull off the same thing in a weekend.
3. Is not a "single-file project": there are lots of things you need to do and lots of details to keep track of.
4. At the very end of the scale, a "large project" might be the sort of thing an intern or an entry-level junior developer is asked to do. (Most beginners will probably likely need to complete multiple easier projects first before they're at this level, though.)

Some examples of large projects for beginners:

1. Implementing an interpreter or compiler for a programming language
2. Writing a video game (either a feature-rich prototype of a novel game, or a polished clone of some existing game)
3. Writing a webapp or mobile app with a non-trivial frontend or backend (for example, implementing their own basic search engine)
4. Rigging together some relatively complex automation using a few Arduinos/Raspberry Pis

Answer 1

You have set a difficult task. The reason is that there are two dimensions here, not one. The first is that larger projects are usually built by teams and not by individuals. Certainly if you are interested in preparing for employment, then teamwork is essential. The second dimension, independent of the first is that larger projects are normally built to the vision and specification of someone other than its builders.

This leaves four cells in a grid. You probably already have experience building alone and to your own vision. This is the easy case. The hardest is building in a team to someone else's specification. You can get there immediately but it is very difficult to transition that way. Instead you can first move through one of the other cells.

• You can find a team to work with you on some project of your own vision. You can, perhaps, find a description of such a project online or in a course description. You can also just try to replicate some software that you normally use that seems big to you. Build a spreadsheet program, for example. The hard part, however, is to find the team to work with. Note that the project need not be terribly large, but you will learn important large-project skills in any case.

• An alternate way is to move into the other cell. Build something yourself, but with another person specifying the program. This will be a lot harder than what you usually do, but is an essential step. One way to find the problem is to find the client. It could be a teacher with a need. It could be a local social service with a need. It could be anyone with a need. But you need to give complete control over what is to be built over to the client, while you are creative only on the how to do it. Again, the size of the project is less important than that you are learning how to work with a client.

Once you have some experience in one of the above, you will be ready to move to the externally specified-team built cell. But the experience in the simpler case may give you some insight into how to find the team and the client. Scaling at this point will be more reasonable than you think.

Good Luck.

---

I should not that even in formal education, when a project is specified by a professor, it isn't quite the same as working for a client. The typical university project normally grants the student a large part of the design space. A true client will not. Normally the professor won't ask you to change direction in the middle of a project. A client might. A professor might grade you. A client might just reject your work or ask you to do it over. A university project is normally thought out completely in advance by the professor. A client may make it up as you go along.

Answer 2

Having experienced this cliff myself, I'd give several pointers:

1. Start by independently solving smaller problems. The Euler problems are great for this.
2. Set specific goals for what the program must do. Then you know what needs to be done, exactly. Much like requirements in the "real world".
3. Break the overall project into chunks, considering the requirements. I.e., if the project is a video game that requires a GUI, chunk one might be figuring out how the heck to create a GUI.
4. Choose a project appropriate for your experience level, but also don't be afraid to plunge in. There's a balance here.
5. Never, ever, ever feel like using Google/Stack Overflow is cheating. It isn't, or if it is, cheat away.
6. Have a cheerleader! For me, I can sometimes talk about what I'm doing to my mom, and she'll be like, "Yeah, that sounds great!" And occasionally, this bonuses as "I'm working on this problem - see, ::explanation:: oh duh, that's what's wrong!" ::races back to computer:: That has happened to me quite a few times.
7. Work at it consistently, but try not to get burned out. Staying up really late is a no. Working on it for several hours at a normal human time is a yes.
8. Comment your gosh-darned code!!!! I learned this the really hard way, many times.
9. Learn to use Github.
10. Last one I can think of right now - set up your programming space in a comfortable way, then you'll actually enjoy working on it. Right now, I have a nice setup where I can plug a bigger keyboard and mouse into my chromebook, and we also had a monitor in the house that commandeered, and I set up the chromebook so it dual-boots Linux awhile ago. I installed all the various packages I use (numpy, scipy, etc) and programs (IDLE, git, etc). Basically, make it so when you start coding, you can actually just code.

Answer 3

Step 1: Think big

The most important part is not to think "this is too big". All big projects are, well, big. You need to find something you'd like to do. Sometimes just looking around, and thinking: "I'll make a system that imitates <insert real life thing here>" works great.

Just make sure not to think too big. You'll know if it is too big in the next step (making it an iterative process until it succeeds):

Step 2: Break it into pieces

Now that you have what you want to do: Search google to get an idea of where to start.

Better yet: think for yourself what such a project might incorporate and thus break it into pieces. Each piece is like small projects which you are used to from tutorials.

Once you have an idea of what are the separate parts of the larger picture, start working on them. Some might be disconnected parts (different pages if it's web related, for example), and so you can work on them separately, and when you get tired and\or stuck with some section, just switch to another one until this "writing block" (;)) is over.

Step 3: Profit?

Now that you have a work plan, remember to stick to your original project. I know that for myself, I ten to run away with myself when it comes to projects: I add things I didn't intend to at first, and make drastic changes. It eventually is not the project I thought of in step 1. This isn't very productive work if step 1 is done correctly .

Answer 4

Bigger isn't better.

My guess is that it's more accurate to say that novices have trouble working on projects that are useful and interesting in real life, which is not necessarily the same thing as larger projects.

In fact, a common trap that I've seen self-learners fall into is taking on projects that are too large! This leads to burnout, stagnation, and a bunch of unfinished projects.

As a specific example, I see a lot of novice game developers get stuck thinking they need to develop a game engine. They'll spend months (or years!) working on the engine, without ever developing any games. What they should be doing is working incrementally on smaller projects. Start with Pong, not with a game engine.

So, at the risk of mu-ing your question, my answer is: don't work on larger projects. Work on a small project, and get it "shipped" before starting the rest. Put a link to it on your online portfolio. If you don't have one, then your first small project can be building your online portfolio page! Put a bow on that code, and then start over on the next small project.

As you learn, you'll find that code you look back on looks pretty terrible. "Oh man, I was an idiot 6 months ago!" This is a completely normal feeling, and it's a sign of how much you're growing. But it also means that you don't want to spend a ton of time (more than a few weeks) building up a codebase, because you'll either have to rewrite it a bunch of times as you improve, or you'll be stuck building on crappy code. IMHO, it's much better to give yourself a blank slate pretty frequently.

That being said, the other half of this is finding projects that will be useful and interesting in real life instead of all of the disconnected snippets you're used to writing from tutorials. This isn't an exact science, but I think the best thing you can do is incorporate your non-coding interests in your programming projects. Here are some examples:

• Have a dog? Build a website that shows pictures of your dog! Make it the best dog picture website in the world.
• Care about a social cause? Create a data visualization that highlights some issue that's important to you.
• Enjoy art? Create some digital art. Bonus points for getting it displayed in a local gallery.

The key is finding something that you're interested in outside of programming, thinking about how programming intersects with that, and then coming up with a small project that you can complete and ship, even if "shipping" is just sharing a link to it on Twitter and your online portfolio.

Then move on to the next thing.

Repeat the process and come up with a new project. Start over, but bring any lessons you learned from your first project. Over time, your projects will naturally get more complicated, but you should always make sure you're working on something that you can see through from start to finish. Don't stagnate on the same project for months at a time. Get something out the door, and move on.

Answer 5

1. Perseverance and determination

This was, without a doubt, the key to my success as a self-learner. You need to see obstacles as a challenge, not as a threat. With each project, prove that you can achieve something beyond what you've achieved before.

Almost any project is doable if you are flexible about the details. (For example, going 2D instead of 3D.) So instead of thinking "I can't", think "How can I?".

Having confidence in yourself is important. You can't plan how you will approach a problem if you don't have confidence in your ability to complete tasks.

Perseverance and determination should come before other considerations like wanting to "do it the right way" and being "neat and tidy". Those things are important but not nearly as important as setting yourself a large challenge and succeeding.

2. Use what you know (and be ready to learn more)

Choose projects that build on your existing skills. It's enough of a "cliff" to transition from following tutorials into doing your own project. For example, if you have followed a tutorial on sprite graphics, make a game involving sprite graphics.

When you are trying to solve a problem, use tools you already know how to use, if you can. Even if this is not a great way to do it, it makes it much more accessible, and once you're done, other approaches will make much more sense to you.

That said, be ready to learn something new if you need to. Be curious.

3. Ask yourself questions

This is particularly important when you get stuck, or are trying to create a plan or structure for your project.

For example, if you want to make a game and have no idea where to begin, ask yourself basic questions like "What language will I use?", "How will the player interact with the game?", "What parts do I feel confident/unconfident about?"

If you can't answer these questions, ask yourself what you could do to find some answers. If you can answer the questions, think about the answers and try to ask yourself further questions. For instance, if the player interacts with the game using the mouse, you can ask what features your programming language has to be told what the mouse is doing.

It helps to write your questions and answers down. Forcing yourself to put vague ideas into actual words helps clarify your thinking about them.

Answer 6

I went through this a few years ago, having self-learned everything I know and teach. I had to do it because, there isn't much money in training alone, so had to get into development as well.

1. First up, I started my talking to some of the folks who are already working on large projects. I am talking folks who are in the industry for a few years. These experienced gave me knowledge about the kind of tools they use, programming languages they use and stuff like that.
2. After that, I decided to build a 'project atmosphere' right at home. For instance, I was advised about using servers and databases extensively for every project. So, I used Azure to create my own IT department, and then consume all those IT resources in my applications.
3. Another individual suggested that I become 'full stack' developer, so I learnt all the languages/components of dot net that are required to go from a project concept to delivery.
4. then, I decided to fill the gaps in my own learning. For instance, I had realised that without even knowing, I had become extremely good at the basics of programming but throw an advance component, I would falter. So, I grabbed all the industry authored books (the ones aimed at working folks rather than students) and pretty much went through them, essentially relearning things.
5. Finally, for practice of getting that 'team' feel, I had some of my students to act as my project members by create real but practice software projects. I would take upon on the role of the project manager or team lead, distribute the work load, conduct presentations, coordinate code over repositories and then deploy the whole thing myself.

Then, rinse and repeat the above so many times.

It took me a while (a year or so) but eventually, I was ready to work in the industry. Now, years later, I switch between working as a developer and trainer, no problem. Since we are talking about transitions, I have found that while I still make a decent amount of money from training, development actually pays more.

Answer 7

update

I completely misunderstood the question this answer is relevant only in the context of large complex projects, I'm not going to delete it but you can ignore it (if you are a moderator feel free to delete it).

---

The only good advice you can give is that they have to work as programmers for at least a year.

It doesn't matter if they are self taught or have a CS degree, this is not about knowledge and this is not something you can learn from a teacher. What they lack is technical proficiency, the only effective way to get it is to actually work 9 hours every day with more experienced people and learn from them on the job.

You can of course reinvent the wheel and learn everything yourself, after all at some point in time there were no experienced programmers but it will take 10 times as much time and effort.