
Ask HN: I've learned a programming language – how do I solve problems with code? - bnb
I&#x27;ve spent a lot of time learning JavaScript (done the Codecademy JS course, finished CodeSchool&#x27;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.<p>Well, I can write code, sure. But I don&#x27;t know how to _solve problems_ with it. I know how to create a webserver in Node that echos &quot;Hello, World!&quot; because I&#x27;ve done it a thousand times. But I don&#x27;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.<p>How do I learn that?
======
ChuckMcM
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.

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

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

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

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

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

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

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

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

------
karangoeluw
That is exactly why I made this collection of problems:
[https://github.com/karan/Projects](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](https://github.com/thekarangoel/Projects-Solutions)

------
j-rom
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)"](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](http://jairampatel.com/projects.html)

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

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

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

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

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

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

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

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

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

------
rlearner
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](https://projecteuler.net/problems)

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

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

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

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

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

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

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

------
wellboy
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](http://www.paulgraham.com/start.html).

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

------
Ologn

      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.

~~~
jakobegger
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"

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

------
primitivesuave
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!

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

------
d4mi3n
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!

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

------
i4i
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!

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

------
coldtea
> _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. \- ...

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

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

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

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

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

~~~
coldtea
> _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...)

------
cphuntington97
Hi from Tent :-)
[https://cphuntington97.cupcake.is](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](https://www.wiktionary.org) dump.

~~~
abecedarius
[http://www.speech.cs.cmu.edu/cgi-
bin/cmudict](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/](http://wry.me/sonnetron/)

~~~
cphuntington97
What an interesting resource! Thanks so much.

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

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

------
JoseVigil
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](http://startupclass.samaltman.com) and try
to attach as much as possible to the advices.

Best of the luck! Great start.

Regards.

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

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

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

------
fsloth
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](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!

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

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

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

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

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

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

------
contingencies
_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](https://github.com/globalcitizen/taoup)

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

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

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

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

------
husseiny
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?

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

------
jastanton
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!

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

------
hayksaakian
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"

------
arc_of_descent
[http://rosettacode.org/wiki/Rosetta_Code](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.

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

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

------
minthd
Since you know javascript, read this:

[http://www.codeproject.com/Articles/699085/Some-simple-
tools...](http://www.codeproject.com/Articles/699085/Some-simple-tools-for-
rapid-mobile-development)

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

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

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

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

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

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

------
kazinator
_[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.

------
krmboya
This might help: [http://www.catb.org/esr/faqs/hacking-
howto.html](http://www.catb.org/esr/faqs/hacking-howto.html)

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

------
surganov
See '180 websites in 180 days' project.
[http://jenniferdewalt.com](http://jenniferdewalt.com)

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

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

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

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

------
graycat
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!

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

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

