Ask HN: I've learned a programming language – how do I solve problems with code? | Hacker News Reader

Ask HN: I've learned a programming language – how do I solve problems with code?

205 pointsbnb104 comments

I've spent a lot of time learning JavaScript (done the Codecademy JS course, finished CodeSchool's Real Time Web with Node.js, and read and implemented most of Node.js in Action), and I thought all I would need to do after I learned it was to start writing code.

Well, I can write code, sure. But I don't know how to _solve problems_ with it. I know how to create a webserver in Node that echos "Hello, World!" because I've done it a thousand times. 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.

How do I learn that?

View on HN

Excellent question for a Friday. Coding is like welding, how do you find two pieces of metal that need to be joined? Generally the answer is visualize something that could exist, but does not exist, and then fill in the parts that need to be there for it to exist.

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.

One of my favourite comments ever on HN. The welding analogy is apt.

I am learning to code and the welding analogy is helpful and encouraging. I am a competent welder (TIG, MI & Arc). I'm confident that with enough practice and commitment I will be an even more competent programmer.

In fact my gravatar is a welding guy. (since 2011 :)

Like said, I normally buy a domain and setup an idea and work on it. In the process I learn a lot.

Why would you buy a domain per idea for learning to develop? Sure for production this is a given but for fiddling about with things unless you have a good reason to work remotely why would you?

Because domain names are cheap, and feeling like you are actually producing something that the world can see is a great source of motivation. You also run into problems when you deploy to a real domain that you never encounter if you're just noodling around with code on your local computer.

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.

Said Right!

Because a domain would provide a real world example on a live server rather than a 127.0.0.1.

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

That comment. It made my day. It's one of the finest comment on HN

@ChuckMcM, your assignment on market theory is nicely put.

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 sudoku idea is a game version of Bitcoin, some sort of proof-of-work to get raw materials (mine). There have been some great write-ups of in game economies and since you want a simple one as a programming project it seemed like a reasonable stand in.

Don't start by trying to solve a problem. That way lies madness.

(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.)

I don't know why this got downvoted, it is very intelligent and I completely agree. Especially for kids, the most effective way to learn coding is to have complete visibility over all the underlying components.

Outside academia it is all about conformance to requirements -- i.e. you get paid to solve a problem for somebody somewhere.

True. But my read of the OP is that they learned for the pleasure and interest of it. They want to "solve problems" for the intellectual satisfaction and joy of doing so, not because someone is paying them or anticipating doing so.

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

Thank you very, very much for your main comment. I am actually a member of both academia and the realm of "regular people/programmers/hackers/whatever." I'm a college student, so a lot of my work is for the most part free (despite what most people think about academia). However, I also want to do programming for a living, and know I will have to conform eventually.

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.

I don't know your career ambitions and goals, but there is a lot to be said for the technician/mechanic/custodian (not really sure of the best word) who solves one problem and moves on.

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.

That is exactly why I made this collection of problems: https://github.com/karan/Projects

> 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

Find a problem first. Then try to implement a solution using your language of choice (Node in this case). An example could be: "I want to create a service that parses books and lists the most frequently words used. A step further would be to have the user enter a longer piece of text and analyzes it (http://www.online-utility.org/text/analyzer.jsp)"

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

>How do I learn that?

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.

You are exactly right on this description of the the pain that is learning to develop.

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 agree with this, but I do think there must be something that we're missing. Many, many skilled developers are saying "just go out there and build." The problem is we don't know how to build.

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.

Perhaps following along with an open-source project in active development?

I can't relate to baseball but I notice a common pattern that applies to most fields.

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.

Absolutely agree with this.

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.

Start. Jump in head first. Before you're ready.

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.

One of the best quotes I've heard about programming was from an old C++ developer I knew- "the best way to learn how to program is to start 10 years ago"

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.

Hi bnb,

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.

This is an excellent attitude to have and may be the only healthy attitude.

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.

This is definitely speaking to me. I started with .NET almost a year ago and I said I'm going to learn everything about the framework inside and out. I said it was my goal to be employed as a C# developer and love what I do. .. I haven't touched C# in almost 3 months. I got interested in Android which led to Java which led to Spring which led to Grails then I said "Hey whats Node JS?" then Ember and Angular .. and one book after the next. I test drive a framework to see what it can do and I have spent about a month digging into about 10 different frameworks and do you know what I discovered?

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.

And this is pretty much how it goes for everyone. At first you think that learning X language and Y framework is a goal unto itself. You then realize that solving problems is the real goal, and that languages/frameworks/libraries/whatever are just tools which enable you to get stuff done. Many of us could write a long list detailing all of the technologies that we know, but really; who cares? What have you done with them? That's the important bit.

