Hacker News new | past | comments | ask | show | jobs | submit login

It usually comes in a phrase similar to "I know how to program, but I don't know what to program."

"How" is about yourself. "What" is about others. Both are important, but "How" ususally comes first. The best way to transition from "How" to "What" is to trust that you have enough "How" (you probably do) and talk to enough others to understand their "What". That oughta give you plenty to do.

In the software community the rule is "don't reinvent the wheel." It's almost frowned upon if you rewrite a library when a mature and stable option exists. While it is a good rule in general, novices should not be afraid to reinvent the wheel. When it is done for learning or practice, it's totally OK to make a wheel!

Yes! The best thing I've ever done to get better ("graduating" to the next level) was to rewrite something else. Sometimes because I thought it sucked, sometimes because it was so cool that I wanted to grok how it worked from the inside out, but never because it needed rewriting. I have never learned anything reading someone else's code. I have always learned tons rewriting it.

Don't get the notion that you need to have the best idea ever before you write a program either.

I never write anything in order to get ideas. I write stuff in order to fill my tool box with enough skills and wisdom so that when I do get an idea, I'll be able to run with it.

How many of you have been in the situation where you think "I don't know what to program?" How did you handle it? What advice would you give to others in that situation?

Just write something, anything. You probably won't know where this will take you, but rest assured, it will take you somewhere you never would have found by not writing it.

Great post! Thank you, OP.




The "what" is also about yourself. To be a complete programmer, as a creative artisan, you have to generate requirements and specifications, not only code. Ken Thompson didn't wait for PRD from product management before starting Unix.

Being able to generate the "what" is necessary even if you're working on other people's requirements. This is because other people's requirements are usually not so detailed that code will pop out. There are plenty of gaps where your creativity is required to go from the high level spec to the detailed spec. That's the design aspect of development.

The requirements leave out the "how": but hiding in every "how" is plenty of "what"! "This requirement doesn't say how such and such is to be achieved: what do we choose to satisfy that?"

Someone who has no idea or interest in programming something if left without external requirements is probably not a great designer; he or she is lacking at least some aspect of the "maker" instinct. The maker is defined by making; you would have to wrestle the craft out of a true maker's hands.

If you get a completely detailed spec handed to you, then you're just a "coding technician". Someone will make a programming language which directly executes such a spec, and you're obsolete.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: