What you need at this point are a series of assignments which are self-contained problems with known solutions. The assignment 'create a web server that displays "Hello World"' is an example of one.

Here are some more:

Create a web site that allows a person to identify what would be an 'affordable' mortgage. (or flip it, shows them how much they need to save each month in order to retire). These are both applications of the compound interest / annuity calculation, but built in such a way that you can pick different parameters to see the results. Pick an interest rate, or pick a home value or retirement amount.

The goal of that assignment is to have you create a web site which has a built in formula (logic) which can be manipulated by user entered data.

Next assignment, build a web site that collects data about a particular commodity that changes day to day (could be a stock price, could be oil, unemployment, could be Eve online credits, what ever), then plots that data on a graph. Allow the user to annotate the graph by date with specific events. You will find the d3 library helpful here. Once annotated allow the annotated graph to be shared by URI.

The goal of that assignment is to get you to store data over time, use third party APIs, and provide a way of getting to a particular state based on arguments in a URI.

Now for third assignment, create a market site for three commodities, we'll call them 'stone', 'wood', and 'sheep'. Have a system random number generator periodically generate one or more units of one or more commodities. Simultaneously create a Sudoko board such that the first player to solve the puzzle gets the commodities. In the Market people can buy and sell commodities, the market creates a currency for recording those transactions. Players with a specific quantity of individual commodities can produce a 'product' and that product adds to their 'production' score. Rank all players by the quantity of currency in their account and their production score.

The goal of that assignment is to create a fun market simulation game that echoes some of Settlers of Catan and gives you something fun to put into a Show HN posting.

Bottom line, practice problems. Then when you, or someone you know says, I'm trying to do this ... you can tell them you can do it or not.

I particularly like the idea of the sudoku part as a way to get raw materials. Get some crypto there and here and gateways with the "real" economy, and... you know what I mean ;)

The risk of creating a bunch of toy programs on your local disk that you never show to anyone is that you avoid the hard parts. Accountability is a good thing, in programming and in homework.

Also one would learn to tweak a server to the application.

(The problem is that your mind, your approach, needs to change, and that change comes with practice and time. And practice always starts with the simple, the controlled, the repeatable, not the full fury of all skills brought together in a high pressure win-or-lose moment.)

Computers are nothing more than repetition machines. Start by writing code to do things that you yourself now do multiple times per unit time.

Start small. Simple things. Let the computer handle the repetition for you, no matter how simplistic and rude and hacky your solution.

Then notice how program A and program B, written to repeat different procedures, have similar processes or structures.

Generalize A and B to make a C that does both.

Do this again for other processes. Over time, your approach will shift. You will notice patterns: Patterns of process, patterns of structure, patterns of relation.

Then you will start solving problems. Only afterwards will you realize you have done so.

(I started coding shell scripts for anything I had to do more than twice - or anything that required "too many characters". I got tired of typing "ls -alt *|head" so I wrote nwst to do it for me. Then I added a numeric option to nwst to control how much head wrote. I got tired of writing "find . -iname" so I wrote fndi. Etc. Etc.)

We have to master the skills before we get rewarded for them.

That said, you're absolutely right in saying that I want to "solve problems" (that's just the best term I could come up with after months of trying to convey my meaning to many people--I have no attachment to it) for the intellectual satisfaction and joy of doing so. I really just love what I have done with writing code. It's really fulfilling and the structure of it resonates with me at a deep level.

So, your comment is very helpful. There's no end to the small problems or ideas that I have, especially within my work writing code. You may have answered this and I didn't understand, but the main thing I'm getting at with my OP is that I don't have the skill set to actually solve the problems. I know it probably sounds completely ridiculous, but I've approached many small problems and have always produced the absolute barest skeleton of the program which solves the problem I have. I then draw a blank on what I need to do next to continue solving the problem--the structure and the logic don't exist in my brain yet. That's what I really want to get from this thread, and I think there are some excellent responses that help with that, including yours.

If you are at all inclined to system administration, your approach (notice problem, solve problem quickly and effectively, move on to next problem) can translate to solid work.

Now I speculate: As an employee, this will probably lead to low to medium pay positions - at least until you start seeing and solving larger scale problems. As a consultant, however, if you can get a stable of repeat clients, preferably under retainer, you may actually do quite well.

Back to reality. How to make progress? Find an OSS project or two that you quite like, preferably ones with really good communities. Go through the lists of current bugs. Find and fix those you can.

Heck, just start finding flaws in people's code and documentation on GitHub, fix, and issue pull requests.

You will get a reputation in the community as a reliable, dependable problem solver. After a while, reach out to people who seem both approachable and a step or two above you. Ask if you might be able to help them with a larger problem, one which they need assistance with and on which they would be willing to mentor you.

That's one approach, at least.

Your academic environment may also have code that needs maintaining, patching, repairing, refactoring. Food for thought.

Keep at it, the penny will drop, things will click into place.

> A list of practical projects that anyone can solve in any programming language. These projects are divided in multiple categories, and each category has its own folder.

Feel free to also look at other people's solutions (many in JS): https://github.com/thekarangoel/Projects-Solutions

Another example is "I want to create a service that auto-corrects text that users enter."

Try to find something that would make your own life easier. Chances are that other people are having the same problem.

Shameless plug. Hopefully you get some ideas out of it: http://jairampatel.com/projects.html

I had (have?) the same issue. Maybe it's something that experienced programmers take for granted; there is a huge disconnect between writing code and developing software.

I've asked the same question, and received the same answer: get your hands dirty. I agree with the premise, and am working on it. But there's the disconnect. I can write a little Python, but have you ever tried to set up a Python development environment on your computer? I don't understand 95% of what is required.