First off, thank you for the excellent reply. I think I'll be saying this a lot in this thread, but I don't know how to express my gratitude for your response--it's shed some light on things for me.

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.

You're welcome. I'm glad that you found my write up helpful.

As others have mentioned, you need to practice solving problems with increasing complexity. You can try Project Euler which has lot of mathematical/computer programming problems. https://projecteuler.net/problems

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/

Remember, programming languages are a tool and problem solving is a skill. Learn data structures and algorithms. There are plenty of good books and websites out there on those topics. Once you have a basic understanding of those you can learn to apply your language of choice to implement solutions to problems. Next, find problem and solve. Also, some languages lend themselves to solving certain problems better than others. Don't limit yourself to one language. Once you have the knowledge of one language you are only a different syntax away from the next. Logic does not change, problems do.

A lot of explanations here about how other people learned to use programming as a tool for themselves, but everybody is different. One person's analogy for using code might not work for you. You have to discover what works for you on your own. Sure, keep the other analogies and things in mind, and ask yourself if you can relate, as you progress through your own journey. Everything is relative though, and your experiences are what make you unique and valuable to the community as a whole. Maybe you're the next Bob Ross of JavaScript - we want you to be. So, don't aim to mimic somebody else's experiences because that'd just be an injustice and it'd also take away from what makes this journey so rewarding. I suggest just visualizing some end goal of yours. You want to make a website that offers some kind of service of something? Visualize that site and break it down into chunks. Finally, dive in head first. Just start coding on it. Don't give a single thought to whether or not it's as good as somebody else's code. Don't worry about if it's the best it could be, yet. All you need to do is connect the dots, mentally, and play with the legos. Focus on hacking together something that, in the end, resembles that mental picture you had. Once you're there, a large portion of your original question will have pretty much been answered - you'll have use code to solve some problem. All that remains is to figure out how to improve. That's all any of us are doing - trying to improve.

Try make something that interests you, see how you would go around implementing it. If you're stuck with a feature, google it. Then see how you did against the "proper" way of doing something, and maybe adapt your code to use the "proper" method. By proper, I mean that it's a more efficient way to do something than to hack it together and have it just about work.

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 :)

Hey bnb. A few thoughts from my perspective.

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.

Just DO! ;) That's why it is named "learning by doing".

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.

For this, you don't need to ask yourself how you solve problems with code, you need to ask yourself how you can solve problems with products.

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.

I think what your question implies is this: "I learned how to write Javascript in a black box where I'm not solving real world problems, and instead just learned how to print static text."

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

See - you're solving problems. This is the kind of stuff you'd have to deal with on the job, and is the kind of stuff you'll deal with with your own projects as you or your users discover problems.

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

I'd love for this to be a mobile-friendly website, but it isn't. It's a useful tool, it looks like it's just a mashup of Google Maps and ZCTA's. A perfect project and problem to solve.

Yes! There are so many comments in this thread and the last one makes the most sensible suggestion: get involved with an open source project!

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"

A few of my friends are learning or have recently learned their first programming language. By my observation[0], what prevents them from building real projects is that while they know the language, they aren’t very comfortable with any frameworks.

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.

Your best project ideas are going to come to you in day-to-day life, like the time my roommates started complaining that the laundry machine in our basement was always being used. A couple days later, a simple web app was hacked together that displays the washing machine status, and let's anyone "claim" the machine. I did that project when I was in college, and I probably knew way less about web servers and Node than you. I just Googled the first thing I wanted to do "make a website", struggled for a bit figuring out DNS and hosting for the first time, and then put up a test page. Seeing a page show up on the internet at yourwebsite.com for the first time is a pretty magical thing, and the rest was history.

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!

The question is a bit open ended, so here are a few thoughts. Programming involves learning by doing. Just start on something. Perfection is the enemy of the good. Your first real attempt won't be perfect. In fact it will be downright terrible. Set your expectations accordingly and do not let this prevent you from getting started. It will also never be finished. Do not let the scope of the project prevent you from getting started. In fact you might even be bad at estimating the amount of time it will take. Ignore those fears and confusion and just start. Channel your weekend warrior instinct. Sit down on a Friday and just start typing stuff.

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.

This is a very common problem for people getting into software development. You are not alone!

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!

