Ask HN: I've learned a programming language – how do I solve problems with code?
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?
111 comments
[ 3.2 ms ] story [ 218 ms ] threadYou have to keep challenging your boundaries. Don't do stuff you know, try to to do things you don't know. But keep each step upwards simple - don't try to build a skyscraper before you can build a house.
I also sometimes like to redo old stuff without looking at the code of my old solution and then compare. It is time consuming but really helps to see how you have grown.
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
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 had (have?) the same issue. Maybe it's something that experienced programmers take for granted; there is a huge disconnect between writing code and developing software.
I've asked the same question, and received the same answer: get your hands dirty. I agree with the premise, and am working on it. But there's the disconnect. I can write a little Python, but have you ever tried to set up a Python development environment on your computer? I don't understand 95% of what is required.
All that said, I'm way ahead of where I was when I started, a year or so ago. I'll keep plugging away, and recommend doing the same. Hopefully we see a few good replies here to help us out.
Example: If you want to learn to play baseball. You learn the mechanics of the game. You learn to hit, catch, and throw. You can be an expert baseball player, and you can practice the shit out of mechanics all day long, and play games, and win games all day long for decades.
But if you want to manage a club and win games, you need to take that next step to learning the mechanics of the game beyond playing baseball, or all you will ever be is a player, and you will never be able to actually build a team that wins games.
Telling someone to go practice hitting, throwing, and catching in order to perfect their ability to orchestrate and manage an entire team of different moving parts would sound crazy.
And that is how it sounds when people continually say "just go write, fix, and build."
I do not have an answer for this problem. But, the answers that always rear their heads when this question comes around, have the opposite ideals of how anyone that has taken the time to learn the mechanics of development. Those people that have taken the time and effort to learn the mechanics are mostly those that appreciate clear and concise paths to solutions. And, as far as I know there is not good resource for bridging that big gap between mechanics and craft. I could be wrong, and there could be a wealth of this information on this process stashed away somewhere. But, the problem is that most of these paths are most likely buried somewhere in a course or resource that is shrouded in mechanics, when the learner is just looking for craft.
The person that clearly outlines this path from Mechanic to Craftsmen will undoubtedly be very successful.
I think there might be an implied aspect of this that we're not getting. Someone said to (paraphrasing here) "Google every problem you come up against; 'how do I do x with y, how does a work, how do I implement b, etc.'" That seems like it would work--if you Google every problem you have, or look at the docs for every function you use, a pattern will start building in your head that shows you how to do x with y. I think the key here is looking at the core source of the tools you're using and connecting the dots in your head.
You are told to do the basics over & over again so you:
a) Learn the motions
b) Learn how they work
You can't successfully apply your knowledge/tools/skills without knowing what makes them tick.
Let me phrase that with an example from my past. I was big into Starcraft at one point in my life.
Started with SC:BW. I was terrible back then, doing builds like an automaton following a recipe - I lost as soon as someone stepped out of the cannon and did something non-standard. Why? Easy. I had the mechanics but was missing the know-how on what made them work and how to apply them.
Instead of going that route I started to watch better players. They quickly diverged from the builds - enlightenment came when I noticed that they were playing reactionary. They observed their opponents and made decisions.
Why am I expanding now? Not because the build says so but because my opponent invested in tech so will not have the resources to pressure my new base etc. The basics are important, if you have your mechanics down then your mind is clear to react and just execute the movements to achieve the goal you want based on what you observed.
It works the same with programming. If you're stumbling with language syntax, your framework - the basics. You will then loose a lot of time hunting small issues and constantly loosing the big picture. When you're basics are down you are free to experiment and will notice patterns that beg you to apply one of the basics you learned.
Some problems are specific, fall into the 'what data structure, algorithm' should I use. Some are structure/flow related - how do I make those two things connect to each other and pass data around. Some are new - but they all mingle and repeat themselves very often.
When you read a lot of code, write a lot of code - you will start noticing the patterns. In the worst case scenario - knowing the basics will make it easier for you to ask better questions/find answers to hard problems faster.
There are hundreds of tutorials on how to write JavaScript, use the for loop, use if else statements, and so on. But not very many that I have found actually show how to use those to build a real program, explaining the steps and thought process behind the program along the way.
There are definitely ones that show you how to do things with it, but there's often not an explanation of _why_ something works the way it does.
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/
The most important thing with beginner projects is scope. Pick MVP versions of things you want to make and build out.
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 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.
The risk of creating a bunch of toy programs on your local disk that you never show to anyone is that you avoid the hard parts. Accountability is a good thing, in programming and in homework.
Also one would learn to tweak a server to the application.
Also one would learn to tweak a server to the application.
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 ;)
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"
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.
> 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
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.
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 :)
(The problem is that your mind, your approach, needs to change, and that change comes with practice and time. And practice always starts with the simple, the controlled, the repeatable, not the full fury of all skills brought together in a high pressure win-or-lose moment.)
Computers are nothing more than repetition machines. Start by writing code to do things that you yourself now do multiple times per unit time.
Start small. Simple things. Let the computer handle the repetition for you, no matter how simplistic and rude and hacky your solution.
Then notice how program A and program B, written to repeat different procedures, have similar processes or structures.
Generalize A and B to make a C that does both.
Do this again for other processes. Over time, your approach will shift. You will notice patterns: Patterns of process, patterns of structure, patterns of relation.
Then you will start solving problems. Only afterwards will you realize you have done so.
(I started coding shell scripts for anything I had to do more than twice - or anything that required "too many characters". I got tired of typing "ls -alt *|head" so I wrote nwst to do it for me. Then I added a numeric option to nwst to control how much head wrote. I got tired of writing "find . -iname" so I wrote fndi. Etc. Etc.)
We have to master the skills before we get rewarded for them.
That said, you're absolutely right in saying that I want to "solve problems" (that's just the best term I could come up with after months of trying to convey my meaning to many people--I have no attachment to it) for the intellectual satisfaction and joy of doing so. I really just love what I have done with writing code. It's really fulfilling and the structure of it resonates with me at a deep level.
So, your comment is very helpful. There's no end to the small problems or ideas that I have, especially within my work writing code. You may have answered this and I didn't understand, but the main thing I'm getting at with my OP is that I don't have the skill set to actually solve the problems. I know it probably sounds completely ridiculous, but I've approached many small problems and have always produced the absolute barest skeleton of the program which solves the problem I have. I then draw a blank on what I need to do next to continue solving the problem--the structure and the logic don't exist in my brain yet. That's what I really want to get from this thread, and I think there are some excellent responses that help with that, including yours.
If you are at all inclined to system administration, your approach (notice problem, solve problem quickly and effectively, move on to next problem) can translate to solid work.
Now I speculate: As an employee, this will probably lead to low to medium pay positions - at least until you start seeing and solving larger scale problems. As a consultant, however, if you can get a stable of repeat clients, preferably under retainer, you may actually do quite well.
Back to reality. How to make progress? Find an OSS project or two that you quite like, preferably ones with really good communities. Go through the lists of current bugs. Find and fix those you can.
Heck, just start finding flaws in people's code and documentation on GitHub, fix, and issue pull requests.
You will get a reputation in the community as a reliable, dependable problem solver. After a while, reach out to people who seem both approachable and a step or two above you. Ask if you might be able to help them with a larger problem, one which they need assistance with and on which they would be willing to mentor you.
That's one approach, at least.
Your academic environment may also have code that needs maintaining, patching, repairing, refactoring. Food for thought.
Keep at it, the penny will drop, things will click into place.
I know exactly a problem you can solve right now with Javascript.
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.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"
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!
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!