All that said, I'm way ahead of where I was when I started, a year or so ago. I'll keep plugging away, and recommend doing the same. Hopefully we see a few good replies here to help us out.

Example: If you want to learn to play baseball. You learn the mechanics of the game. You learn to hit, catch, and throw. You can be an expert baseball player, and you can practice the shit out of mechanics all day long, and play games, and win games all day long for decades.

But if you want to manage a club and win games, you need to take that next step to learning the mechanics of the game beyond playing baseball, or all you will ever be is a player, and you will never be able to actually build a team that wins games.

Telling someone to go practice hitting, throwing, and catching in order to perfect their ability to orchestrate and manage an entire team of different moving parts would sound crazy.

And that is how it sounds when people continually say "just go write, fix, and build."

I do not have an answer for this problem. But, the answers that always rear their heads when this question comes around, have the opposite ideals of how anyone that has taken the time to learn the mechanics of development. Those people that have taken the time and effort to learn the mechanics are mostly those that appreciate clear and concise paths to solutions. And, as far as I know there is not good resource for bridging that big gap between mechanics and craft. I could be wrong, and there could be a wealth of this information on this process stashed away somewhere. But, the problem is that most of these paths are most likely buried somewhere in a course or resource that is shrouded in mechanics, when the learner is just looking for craft.

The person that clearly outlines this path from Mechanic to Craftsmen will undoubtedly be very successful.

I think there might be an implied aspect of this that we're not getting. Someone said to (paraphrasing here) "Google every problem you come up against; 'how do I do x with y, how does a work, how do I implement b, etc.'" That seems like it would work--if you Google every problem you have, or look at the docs for every function you use, a pattern will start building in your head that shows you how to do x with y. I think the key here is looking at the core source of the tools you're using and connecting the dots in your head.

You are told to do the basics over & over again so you:

a) Learn the motions

b) Learn how they work

You can't successfully apply your knowledge/tools/skills without knowing what makes them tick.

Let me phrase that with an example from my past. I was big into Starcraft at one point in my life.

Started with SC:BW. I was terrible back then, doing builds like an automaton following a recipe - I lost as soon as someone stepped out of the cannon and did something non-standard. Why? Easy. I had the mechanics but was missing the know-how on what made them work and how to apply them.

Instead of going that route I started to watch better players. They quickly diverged from the builds - enlightenment came when I noticed that they were playing reactionary. They observed their opponents and made decisions.

Why am I expanding now? Not because the build says so but because my opponent invested in tech so will not have the resources to pressure my new base etc. The basics are important, if you have your mechanics down then your mind is clear to react and just execute the movements to achieve the goal you want based on what you observed.

It works the same with programming. If you're stumbling with language syntax, your framework - the basics. You will then loose a lot of time hunting small issues and constantly loosing the big picture. When you're basics are down you are free to experiment and will notice patterns that beg you to apply one of the basics you learned.

Some problems are specific, fall into the 'what data structure, algorithm' should I use. Some are structure/flow related - how do I make those two things connect to each other and pass data around. Some are new - but they all mingle and repeat themselves very often.

When you read a lot of code, write a lot of code - you will start noticing the patterns. In the worst case scenario - knowing the basics will make it easier for you to ask better questions/find answers to hard problems faster.

There are hundreds of tutorials on how to write JavaScript, use the for loop, use if else statements, and so on. But not very many that I have found actually show how to use those to build a real program, explaining the steps and thought process behind the program along the way.

There are definitely ones that show you how to do things with it, but there's often not an explanation of _why_ something works the way it does.

I made my first video game when I was 13 years old. I made it because I wanted to make something for a girl I liked. I used Macromedia Flash, learned as I went along, and never lost site of the goal. I had to impress this girl.

Sometimes we are inspired by technology to do things. The reason an engineer might give to building something bizarre: "I'm building this because I can." I think it's better to have the goal in mind first, though of course we may only think of solutions to problems because we also understand the tools we have available to us.

It's easy to solve a problem with programming once you know what problem you want to solve. I don't think anything great is made when you try to come up with a product based purely on technology. It's great that you learned JavaScript, I happen to think programming is a blast! And learning new tools, languages, frameworks, or paradigms are always great for the left side of my brain. But programming has always been the most fun, most rewarding, and easiest when I'm deep into solving a problem. The "how" is straightforward: you Google the error message, you Google the 'how to perform X function with Y language on Z platform', you ask friends and family to test and break your likely fragile baby, you build a business, et cetera.

Try to solve an issue you have. Try to solve someone else's issue. Try to solve an issue many people have. Or, browse GitHub.com, and work on another person's solution.

Did the girl I made that game for ever go out with me? No. But it didn't matter.

I got started.

The fact you are asking this question is a great sign. This is a key skill that is overlooked in technical hiring and by many development blogs trying to qualify what makes a "good" programmer. Problem abstraction is a huge part of software development. I work in enterprise development around a very specific niche of oil and gas. (ETRM) the "programming" I do amounts to little more than reading and writing to a database. The tricky part is modeling a business process and breaking it down into manageable units of work. For what I (and probably most developers) do, language is just syntax to know and interchangeable.

In my experience, programming is a series of learning curves and plateaus. A lot of what I know just comes from experience. The best way to learn is to program. You will eventually see patterns in the types of problems you see and know the general approach to solving it even if you don't have the exact answer.

I started programming around 20 years ago - self taught and experiencing the same problems as you in the early beginnings.

I made mistakes when I started

- jumping around between languages