I remember exactly when I was at this point. I had a decent grasp of Java, but I couldn't build anything that I wanted to use. The way to learn is to build something you want, or something you'd like to show off. For me it was an Android app. I knew there was Java involved, but it taught me all of the things I could never learn from just reading a book (user interactions, getting data off the network, etc). Building my first Android app and my first Ruby on Rails website showed me 'real' programming. The funny thing is it turns out that stuff is all boilerplate rarely involves the fancy algorithms you learn first, but it's what makes real products.

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'm in the same boat and it's so frustrating I've simply given up caring whether or not I actually ever make anything. I did Udacity CS101, (253 was a nightmare), every single Codecademy track, Ruby Koans, Ruby Monk, Learn Python The Hard Way, Command Line the Hard Way, and the Ruby on Rails Tutorial. That's a couple of years of daily practice. There's no shortage of projects I want to make or actual problems I'd like to solve. I kept hoping I'd run across something that was close enough to what I actually want to do, that I could bend it to my will. Here's what I think would work: Using Michael Hartl's Ruby on Rails Tutorial as a model, add 10 projects that increment in complexity between 'Hello World' and the Twitter clone.

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!

Most people have already given you a very good advice.

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, I can write code, sure. But I don't know how to _solve problems_ with it. I know how to create a webserver in Node that echos "Hello, World!" because I've done it a thousand times. 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.

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

I started development actively in 2010. At that time I was in my first year of college doing Mechanical Engineering which I didn't grasp really well. So, I ended up putting all my time into development.

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.

Project ideas will come to you at some point. Meanwhile, while you're practicing, start making small projects that you know you can finish in a few days, but there's something new to you in it.

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.

Pick a problem you need a solution to . . .

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.

A nice thing about "hello world" applications is that you can always use them as the starting point for any other.

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.

No no, don't work on petty real problems just yet, because you have only finished half of the programming training, specifically the bottom half that is the lowly Javascript(or PHP).

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.

>because you have only finished half of the programming training, specifically the bottom half that is the lowly Javascript(or PHP).

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

Hi from Tent :-) https://cphuntington97.cupcake.is

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.

http://www.speech.cs.cmu.edu/cgi-bin/cmudict makes English pronunciation pretty easy. I've used it for versifying, e.g. http://wry.me/sonnetron/

What an interesting resource! Thanks so much.

If you want a process that takes you from problem to product I recommend one I have used in developing several real world solutions, described by Freeman & Pryce in the book "Growing Object-Oriented Software - Guided by Tests". Allthough the book uses an object oriented paradigm and Java (none of which I particularly recommend) the process described in the book's first few chapters is solid and makes quality software development more predictable - and less of an art. (For those of you in the know, but who haven't read the book, this is about TDD, London style, (outside-in) with a high level of automation (continuous delivery).)

Great question.

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.

You hit the nail on the head with a huge question, not sure if was on purpose or not but well done.

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.

The most salient part of your question to me was the word user. How do you add functionality to benefit a user? Once you have a clear idea who your user is, and what they want, the answer comes more naturally to you. For instance, if your user is someone who wants to know a piece of information, you can display that information. If there is logic to be handled depending on who the user is, you can google "nodejs authentication" and use a library to handle that for you. Everything is constructed in steps, and I don't think there's a magical barrier between writing your first lines of code and having useful functionality.

I was in this same situation for a long time and when meteor 1.0 came out I went through several tutorials, including discovermeteor, bulletproof meteor. Its like a wave of ok, now I can build stuff and its dynamic, I had a plan to learn socket.io and now it just works. I have also signed up for the free mongodb class jan-Feb so that I don't make a big mistake at some point and dump my database. I also used erlang zotonic for a while but meteor has a bunch more kool-aid that makes it easier when you get stuck or have a question. Oh man, good luck I have been in that situation and can really feel your pain.

Take the MIT Intro to CS with Python course. It's an introduction to using computational methods to solving problems. Then take the second course.

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

The answer will be 'write code'.

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!

Pick a small, simple project that will force you to learn new things and put pieces together. My favorite starter server project is building a super simple URL shortener. You just need to render a page with a form, accept a POST from that form submission with the URL to shorten, hash the URL, store it in a database, return the hash, and set up a GET that maps your hashes to your URLs by looking up against the database.

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

There's some great comments here to the effect of "find a project to do". That's ok, but I find the problem with that is you tend to find projects that you already know how to do, and you end up making a spec that is just a slightly bigger hello world. You miss out on collaboration and moving goalposts.

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.

Programmers learn programming by doing, they solve a problem / need, a problem for themselves, for customers, for other users.

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've often felt the same way. I've found things just by spending time brainstorming, and keeping it in the back of my mind as I go about my week. You can actually come up with a lot of ideas just by practicing observation of daily tasks you have.

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

What have you done that's more advanced than 'Hello World'?

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.

I learn it backwards. Take something slightly complicated (so much so that you find it challenging to read) that solves a problem that you understand.

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.

Pike's 5th Rule: Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. - Rob Pike, Notes on C Programming (1989) via https://github.com/globalcitizen/taoup

