Being a Non-Hacker in a Hacker's World
scribblesheet.co.uk
An article I wrote about being a non-hacker in a hackers world. It can be uncomfortable.
How many people on YC news cannot hack?
scribblesheet.co.uk
How many people on YC news cannot hack?
Then I made some friends who worked in the VFX industry, and I realized how much the life of an FX artist sucked. So, shortly after I got my first offer to work for an FX firm, I decided to leave town.
One of my friends, (he teaches FX at Sony Imageworks now) told me: The guys at Imageworks who have the most creative freedom are the programmers. The artists have to reproduce what someone else tells them to reproduce for 16 hours a day, 6-7 days a week. The programers write code whatever way they want to as long as the code gets the job done.
So, I picked up a copy of Hackers and Painters, left LA and enrolled in a CS program. That was 3 years ago. I've been plugging away at school ever since.
I've since moved to the Bay area, I'm finishing my degree in two more semesters, and I'll finally have a go at my startup.
I agonized and complained for months after I read Hackers and Painters because I couldn't hack and I didn't think I'd ever be able to. I was intimidated. But, then I figured if I didn't take the leap and dive in, I'd still be whining about it months or years from now.
So, if you're upset that you don't fit in in hacker culture, and that your not a hacker... Maybe you're trying to tell yourself something. Maybe what you really want to do is learn how to hack. It's what I wanted all along. I just didn't know it.
Coming from an art background though, you probably have a significant advantage when it comes to creative expression.
"Hack" is a verb that badly needs a direct object behind it, usually with the word "together" in between, and even then it's still cringe-inducing, because usually its usage takes some form of "look at what words I use." The word "hack" is practically a form of profanity.
I can tell that you have the drive, curiosity and the desire, though. I think that's the biggest part of it. Everything else is just learning and not putting your foot through the monitor the umpteenth time your code doesn't work. :)
I would strongly suggest trying out any of the many "Build an App is x Days or Hours". Grab a book or something on-line. They're everywhere. There was even a pretty good "Build You Own Ruby on Rails Web App" on the forum a few days ago (probably 2nd or 3rd page by now). Follow the instructions and do what they say. Build you app.
One of two things will happen: you'll either feel like I do and you'll be hooked. Or not. Either way is OK, but to not give it a shot in 2007 would be a shame.
(By the way, you'll probably find out that's how the best of us got started. School is cool, but nothing replaces just doing it.)
Best of luck
There are appropreate times to use the word "hack", when i am doing something really quick and dirty, just b/c it needs to get out asap, but probably I am not really proud of my solution, as it probably less maintanable on the long run.
When you heare phrases like: I did something "hackish", or my bug fix is kinda of a "hack", usually are not something programmers are proud of. Usually that means I did a quick and dirty solution to that problem, and not an elegant one.
In an early startup, i guess, being quick is the most important thing, but after a while you have to start caring about the long term of the code you are writting or end up like friendster, where their poor performance killed the company.
A good programmer will use a "hack" only as a last resort.
1. A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. RFC1392, the Internet Users' Glossary, usefully amplifies this as: A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.
2. One who programs enthusiastically (even obsessively) or who enjoys programming rather than just theorizing about programming.
Exactly. Using words out of the jargon file is crass. You don't "learn to hack". It's just wrong and painful, seeing that phrase.
If you hit a brick wall when you get to the chapter on pointers and arrays, don't panic. That's perhaps the first relatively hard thing to learn in C, it may take you a little while to grok it.
And I get the impression that K&R doesn't teach it well; I myself read the Lions notes to "get it" (_Lions' Commentary on Unix_, ISBN 1573980137, a critical 1977 book with the UNIX Version 6 source code and excellent commentary). Now of course there are many more good expositions on this and the other harder parts of C.
Aside from K&R being a bad first-time instructional book, C is just a bad choice of a first-time language. Most CS departments start freshmen with Java, these days (hell...back in my day, most new programmers started with Basic or Pascal, before moving into the ugly world of C.)
If at all possible, learn a scripting language first. Learn Python. Learn Perl. Learn Javascript. All are more productive and fun for first-timers than C. Compared to C, they're all ultra-expressive and ultra-friendly, and you will have an easier time understanding the why of programming, since you won't be as distracted with the details of the how.
And just to be devil's advocate, C is a fine first language to learn - it is small and encourages you to understand what the machine is doing. C++ on the other hand is not a fun place for beginners to hang out.
Just because most CS depts start freshmen with Java doesn't mean that Java is a great first choice.
I think learning C and Python/Ruby would make for a pretty nice combination.
There are other languages that you could learn first, but Python offers a really friendly cross-section of features and flexibility that makes it an attractive beginner's language. It's definitely the language I would teach to first-time programmers, given no other constraints.