- thinking I couldn't grasp something

- jumping from one tutorial to another, and another, and another

- I wish I started learning algorithms & data structures earlier

- I wish I took time to dive deep instead of rushing to getting something working

What was my breakthrough?

I got a job in social assistance - it was mostly sitting at a desk and distributing food supplies. This left me with most of the day unfilled with errands and a PC in front of me. I installed Perl on it and started learning, digging deep into every bit of the language.

- Learning how the interpreter works

- Reading the perldoc for every module I used, every function I called

- Writing small scripts to help with my then daily tasks

- Writing code every day, even for stupid one off tasks or things I wanted to try

Three months later I got my first job as a Perl programmer - mostly doing web interfaces, marketing mailers & web scrapers. Having learned Perl to the level when the language itself wasn't getting in my way it was far easier to grasp additional concepts:

- programming paradigms

- algorithms & data structures

- abstraction

- documentation & good practices (version control, testing etc.)

This was a major stepping stone for me. Picking up any other programming language, framework was a breeze since then. I worked at a corporation doing Oracle PL/SQL for seven years. I programmed in Ada, Ruby, Perl, Python & JavaScript professionally in long term employment. I did contract work for C, C++, Java. I played with Common Lisp, Scheme, Prolog, Erlang & Smalltalk (mostly when I was hospitalized for a long period of time) and now I'm working with a start-up I co-founded where I'm doing Python, Ruby, Javascript, C, Go and recently some Dart.

Don't let anyone tell you that you're limited in any way - most of all don't think it yourself. The only limitation is what you want to achieve.

Recently I got really interested in OpenBSD and would really want to be involved in OpenBSD development.

Here's how I'm tackling this specific problem now with hindsights to the mistakes I made when starting as a programmer.

1) Pick one project

This is OpenBSD in my case - should be a heavily developed framework, library, application in your case.

I ignore all the OpenBSD vs X articles, post whatever. I made my choice.

2) Follow it

Subscribe to the mailing lists, join the IRC channel - consume news & changes about the project.

Don't feel bad when you can't keep up! 20 emails per day? Try to read a few of them and leave the rest for later - just keep at it.

3) Follow the code

Take a look at each code change made to the project, try to understand it even if it's over your head.

4) Run it!

Changes were made? Pull them in, run them.

5) Poke around

Try introducing your own changes. Hit a bug? Try to trace it down as much as you can & fix it. If you can't fix it, report it upstream.

6) Make your own

You want it to do more? Add it, or at least give it a good try.

Don't know how? Still try! Even if you just end up breaking stuff you will learn!

7) Rinse & repeat

Until you feel confident enough to go in on your own - though you rarely are completely on your own. Don't be afraid to ask for guidance & help. Just remember that it's always nicer to show people that you tried on your own (and documenting that) before going public with a help request.

So this was a wall of text, hope it helps you at least a little bit :)

I mostly work from home on my own schedule so can devote a few hours spread out throughout the day. If you really want to learn and need a helping hand in the early steps or someone to bump ideas against feel free to catch me on freenode @ #hncode.

They all do the same fucking thing. So with that I feel on one level I like being exposed to different languages on my personal time (Perl programmer/Sys Admin professionally) and I thought that this was really helping my programming skills in general. But now I'm wondering if I've caused more trouble than good. I know I have to pick a technology and literally stick with it. I have to see what I'm most passionate about. I am thankful for everything I have observed but its time to publish some apps. I feel like I do a lot of studying and have nothing to show for it. Rails, ASP.NET MVC, Spring MVC, and Grails all do the same thing. It just depends on what eco system and what language you're most comfortable with and of course your work environment. All of this for me is personal exploration. At work we have a LAMP environment and our web apps are written in PHP. I'm just there to build my resume. I can't stand PHP and am not passionate about the technology we work with. So yeah. Lost in a sea of code.

I'm a college student, and I haven't had a single programming course. I'm interested in full-stack, including front-end design and dev. I've learned my shit with that, and can hold my own with it pretty well. However, I do have plenty of free time to do what I want with programming, and I've taken on a massive load.

Every day I'm hopping between frameworks. I did half of the Ember.js course at CodeSchool, realized I didn't like how the project was being handled and decided to try React. That's just the latest, though--I've been trying to learn Node, Express, Gulp, Slush, and a bunch of others. I've got about 10 projects with just a bit of work done on them, and no more because I got stuck, didn't know what to do, and moved on. I see now that I really need to pick my tool and learn it.

Right now, that's going to be Node + Express for me. I don't think I have the gusto or interest to get into the nitty-gritty of Node core dev, but I could definitely do that with Express. Thank you for the excellent guide on how to really focus with it. I'll definitely be doing that immediately.

Thanks for your help, and I'll definitely sign on to Freenode to chat and get some help/ideas some time.

As opposed to the conventional wisdom, which wants us to Never Settle by keeping on jumping between things, reading broadly and pretending you are a coding god after reading all the X vs Y articles, never building up enough expertise in any one thing, while holding out for that one gig that will hit the spot.

And Just Getting It To Work as is commonly understood really translates to Do a Shoddy Job So It Looks Good On The Surface, Fuck Understanding Or Actually Getting It To Really Work.

You can also try daily programmer subreddit http://www.reddit.com/r/dailyprogrammer

If you want to practice with Bioinformatics problems: http://rosalind.info/problems/list-view/

You've learnt the language and the syntax, but it's the experience of just doing something that counts is where it's at! Good luck :)

What does it mean to "solve a problem"? Furthermore, how can computers be used as a solution? Let me illustrate this with a precautionary tale. It doesn't involve software design, but the principles are the same.