Start small then build up. Give yourself lots of small nonsense throw-away challenges, or maybe take one small part of somebody else's website and see if you can duplicate it.

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 think this is great advice. The only thing I can add from my own experience is - take your time to reflect on what you've learned once you achieve a new goal.

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.

The question you are asking is like"How do I build a house?" It's too broad. Instead ask, "how do I pour a foundation?" or "How do I frame a wall?" Figure out how to setup a database. Figure out how to execute queries between database and application. Figure out how to write a login form. Build up from there, one small piece at a time.

Thanks for this. I think this is a large part of my problem. I don't know how to do fundamental things, such as set up an index route with Express, or how to use a templating engine with that to display dynamic text, or how to use a database to store that dynamic text.

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.

Just do it! You need to pick a pet/side project of something you want to work on and try to figure out how to get there with code. Perhaps start with a framework and go from there. If you can't come up with a project, find yourself a product person friend who can brainstorm ideas with you and work on it together. Where are you based?

I'm based in the middle of friggin' nowhere, New York (State). Not many good programmers around here. The nearest big city is Albany, which I'd bet has some, but I'm not really in a situation where I can go there to meet up with people.

There are a lot of good answers here. What launched me into development when I didn't even know to program (so one step behind you) was that I found a problem I had personally had and looked for a way that could solved it. It turned out it was programming. The reason this was so effective was I was already passionate about the problem before I even knew what programming was. Then I discovered programming was the right approach, so I learned the tools to get the job done, then iterated.

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!

This is an excellent comment, and I really feel similar to you, and I have had the same experience!

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.

based on what you wrote, i would say the next goal is to write a twitter clone.

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"

http://rosettacode.org/wiki/Rosetta_Code

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.

Apart from good advice already given in this thread, solving problems with code usually consists of the following actions:

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.

The computer is an automation tool. When you write code, it is serving the purpose of automating a specified and designed process. The things you write in the program to make the automation happen only have to be as complex as is actually necessary for that task.

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.

Since you know javascript, read this:

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"

The best way to learn to sole problems is to find a practical problem and solve it!

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.

Read Programming Pearls to begin flexing your mind in the right direction. It's a somewhat older book in terms of the actual practicalities, but in terms of getting you thinking about how code is applied to situations, it's timeless.

Well i think you need pick a real world problem or need or an Idea and turn it into a product like

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

before i learned to program, i knew what i wanted to create. that was 13 years ago when i was too busy playing an online video game (nba live 2000) and i wanted to create an association league out of it, just like nba.com. first thing i knew i needed was a website, somehow picked php and after heavy amount of trial and error, just under 4 months or so i had a website going with my own forum, standings, team management system, player/team statistics, etc ... little did i know, that was all it took to set me off on a career path i've never have imagined otherwise and i love every day of it. :)

Why are you learning to program if not to build some specific software application?

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.

[H]ow to make a site with logic and structure behind it that will lend itself to solid functionality that users can benefit from.

How do I learn that?

When you figure it out, please pass the message on to the fifty bazillion useless websites out there, that all want me to enter my e-mail address and create an account, yet provide no benefit.

To create something that will benefit users, you need a brilliant idea, not only the ability to code, even to code very well.

If you don't have your own idea, then you get someone else to supply the idea. The idea will start out vague, then take the shape of concrete use cases (interaction scenarios between the proposed system and the people or other agents that use it). From those emerge requirements and a detailed design, and then some prototype code that becomes production code.

This might help: http://www.catb.org/esr/faqs/hacking-howto.html

Don't think too far. Find a problem of your own, your family or friends and try to solve it. Best chance is that if you have it, someone else might have it too.

See '180 websites in 180 days' project. http://jenniferdewalt.com

>But I don't know how to _solve problems_ with it.

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

Programming languages are a tool. Problem solving is a skill.

The best way to learn is always to just do it. Now that you r got some fundamentals down, think of a project that you would enjoy building. Now Google the little pieces together :)

find things in your everyday life you could use programing to make easier or solve

When I went to grad school, my career had been programming, and I'd done a lot of it for some years. Two applied math profs were starting a computer science course and asked me what good lessons I'd learned, and I answered. The answer remains current:

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!

Are you having troubles coming up with problems to solves or in getting started on a problem you've identified?

The reason you don't know how to solve a problem is because you do not have a solid grasp of what you learned. This will sound harsh but node.js is a horrible beginner choice. you should've learned python, java, php. asynchronous programming is a bit advanced way of doing things, and synchronous, functional programming works best. i've dabbled with OOP, but have rejected it largely because it doesn't work well for most of my projects.

Pick a new language, which will be now easier since you know javascript, create a simple project with it. Once you get to creating something, you will realize, the confidence to solve other problems. You keep going until you are very confident. You can't learn it, you have to use it.

Reply on news.ycombinator.com