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

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
• Can you clarify what kinds of larger projects you mean or what the goal of the self learner is here? In light of Buffy's answer: Are we talking about training for the job market, or about programming for fun/out of interest, or both? – BlackJack Aug 15 '17 at 10:50
• By the way, there's a Topic Challenge going on. – ItamarG3 Aug 15 '17 at 14:51
• @BlackJack -- good point. I edited my question to try and clarify. To answer your specific question: the self-learner could be both training for the job market or learning to code for fun. – Michael0x2a Aug 15 '17 at 15:14
• Just saw your update, we were talking about completely different things. You meant "large project" ("experienced programmer might be able to pull off the same thing in a weekend") I thought you meant large projects as in > 100k sloc ;-). You can ignore my answer, it's not relevant. What you want is definitely possible with good learning material. Unfortunately I don't have any concrete advice(maybe just tell them to read some good books and not tutorials?). – Oleg Aug 15 '17 at 17:32
• This question has been entered into The Being Selfish challenge question contest. – Ben I. Aug 15 '17 at 20:47

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.

• I think there is a middle ground between tutorials and the kind of big projects you describe here and I guess that's the kind of projects the OP talks about. Because in my experience that is already considered too big by self learners right after the tutorial phase. Usually anything with more then three or four toy classes seems to be a challenge, because in most tutorials you learn the syntax to write classes, inheritance and so on, and the theory but the self learner then struggles to apply this even to a small or medium project. Which is already big from their point of view. – BlackJack Aug 15 '17 at 7:28
• For the second bullet point I would recommend implementing a card or board game, or to re-implement some given program. It can be implemented by the self learner alone, and the complete specification/set of rules is already given. – BlackJack Aug 15 '17 at 7:31
• Implementing from a written description is decidedly not the same as working for a client. The point is having another person in the loop who sets the direction, and can even change it. What you describe is still in the simplest part of the space, even if the program is larger than what you normally build. You could use something like that for the first method, however. Find a couple of other people to form a team and build a game that way. – Buffy Aug 15 '17 at 10:11
• I'm not sure bigger project means working for a client in the context of the question. Self learning beginners usually struggle with the first “big“ project(s) after tutorials, where ”big” means big for them, not necessarily for an experienced, professional programmer. It might be a days work or a weekend project for those. – BlackJack Aug 15 '17 at 10:46

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.
• Maybe an 8a: Write code that doesn't need comments. Comments are for explaining why the code does what it does — if that's not obvious from the code itself anyway. So if you feel the need for a comment, think for a moment how the code can be written clearer, so it doesn't need a comment. This comes down to names most of the time, but also to restructuring code and/or data sometimes. – BlackJack Aug 18 '17 at 9:29
• @BlackJack I strongly disagree, it's arguable if striving to write code that doesn't require comments is generally good, it's definitely a terrible advice for a beginner. I don't think that this is something they should be concerned about and it will make there task of moving to bigger projects much more difficult. \@heather This is a very good answer, please leave it as is or change it only based on your personal experiences. – Oleg Aug 19 '17 at 2:09
• @Oleg Why isn't it generally good for beginners to aim to write code that's clear and understandable? Thinking about and finding good names for instance is very important. If you can't come up with good names it is often a sign that the problem or the solution isn't fully understood, or a function mixes different concerns or data structures bundle things that don't actually belong together. Structure in code and data becomes more important the bigger projects get, so I think it is actually very good, for beginners and others, to think about expressing their ideas in understandable code. – BlackJack Aug 20 '17 at 10:17
• @BlackJack Having good names is a good suggestion. However I think that trying to "Uncle Bob" there code will only confuse them and make there task much more difficult. If they manage to come up with a 40 line function that does what they want, adding some comments that explain what each part does and moving on will be better for them. "Clean Code" is meant for more advanced programmers and in my personal opinion many times I saw "Uncle Bob" take a perfectly fine and readable code and make it much less readable. I do admit that it's the minority opinion. – Oleg Aug 20 '17 at 13:03
• "Never, ever, ever feel like using Google/Stack Overflow is cheating. It isn't, or if it is, cheat away." - this is an excellent advice. For some reason, a lot of students feel that they should 'everything' on their own. It takes a huge cultural change to make folks understand that copying blatantly and avoiding reinventing the wheel is not the same thing. – Jay Aug 24 '17 at 3:37

## 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 .

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.

• Most big projects aren't tackling big problems; they're tackling all the little details in a small but realistic problem. Managing this complexity is where people seem to get stuck, because strategies that work on the scale of a textbook exercise stop working. – Jeffrey Bosboom Aug 15 '17 at 0:19

# 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.

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.

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.

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.

## 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.

• This seems a bit chicken-and-egg? In my experience, companies tend to prefer hiring people who have already have a few large, non-trivial projects on their resume/portfolio that demonstrate their potential -- that's why many universities make their students work on projects or capstones as part of their curriculum, and why many people advise job seekers to work on side projects. If the only way to become good at larger projects is by getting a job, but employers prefer hiring entry-level devs who've already completed larger projects, what is a beginner supposed to do? – Michael0x2a Aug 15 '17 at 15:20
• @Michael0x2a You are talking about something else, my position is that in order to actually reach professional level you have to be a professional for some time, university projects are not going to cut it. And yes, it definitely sucks being a beginner, they are supposed to get by, that's what people do. My cousin for example looked nearly 6 month for his first job after graduating. Even then it was for a quarter of the average salary, his next job ~1.5 years later was much better and with the one after that ~3 years after graduation he was able to make standard software developer salary. – Oleg Aug 15 '17 at 15:41
• I'm not sure I agree, but that's probably not a debate worth having atm. To work within the framework of your answer: I'm interested in helping beginners and self-learners who struggle to complete even university-level projects, especially the ones that are expected to take a few weeks to complete. What advice would you give to those beginners? – Michael0x2a Aug 15 '17 at 16:00
• @Michael0x2a What kind of help are we talking about? If you can have them actually work with you(or some other experienced developer) on a project for a long period of time then it's possible. If you are talking about writing a tutorial or some forum/messages to help then imho it's not possible. – Oleg Aug 15 '17 at 16:18
• it seems we fundamentally disagree on the premise, then. Based both on my personal experience and from watching the progress of a variety of other self-learners, I feel it is very much possible for a self-learner to scale up to independently working on large projects without any direct guidance. You can find examples of what I mean by "help" by looking at the other answers that have been posted so far. – Michael0x2a Aug 15 '17 at 16:32