An old company I worked at had a crippling problem. Development groups were not communicating with each other. Each team would work on a module, only to find there were separate interfaces. Months of man-hours were wasted, time and time again. An up and coming intern convinced the management he could solve the problem by implementing a forum. Resources were allocated, and he spent the next few weeks setting up phpBB. Hopefully you can see where this is going.

The tedium of checking forum threads soon wore on the jaded developers. Nobody wanted to root through non-threaded, disorganized responses, or update the attached Wiki. Soon, the server turned into a forgotten wasteland.

Computing problems are solved with computers. Human problems are solved by good leaders. Sometimes, computers can help. Although the forum didn't work, a new developer was hired as I was switching jobs, and was doing a marvelous job uniting the development team. Before I left, a Jabber server was setup in place of the forum. The reception was much better--but the real problem solver was a good leader. Not the computer.

No offence: Programming is not worth a dime if you don't have a problem to solve yourself. And either you are the kind of lemming who sits and waits that someone presents you a problem you should solve for him or her or you are as creative to create your own problems as creating problems is a very creative process.

For example take a website. Let's suppose you are using a popular blog system. Then... what? Well you see a spectacular gallery on a site X. You want to have that on your site too. Then sit down, take notes and think over what you need. All you write down is more or less your algorithm (logic). You could do it with database support or without, you could use a JS lightbox or you could do your own. I remember doing my first coding. The example in the book was a basic text editor. So what did I do? I expanded the thing, so I added feature after feature I found very useful. :)

Another example with your blog and an API? Let's say you would like to visualise your data. Get the proper js library and try to connect it with your data. How could you do it? You could use csv files with a cloud space like Dropbox or Google Drive.

At least the problem is what you think of it. There are a lot of problems or none. Noone could tell you what "your" problems should be.

If you get past JS you could use Rails, Python, PHP and code your very own content management system (recurring to Codecademy and CodeSchool's content). Or you could write an app, which aggregates all the news channels you like by storing all rss feed entries, all tweets all Facebook postings by the channels you chose.

Coding is not the hard part, it is rather a means to an end. Figuring out for whom you are solving that particular problem and how your product will actually solve that problem is the hard part.

For every problem that there is to be solved, there are 1,000 ways to execute the product that is supposed to solve that problem. However, only 4 or 5 out of these 1,000 ways actually do solve the problem that the product is intented to solve.

So, now you need to

1. Find a problem that is worth solving and that interests you

2. Find out if this is actually a problem. The more people have the problem, the better

3. Figure out how to build a product that is built in such a way that is solves that problem that you are intending to solve

All in all, as you are just starting out, you should probably start writing little scripts that solve your own problem. However, your questions is basically how do I build products that people want to use or how do I start a startup. I would recommend you to start with this essay. http://www.paulgraham.com/start.html.

Programming, like anything, is a tool - you learn the features which might not sound like solutions to problems, and with practice you start crossing your programming mind with normal day to day mind. Let me give you an example.

I got the mega Creative Market Black Friday Photos bundle yesterday. To my surprise, the photos are all separate, so instead of one zip file for me to download, or a "Download All" button, it gave me a list of 100 or so buttons to click to download INDIVIDUALLY. Conveniently (or not), they added a "Save to Dropbox" button to each item, but that doesn't help at all, there's still no "Save all to Dropbox" button.

So after clicking on 5 or 6 items... I started to give up, then suddenly my programming mind jumped in and said to me "hey dude why don't just go into the console and select all the elements and do a `trigger('click')`?" So I jumped into the console, and typed

`$(".start-sync").trigger("click")`

I didn't even bother to check if the site uses jQuery, I just typed it in and it worked!

Now, if you were to jump in and helped them add a "Sync All to Dropbox" button, don't you think that's gonna be really beneficial to a lot of the users?

You might have learned the feature in jQuery to trigger an action, but to actually do something with it to solve a problem you need to not only learn the tools, but also start thinking about problems using your programmer brain.

  1) Go to Github
  2) Browse the Javascript projects
  3)  Look for projects which are active with many follows/forks
  4) Click on the Issues tab
  5) See what open issues there are
  6) See if the maintainer is active and applies pull requests
  7) Pick an issue you can fix, fix it, write a patch
  8) Send a pull request
  9) See if the maintainer has any comments 
  10) Go back to step 1

I know exactly a problem you can solve right now with Javascript.

   * Go to this website - http://maps.huge.info/zip.htm 
   * Move around the map so you can see where various San Francisco zip codes are.
   * Now try to do this on your phone

There is absolutely no point in starting your own projects from scratch when you've never seen other projects.

Fixing random bugs in open source software is great for two reasons:

1) you'll need to read large amounts of code to find bugs, learning things about coding style, design patterns, architecture along the way

2) What you do actually has a purpose. There's nothing more boring than programming for the sake of "practice"

I’m not arguing that you have to know frameworks to build real projects. However, I believe knowledge of a framework reduces the effort required to complete a working solution so dramatically that it changes the game, especially if you’re new to programming.

I’m not a pro by any means, but my practical advice would be: don’t stop at having learned JavaScript (the language) and Node.js (the platform). Learn Meteor.js[1], build all the examples you can find in the official docs, and after you become familiar with the process—the ideas will flow.

[0] It was a surprise to me, but in retrospect it should’ve been obvious as I myself have quite literally learned Django before Python.

[1] Meteor is just an example that came to my mind, I’m not affiliated with them and it’s possible that there are better choices in the land of Node.js-based web frameworks.

In general, what you need is activation energy - that initial bump to get the project or idea started. After that, you need to practice maintaining the motivation to complete the project you started.

Asking the HN community was an excellent way to start. Good luck!

Start with an idea, a problem. It really helps when the problem is personal. What do you hate? What annoys you? The text editor you use? Some little feature of JS that the makers of the language seemed to have forgotten about (how could they!)? Some website that just looks wrong to you? The todo list that doesn't work the way you want? Just think of something that doesn't quite work the way you want, a void, and then try to fill it. Just start and get in over your head. Do some spying on how others solved it (preferably only if you really get stuck, or once you made substantial progress). Maybe you can solve it better? Gotta dog food it. I find dogfooding a solution to a personal annoyance is what keeps you progressing towards a finish line.

If your asking about, say, the idea of website design, and the typical systems that make up sites (the software stack), just start reading about website design. Make a dumb website. Make a blog. Make a family photo album. Basically, start, and then figure out what you don't know, and then figure out what you need to know to proceed. It is an iterative learning process of realizing all the things you do not know and calmly tackling them. For some, this is the best part, the adding of another tool to the toolkit, the unearthing of some common pattern among the tools.

A lot of other people in this thread provided some good advice to finding problems to solve, but I'd just like to comment a bit on how to solve them.

My advice: read code. Lots of it. Find popular libraries in your language of code and pick them a part to see how they work. Set up some open source project that solves a real problem (a CMS, chat bot, whatever) and explore how it operates.

Seeing how other people solve problems will give you a good frame of reference on how to tackle other challenges you encounter. You will also occasionally come across sub-optimal solutions: learn from those as well. Seeing how to do something badly can be just as valuable as seeing something done well!

At the end of the day I think programming is a lot like writing: a good writer reads a lot of books and writes often.

Just keep at it, there's a whole community of people here who've gone through this exact same thing. Good luck!

Since you know JavaScript, go build a mobile app with Phonegap. You'll get a really great rush when you see your first app pop up on an iPhone or an Android phone. You'll naturally want to iterate and improve, and that process will make you learn.

I assumed that smart people who code would be able to solve the problem of teaching eager minds how to make stuff with code. I was wrong!

I can tell you what I did many years ago. When I learned my first programming language, I decided to create my own CMS. I was still in high school, around 15-16 years old so it was just a fun project for me.

Imagine a simple version of a Wordpress. An admin area where you can add new posts and tag them. And an index page where the posts are displayed in a descending order with a pagination.

This will teach you basic ideas about how to store data in a database, how to work with forms etc, how to retrieve the data from the database and display them in a structured way (templates).

Ok, let's make it little bit more challenging. users can click on individual posts and add comments. Once I got my hands dirty and created something simple, I started adding more functionality to satisfy my newly acquired thirst for knowledge.

Each new problem I solved, no matter how trivial, motivated me to go t a next level and learn more.

Let's say users have to register in order to post comments. This will learn you how to create a basic authentication system, how sessions and cookies work, how to safely store passwords in the database, maybe add your own custom catcha element on top of it.

Next, I moved on to a new feature. I wanted to be able to upload pictures from the admin area and be able to insert them inside posts. Images should also be resized into multiple sizes (thumbnail, full size etc).

You can see that what started as a very simple project can actually grow more and more complex and you can learn a lot.

After I finished my CMS, I went on to a new project, I wanted to created my own text editor and a simple image editor (imagine MS Paint). Did both of those and again learned a lot.

After that, I went even deeper and created a fairly complex social network from scratch. Although this was the first piece of code in my life I got actually paid for so it probably doesn't count.

What I am trying to say is that you should go and get your hands dirty. It might seem like reinventing the wheel (because it is reinventing the wheel) but it is perfect for learning how to actually do something useful with code. It teaches you about data structures and algorithms.

You will probably laugh at your first creations in couple of years but they will be very important in making you an actual software engineer down the line.

Well, first think of a site. Something that's not "hello world", but it's not Gmail or Facebook either. Something simple.

E.g. create a site were a user can log in, write notes, and save them.

That can be the start -- it's a real problem (not novel, but real) and it teaches you how to move forward from hello world.

Then you can add to it: - Auto-save the notes as the user writes. - Let the user write notes in a rich text editor. - Let the user share his notes with other users. - Let the user mail the notes. - ...

The first thing I built was a small website which was a music catalogue. When I think about it now, it seems utterly pathetic but it was the first thing I ever built. Later on, I got into WordPress and spent a lot of my time picking up PHP and writing new themes. This was an enlightening experience as I picked up a lot of plugin writing practices and I ended up being invited to a few WordCamps.

In the coming years, I learnt a good deal of JavaScript and was working with PHP frameworks to write a lot of admin interfaces for my own projects and some tools for my college's software development team.

In the last one year, I picked up Ruby and wrote a few tiny gems.

With this much experience, I have been able to port code from most of the languages I have encountered to all the languages I know.

Currently, I work at a company where I write a lot of PHP, SQL queries, a lot of front-end and all of us are expected to be full-stack.

My only advice to you would be:

1. Start slow. Try to spend a lot of time learning from other people's code and attempt to imitate a lot of code which is already out there. Solve the same problem many other's have done and trust me that you will learn a lot more from it.

2. Why don't you start a blog? You can start with a blogging system in the beginning and maybe later you can write your own.

3. When you say:

> "But I don't know how to make a site with logic and structure behind it that will lend itself to solid functionality that users can benefit from."

My answer would be, "If you can solve a problem for yourself, then there is bound to be a person who is benefit from it."

Good luck to you.

