Hacker News Reader

Comment by Skywing | Hacker News Reader

Personally, I think planning out which languages you're going to learn over the course of an entire year is a pretty good plan on how to not become a hacker. Think about what you're about to do - you have a startup idea and want to execute it, so instead you're going to learn a bunch of languages that you probably wont use. How does that sound like the right way to get you startup off the ground? Well, it doesn't to me.

I'd suggest that you ask around and determine what languages other people are using to execute their startup ideas. For example, I think Python would be a great start. Perhaps learn Javascript too, since it has many applications.

Don't focus on learning all of the languages. Focus on executing your brilliant idea, and learn the languages and frameworks required to do so.

View on HN

I get what you are saying and it makes sense. I made the plan I did because I didn't know where to start and figured focusing on a sequence of languages would be a good way to get a solid foundation.

But I agree, once I have the basics down, I should just start executing and learn new languages and frameworks as needed.

Thanks

I believe you are missing Skywing's point. Learning to hack requires using what you do know to get things done and only worrying about what you don't know only when not knowing it becomes a problem.

For example if you don't know any kind of code at all, draw pictures of your application screens, then learn HTML and CSS to mock them up, then learn whatever framework and language is handy to handle the backend and logic necessary to tie them all together.

A working kludge is better than a perfect code in one's head.

Largely true, with the caveat that learning new technologies expands the scope of what you can get done.

I can't count the number of times that I've learned a new technology and thought "You can do that? Woah, that's what I want to present to the user. None of this ugly kludgey stuff that I was gonna do."

I've also found that the hardest part about eliciting requirements from non-technical people is that their vision is constrained by the systems they've used. You ask them what they want, and they'll give you something that looks basically what they're already using, but with a few minor annoyances fixed. If you actually build that, you'll find that they won't bother to switch over. You usually need something that works in a radically different (and better) way for people to use it.

For example, you shouldn't assume that application screens, HTML and CSS is the right way to solve the problem at all. Maybe it's better done as a mobile app. Or maybe you're better off wiring together existing apps (say, Google Docs or Drupal) and writing a bookmarklet with a little bit of JavaScript glue. Maybe you want a hardware component and will be selling a physical device, like WakeMate.

Agree that learning languages isn't the way to discover these technologies. Instead, focus on algorithms and APIs. Learn what's possible before diving into the details of how to get it done.

Reply on news.ycombinator.com