I learned by doing games, can't go wrong with that: Minesweeper, Poker/Blackjack (or any card game, implementing the rules of a complex card game is very educational), Tetris, Connect Four, etc. These are not unique projects and won't make you rich but keep on doing them one per week or so until you get a grasp of what you're doing. Just make sure you can and will finish your projects.

Small projects like that are also a very good way to fill your portfolio for your first entry level job. It's no substitute for a good CV but will certainly get the foot between the door compared to someone who doesn't have any work samples to show.

a todo list app shopping list app blog/cms simple crm tracking lego minifigures in your collection

Basically pick anything you would use, then dive in and start developing it.

You'll be creating a basic CRUD app initially but you can expand and improve on that as you go/learn more skills.

I'm not sure js/node is the best starting point but use what you know. Typically I recommend learning

html/css/js/jquery/php/mysql/(rails or laravel) then top it off with angular.

I recommend rails or laravel.

railscast.com or laracasts.com have lots of great tuts.

Coding something up from scratch before diving in to a framework is probably a good idea. The first time a started learning rails it was tough to follow what was going on behind the scenes. But after creating a few apps from scratch in php/mysql rails was a lot easier to learn.

Good luck, have fun.

The first step forward would be to change it from "hello world" to "hello {{name}}" and have the user input their name and the application show a custom hello.

Having this minimal input / output, now you can invest some time to make your app secure. This will teach you a lot.

Then you should feel ready to allow users to register, log in, and log out. This will teach you DB stuff and a lot more about security.

Then you should feel ready to allow users to add a profile with an uploaded picture. This will teach you about sophisticated UI issues, and even more security.

Then, except for scalability, machine learning and a few other special but mainstream technologies, I think you should feel ready to learn anything else.

Now you need to spend 3 months on a lisp language(Clojure, Racket, SBCL, Arc, doesn't matter), then another 3 months on Haskell, the King among Kings of programming languages, yet another 3 months on the almighty Emacs, and finally 3 months on Vim, so you can use the Evil plugin with Emacs. Only after all these, you can confidently and proudly start learning PHP, work on a Rails project.

You will thank me every time in the future when you visit Hacker News, Reddit or StackOverflow, every time you walk into a meetup, or join in a water cooler conversation.

Sorry, that BS. Nothing "lowly" or "bottom half" about Javascript or PHP.

(And I've started 20+ years ago on Sun OS and Solaris and HPUX and doing C in actual terminal boxes...)

If you're uninterested, please ignore, but here is something I want that might make an educational project:

A list of English words and/or phrases that are "phonetically contained" within Spanish words and/or phrases (and vice versa). For example, the English words 'cone,' 'tea,' and 'go' are phonetically contained within the Spanish word 'contigo.' (I'm trying to write songs in both languages that converge at key points). You might be able to do it with a https://www.wiktionary.org dump.

Problems are solved by tools. Powerful tools can be built with code.

So try first to think about what kind of tool would be helpful for you. How could a computer help you accomplish something that you couldn't do yourself on pen+paper.

One example I like was I was making designs for various sports teams, and I liked the idea of word clouds, but it seems like too much work. So I built a javascript app that counted words in wikipedia articles and built wordclouds form that.

It's a cool project, but the original seed didn't comde form thinking 'what problem can I solve with code' it came from trying to do something new, then thinking if that specific problem could be done with code.

Your question is much more important than learning code even for a long time. That is a good start. Even super great developers never solve a real problem.

Solving a problem, demonstrating a business model and creating a successful start up are -to my eyes- more and less the same thing and takes years of extraordinary hard work, much more work than people at an office could even imagine.

My advice, watch all these videos are amazingly useful http://startupclass.samaltman.com and try to attach as much as possible to the advices.

Best of the luck! Great start.

Regards.

Then find problems to solve. Lots of them.

Find a mentor.

I had my 15 year old son take these courses (with me acting as tutor). There is no way to describe the transition he made. From wasting his time learning a bit about a language here and a bit about another language there to focusing on one, learning how to solve a range of problems, learning about data structures and more. He cam out of that swinging and capable of approaching real problems (still with a need for me to coach, but a huge step forward).

This will teach you a lot of things... I can try to come up with a short list of what I've observed of my own development as a programmer.

You will recurrently come up with particular patterns, you start to identify which approaches will work, which will be dead ends and so on.

Try to separate your understanding and model of a problem to at least data, model and view domains. You will have certain data - you should keep this as simple as can be for the problem you are solving. There will be the model - how is the data mutated, which rules will guide it - and there will be a one or more view to this model and data. Note, that as a pattern the view encompasses both the possibility of an API to your system, as well as the actual display of data.

Try to keep you code as simple as can be. Don't go for the more complex solution unless you know you really need it.

'Pragmatic programmer' and 'code complete 2' are pretty good books about software development in general.

I would suggest you figure out what interests you and then try to implement simple programs in that domain. If something feels too complex, then first try a simplified version... more simplified etc. until you understand how to solve it.

One of the best knacks to learn is how to approach something from a direction which makes the problem easier to solve. There are usually an infinite amount of ways to write something and the challenge is not to just start writing code but actually figuring out which solution method leads to the most understandable and easy solution.

I would suggest you familiarize yourself with the practically important datastructures: the list, the binary tree, the map and the graph, etc. "Algorithm design manual" is a pretty good book for this. Aho's foundations of computer science is a pretty solid and free reference: http://infolab.stanford.edu/~ullman/focs.html

It's probably most motivating to mix the computer science with practical exercises unless you find you get a great kick out of it.

Good luck!

The most important thing with beginner projects is scope. Pick MVP versions of things you want to make and build out.

Real world projects often come from other people, the spec changes over time, and other devs need to collaborate with you.

Make me a tutorial site that exercises these two goals, with someone else at your level.

What program did you/your customer/other users need?

Then do it.

No course in the world will tell you the exactly need and how to solve it exactly -> if it exists, millions of programmers will be unemployed ;-)

I learned it when i was 10 years old (C64), i saw the "cool" games and thought -> i want to create my own. Learned Basic, learned Assembler and Build step by step many different games and programs.

I'd also recommend attending a Startup Weekend or hackathon of some kind and just joining up with a group working on something interesting. Being around the creativity at these can the wheels turning even afterwards

I'm assuming you don't literally mean you've written 'Hello, World!' a thousand times, and I assume you've tried more complicated projects, so where do you keep getting stuck?

Logic and structure doesn't leap, fully formed, from the head of an architect like some prophecy. It starts with some notions that are carefully honed into a working implementation.

Then think of a feature or modification that you think would be useful. Try and implement it.

It's incredibly painful but I find this works better than trying to build something from 'hello world'. Before you know it, you can understand why stuff was implemented that way and what not.

You have to keep challenging your boundaries. Don't do stuff you know, try to to do things you don't know. But keep each step upwards simple - don't try to build a skyscraper before you can build a house.

I also sometimes like to redo old stuff without looking at the code of my old solution and then compare. It is time consuming but really helps to see how you have grown.

I think your comment is a more direct way of saying what a lot of people have said: Break it down into smaller problems. You can go through each smaller problem and solve it, then move on to the next, until you're done. Once there, you'll have learned how to program. Or I should say, I will have.

That _passion_ was a HUGE motivator, in fact i didn't even like programming really was when I solved the problem, but I liked the result. I realized later how many problems could be solved that programming was the tool for the job so I eventually learned to program. But that came after I found the problems I was passionate about.

I find later that this approach was very fulfilling and now I am reading heavy textbooks and doing jobs I thought I would NEVER do because I really like solving problems. But I never could have seen myself doing this 10 years ago.

Now you're follow up question might be, how do I find my passion for this tool I have. Doesn't that now feel like an awkward question? I have a tool, I don't know why I have it, but I want to use it on something. There must have been some reason why you learned how to use this tool. What made you say "wow, how was this done?", or "I wish I could just do X" Try to recreate whatever it was that made you first look up "how to learn javascript programming" in google. If you are still stuck, then you might take to some of these other answers. Browse github, visualize something that could exist and work backwards, read other peoples code etc... but where all of them will fall short and where I suggest you take with yourself is that nothing will kick you on the curb harder then doing something that you're not passionate about.

The number of times I quit a program half way through because I lost the passion was A LOT! I felt miserable about programming for years. I thought I didn't have what it takes and beat myself up about it a lot. I was admittedly ambitious. Some things that could have helped:

* Smaller problems. Something you may not be able to control.

* Breaking your goals up into smaller chunks so you get rewards often.

* Working with someone else. Think of it like a running buddy, or a workout buddy.

* Being forced to do it. Get a job in programming, if someone realizes on you, and you feel that heat under your butt you'll probably end up doing it even if you loose the passion temporarily, though you should stop if you never get the passion back, but give it some time.

* Teach someone. You learn very quickly if you try to teach someone else. Especially if you try to force your brain to think of ways to find your passion. It's a good chance it will spark some passion into yourself as well.

Good luck, I hope something I said helped spark something in you and I hope you can find your passion! Or learn that this passion isn't for you. Someone once said that programming is 90% frustration and 10% elation. That gets you through that 90% my argument here is your passion to solve the issue. If you have no passion that 90% is going to be hell. But stick with it because it will take time! Good Luck!

I completely agree with "working with someone else". Find a programming buddy, do it. Join IRC and start becoming a regular in whatever channels you're passionate about (#programming, #rails... etc). You will find someone you kick off well with, and you will find yourselves working on the same project but the BEST thing is you will both make each other passionate and force one another to finish a project. It's exciting and fun.

However, "being forced to do it" I'm not sure sits well with me -- if you're forced to create web forms all day, every day, you'll get so tired, bored and you'll start to _hate_ programming. It's best to be around like minded people (even if it's IRC or your programming buddy).

My programming buddy is now my co-founder. Exciting times ahead! :-)

My last tip would be to learn algorithms, which aren't tied to any programming language but will give you a really good mindset for solving problems. It wasn't until I really sat down to learn recursion etc, that I learned programming for real.

write something that takes user input, stores in a database, and represents it later on.

CRUD (create read update destroy)

many webapps could be categorized as a CRUD app, or start as a CRUD app. if you've only gotten as far as "hello world" then i'd consider this a worthy "next target"

I'm currently learning Python and I did the Letter Frequency problem and I'm now working on the Bulls & Cow problem. I highly recommend you visit the website and pick a random task(s) and solve it using code.

1. Define the problem - think about/write down exactly what you want the final program to do.

2. Break it down into smaller problems, then break those further, right down to the smallest.

3. Solve the small problems individually, one by one.

First, have a good problem to solve. This is your design - developing your sensibility for it is somewhat independent of your coding skill. For your own project designs you should always prioritize your own motivations first, because there is nobody you are directly obligated to finish for. If you don't do this finishing will become very hard. Find problems people have already solved and reinvent their wheels so that you learn more about the problem domain. (e.g. if you want to learn how Facebook works, clone parts of Facebook - if you want to learn how operating systems work, build a toy OS, etc.) Or, find clients who seem to know what they want(nobody really knows - the design will change) and build things for them, on their terms, in a way which will get you paid so that you have the obligation to finish.

A good problem should be either obvious and a bit boring on the surface(an everyday thing made easier, more available, more accessible), or scary(a technical problem that you are not immediately sure how to solve, or are not sure how long it will take to solve). Usually projects start out looking like the former and then develop parts of the latter as you go along, forcing you to "plateau" on new features as you build out the infrastructure. You can also slice up a project into defined versions with incrementally larger sets of features so that your expectations for "done" are managed - if you don't get to some things, you still have a practically useful program.

Then, start working on it in small steps. Maybe you aren't sure how to envision the whole problem. In that case, you can simplify it by reducing the problem into a bunch of facades that are intentionally incomplete. Maybe you want to render a page that shows tables of data, for example. You can start by building up a facade for the presentation layer and see what kinds of data will have to be passed in to make the presentation work. Then you can mirror this at the other end and only solve the problem of "how to store and process the data." Then you figure out a protocol for making the two parts communicate. If you design each part so that it is simple to rewrite, the code will be maintainable regardless of your techniques or technologies, because then you can rewrite your way out of any corner you get painted into.

http://www.codeproject.com/Articles/699085/Some-simple-tools...

It's from a workshop called "how to build your first mobile app in a day"

Find something that would make you more efficient or something that you would personally use. It's going to be a lot of head banging at first but it keep banging away and then start adding complexity.

Skype ( it solve voice problem over ip and people uses it more than any other software)

whatsapp, Airbnb, Uber, Twitter etc or build something which people love to use

Start doing it. Within seconds or minutes you'll hit your first problem that will need a solution. Keep doing that forever. You are now a programmer.

Do you have problems? Maybe you just don't to solve anything at the moment.

A programmer stands between a real problem and a computer.

The computer does only what operations it is carefully instructed to do and no more understands the real problem than the chef's knife of a good cook understands cooking.

So, the work of the programmer is to take the real problem and see how to use the computer to solve it.

For this work, as a first step, if only to make the work easier for the programmer, get a first list of the data inputs for the problem and the data outputs. Yes the code for a Web page is a special case of this first step.

Then outline how the program will take the inputs and generate the outputs.

Here likely will need to define storage for the inputs, say, some or all of variables, arrays, data structures, instances of object-oriented classes, database tables, etc.

Then move on to the work manipulating the input data to get the desired output data. In the case of a Web page or any software with a graphical user interface (GUI), also will want to outline what the output will look like on the user's screen.

Then for the manipulations of the data, use the old strategy of divide and conquer, that is, break the work down into largely or entirely independent pieces of work. People have been doing work of wide variety this way for centuries, likely back to the pyramids and the first boats that could cross an ocean. For each such piece, have in the software a section of code, subroutine, or function. The work of such a piece may be further subdivided.

In the end, want each such piece of code, section, subroutine, ..., to be small, to have a purpose that is easy to explain briefly, that is fairly easy to debug, by desk-checking (that is, careful critical reading), running test cases, etc., and with logic that is fairly easy to create, explain, and follow.

This division of the work should be, at least intuitively, robust to small changes in the real world problem to be solved. That is, the division should be for a problem a little more general and complicated than the one actually given; how much more is a matter of judgment, but a small change in the problem statement should still be a small change in the software!

Next, in the division, exploit the scope of names rules in the programming language to help the software pieces be independent.

Next, remember that at least one human needs to be able to understand the source code and that "When a program is written, it is understood only by the programmer and God. Six months later, only God." So, humans need to be able to understand the code, for small projects, just by reading the source code and not needing additional documentation outside the source code.

Next, remember that humans communicate in natural languages, e.g., English, hopefully with sentences, paragraphs, etc. Remember that, no matter how much we might wish and intend otherwise, the source code of software is not in a natural language. Yes we can use mnemonic spelling for the various names we choose and use, and such mnemonic naming does help someone trying to read and understand the code, but such mnemonic names are still a long way from English. Bluntly, as information for a human reader, the code doesn't really mean anything or is likely a puzzle problem to solve to guess the meaning.

So, net, have to document the code, that is, explain the code to a human, explain with English, essentially with sentences, paragraphs, etc.

Here is an example of a technique in source code documentation: My project now is a new Web site; the source code for the Web pages is in Microsoft's Visual Basic .NET making use of the .NET Framework (collection of object-oriented class), SQL Server, ASP.NET, and IIS. For this work, I have 5000+ Web pages of documentation, nearly all from Microsoft's Web site MSDN.

So, my code makes use of a lot of classes, functions, etc. from those 5000+ pages of documentation, and some of those classes, etc. do a lot and need some good documentation. So, in my source code, when I use one of those classes, functions, etc., I insert in my source code a comment with the title of an appropriate Web page of documentation along with a tree name of the Web page on a hard disk on my computer. So, when reading such source code, one keystroke in my favorite text editor (which is what I use to write code) will display the Web page so that I can confirm that my source code is doing what I intend.

Since the code is awash in symbols, good examples of how to explain code are in good texts in subjects based heavily on symbols. So, can explain code much like a good freshman physics text explains Newton's second law or Coulomb's law or how a good freshman calculus text explains conic sections or differentiation. E.g., for English readers, mathematics is still written in English; then the symbols are names, that is nouns.

In large projects, the documentation may be hundreds of pages. But essentially always there is documentation as source code comments in the source code.

Then, six months later God, the programmer, and others will all be able to understand the code!

My view is that currently the biggest bottleneck in practical computing is poor documentation. Sorry 'bout that. YMMV!