Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Learning to Hack: the Tipping Point (zapier.com)
74 points by bryanh on July 8, 2012 | hide | past | favorite | 28 comments


I think the way that one learns to program says a lot about the programmer. I, like many people, started with games and websites, but although I understood conditionals and loops, and even glimpsed OO, I wasn't very good. My software sucked, I got bored of it, I slowed to a stall.

A couple of years later I picked up Python, and instead of trying to make games or websites, I worked on stupid little puzzles. Pointless things, really. After a lot of work I built a Befunge interpreter (probably my own "tipping point"). And many useless puzzles later, I somehow wound up a genuine computer scientist.

People always talk about "getting things done". I just worked on meaningless puzzles, and that was the best thing I could have done. Anecdotally, to me it was about achievements and challenges. If you grow tired of the drive to "get things done", make something pointless.


The "thing" in getting things done is fuzzy. For you it was a "meaningless" puzzle. For me it was an implementation of Conway's game of life. For others it was modifying their wordpress blog or making automating their financial tracking.

The point is there is something you want to do and you used a programming lanaguage to do it. As a result:

   * You were self guided not following someone elses steps.
   * You were rewarded with some self confidence when it worked.
That's the tipping point the OP was talking about I think.


I suppose what I'm trying to say is that for me it wasn't that there was "something I wanted to do and I used a programming language", but rather that I wanted to use a programming language so I found something to do. For me it was about the (self-guided) achievements and challenges: I wasn't "hacking a way to a solution," and would often return to the same problem and solve it again and again, never "falling back to really hacky solutions to get things done." It's a bit fuzzy (things do get done either way), but I think there is a distinction in approach.


OP here: exactly what I meant.


As someone with an interest in the programming world, I'm slowly "learning to code". I don't intend on ever developing in any occupational capacity. I'd just like to be able to have both a better understanding of what goes on under the hood, as well as be able to cobble together tools.

But I'm having trouble finding my own tipping point. I've worked through tutorials, online classes and introductory texts. Most of these things have you typing code in an editor, solving very minor problems, and seeing the results. But there's a big gap between, say, typing a little program in an editor, and a full blown web page or game. I understand that when you drill down in an iPhone app, for example, there's code back there, most of which I can't recreate, but can understand on a basic level. But what I don't understand is how that code gets there; how do all the pieces of code fit together to make a finished product, and how do you get it there? It's still sort of a black box to me, and haven't found the resource that can get me across that chasm.

I bring this up because I'm waiting for the epiphany, when I can say what the author does:

>"What had previously been a mysterious and confusing world suddenly started making a little bit of sense."

It's difficult when learning from scratch.


Two things:

It definitely helps to have some sort of scaffolding or small seed program to help get you started. If you're looking at other people's projects you don't see all of the small choices and decisions that they made, just the final product. That always seems a lot more complex and intimidating than whatever it is you're currently working on. (If they're on github, you can sometimes go back to revision 1 and see what they started with, then roll forwards and watch them work)

The second thing is that programming is a lot like maths, in that learning it in and of itself is pretty dull. Having something that you want to do, with programming being the tool that you apply to help you get there, is a lot more motivating (and seems to be the tipping point experienced in the article)


Appreciate the responses. Keep in mind this comes from a guy with no programming background.

I suppose I'm finding it easier to get exposure to the science, but not the art. Or maybe a better way to put it is, writing code is one thing, but making software seems completely out there to me.

I was a big fan of MUDs as a younger guy, so as a practice project as I work through texts and tutorials I've been building a little choose-your-own-adventure game. It started as a slightly modified "Hello, world!". As I learned about more complex things, from loops to functions and packages, to objects and classes, I've found ways to complicate the program by adding in the things I've learned. Now I have a couple thousand lines of code (bloated, I'm sure!) and a little game that, at the least, has a wee bit of depth beyond "enter your name:". But at the end of the day, it's some code in a text editor. I could spend more and more time adding more and more code, but it's still a command-line executed script. How do you make it "software" if you get my meaning?

There are other examples: I've been using python to learn to play with data, with some success. I can get data in, manipulate it a bit, and spit it back out. Great. But how would I automate that, drawing a file in from a folder automatically, manipulating the data according to my python code, then ejecting it onto a webpage into some graphing package. I know that isn't a complicated procedure (it's essentially a transfer of data), but I don't even know where to start.

Or you mention Github. While I know what it is (sort of), I have no idea how it works or why people use it,outside of sharing code. APIs? I know that they're a way to transfer data between pieces of software. But I don't know the first thing about how I'd use, say, the Twitter API, even to mess around for practice, by adding some extremely basic functionality to my "game".

This probably sounds ridiculous to people with experience. But I'm living it. I guess I feel like I've done enough programming 101 and am ready to see what 102 is all about. To me that's not "learn another language", it's "how do I turn code in a text editor into something". There don't seem to be many resources that cover the subject. That's the epiphany I'm waiting for.

It seems the answer is to define a small project, specifically, then set about doing it, with Google as your friend.


There's really not much difference between a script and a program, other than size/features. A program just has a few more added :) It perhaps seems like there's some extra sauce if you're looking in from the outside, but it's really just a case of iterating, adding stuff and polishing the "out of the box" experience.

Minor plug - I actually wrote a book which I think follows the pattern that you're looking for: http://manning.com/briggs/

It's essentially completely ass-backwards if you're used to traditional programming books, in that you don't learn everything about Python up front. Instead, it's a bunch of small-ish practical projects, and you learn as you go.

Chapter 6 is an adventure game, and chapter 10 turns it into an networked MUD via twisted - it sounds like what you're trying to do. But there's also business stuff - csv parsing, etc. - an asteroids clone, writing a web app in Django and so on.


The book looks awesome, thanks a lot for the link!

Just yesterday, I started teaching my co-founder how to code in python, and wanted to very quickly get to something useful to give him inspiration to keep going.

I ended up starting with the python interpreter for ~30 min, followed by writing a very short program to show a random inspirational quote on the command line, and then turned it into a module so we could import it back in the interpreter. The end goal was to show how programs get built up from smaller pieces and can become more and more complex.

I think he really started to get it once we added a few test functions to test the different range of inputs to his "get_quote" function.

Next time, I'm going to show him Django via simple demo site and hopefully he'll be at the point where he can start editing HTML. (I'll either use https://github.com/mpdaugherty/django-demo-project, which displays quotes and demonstrates views and templates, or https://github.com/mpdaugherty/RateBeers, which rates beers and adds in some DB models, depending on how far he gets).


>"There's really not much difference between a script and a program, other than size/features."

Saying so is the luxury of having reached the tipping point!

You sold a copy of your book, so plug justified. It looks interesting. Hopefully it can fill in a few gaps. Thanks.


Cool! :)

Don't forget that there's an author forum if you get stuck and need a hand. I check in every day or two.


It also depends on what you want to get out of programming. From a pragmatic perspective:

One option is to look at code that's embedded into other platforms. You talk about data analysis. Perhaps try looking at OpenOffice (which I know has Python bindings). Import your data and get OO to do the heavy lifting of creating the graphs.

Remember: The whole point of programming is that you get shit done by giving a general purpose system specific instructions to carry out.

For large parts of the "Build an application" questions you have. It depends on the tool you use. If you're building an iOS app -- XCode includes Interface Builder (which lets you drag and drop GUI objects and link parts of your code to them). If you started coding in something like Visual Basic you'd have the same thing. These sort of tools make it easy because the design a gui and package the app are all baked in. A Web example is probably PHP. For Python you can look at tools like pyGame or wxWidgets


I'm in a similar position to this, except that I really do want to get ton occupational level. My goal is to be employed in web development. I can hack some things together, and I can get through tutorials reasonably easily at this point. Almost all of my code at this point is plagiarized from someone else, then modified to meet my goals. So when is the tipping point when I can start to look for employment? I liked this article, but I'd like to see my question answered as a follow up.


Dude. Honestly, you have all the tools that you need to be fairly good at coding. I can already tell.

long post

What you're really fearing is the unknown, so think of it this way...

Coding is a bunch of logical expressions thrown in to essentially one lump which ends up making a computer do a bunch of things. That's basically it. Now we have patterns, best practices, algorithms, classes, etc., but those can be learned as you go. Don't worry about it, you have all the tools.

How do I know?

You were able to make a post on HN. That is, your mind has mastered (to some extent) the coupling of language and logic.

You already know logic... Your sentence structures have the basics going [subject verb object]. You know that in most cases, your sentence will not make sense if you omit any part of the basics. Same with a program. If you omit something in the logical arrangement, your program will not work.

--------- You already know flow... Your post goes from the top down. A lot of programs does that. That is, the tasks are processed from the top of the program until you get to the end. Now, we do skip around, but that's because during the flow from top to bottom we call other functions for help. Think of functions as an extension of the flow (just in another location) and you'll get what I'm talking about.

   Now we do have events as well. Think of when you're clicking a button, something happens. In that something, it also uses a top down approach. 
--------- You already know conditions... You've created basic guidelines for getting your paragraphs to work to your liking. I've noticed a few if/else conditions that you're using... 1) IF I explain this part of my coding history THEN the readers will realize how badly I want guidance help... 2) IF I use a general/cliched phrase THEN I'll put quotations around it (e.g. "Hello, world!" or "how do I turn code in a text editor into something" ELSE no quotes will be added around the word/phrase

--------- You already know abstraction... Your using paragraphs to abstract topics/themes to be separate from one another. In CS we use functions and classes.

--------- You already know how to utilize classes... You're using a combination of letters to form what we call words. With those words, you have created sentence. Your mind has already figured out that if you utilize these words and sentences in a certain order, it will return something useful.

--------- Now why did I go through all of this to convince you that you know more that what you think? Because I'm insane. No, that's not it. I hear a lot of people say that they aren't smart enough to code. Yet, these same people can memorize entire albums and television episodes. Memorization uses a lot of CS tools if you think about it. You're using logic, flow, conditions, abstractions, classes, etc. You just don't know that you're doing it.

I have a friend that, for the past 3 years, explained to me that he wasn't smart enough to code. I ended up giving him a run down of all the basic things needed to make a basic web app. It confused him, but it gave him exposure.

After a couple of months He called me and said he had a "great" idea for a site for his wife. He spent about a month working on it before I took a look at it. The site was functional. It wasn't great, but it was functional and dynamic. I gave him some pointers, but a lot of the work came from him seeing what he wanted to do and running with it. Yes, with good ol' Google. All he needed was the basic guideline. All he needed was some exposure.

I think that's all you really want/need. I can help you out if you'd like. Here's my tools... HTML - text and boxes on the page CSS - making things look pretty JavaScript(JQuery) - making things move Asp.net (or PHP) - server back end (mostly a communication tool with the data base) SQL Server (or mySQL) - the database (stores a bunch of data)

That's about it. Those 5 things. You can do a lot of really cool things with that. If you need help, don't be afraid to ask.


>"Dude. Honestly, you have all the tools that you need to be fairly good at coding. I can already tell."

Good to hear!

Like I said --and how the original article struck me-- I'm just waiting for that feeling of getting it. We've all had it. I've felt it with thousands of things in my life, from Calculus to playing Street Fighter 2. Up to this point every introductory text/course says, "Look! You're programming!" and I sort of think, "Am I, really?"

At the end of the day, I realize that learning anything is a function of time, and I certainly haven't paid my dues there yet.

>"All he needed was some exposure."

Another good point, which causes me a bit of internal strife. There's a wealth of information out there. In fact (first world problem alert), there's almost too much. Try typing "learn to program" or "introductory python" into Google. It's exhausting. I'm looking for the next incremental step in this learning process, but both my problem and the solution revolve around defining what it is I'm looking for. But, as you and others have suggested, I think the answer will come from looking at other's code and plugging away.

Thanks for taking the time to reply.


Do you really want to program? Send me an email. I'll be your mentor.


I've taken the exact same approach through the years as I've gradually started working on more complex projects. So, it's sort of comforting knowing that I'm not alone in the "just get something working, no matter how ugly/bad it is" camp. This sort of mentality, no matter how good/bad, was really helpful because it forced me to take a look at what I had made objectively, as I began to look back on old code/projects I wrote and finally ssee not only how "ugly" it was, but more importantly, why it was ugly.

I'd then move on to a more challenging project, proceed to find some horrific, hacky solution, then talk and show it to people smarter than me and who could point out better ways to do things. I think if you're able to look at things you've made from years back and say "wow, I was a much worse programmer then, for these reasons", that says a lot about how much you've learned so far.


It's probably a lot easier to understand a larger project like a game or a website by trying to implement something substantial on your own. A lot of the obvious approaches to coding that work for small examples don't scale well for one reason or another. In the process of running into roadblocks and finding solutions (typically with the help of google) you'll encounter some of the pieces that end up in something like an iPhone app and at that point you'll probably be in a much better position to understand them.


I am 35+. Never coded myself except for small feats in HTML/CSS. Background - corporate finance.

It's difficult to learn from scratch, but it is not that difficult.

If your goal is web development, then I would point several key things that worked for me:

1. Don't be afraid to start and try it out.

2. Knowledge builds by iterations.

3. If you stumble - make a break, then get back to the stumbling block. Most of the times it will be solved fast.

4. Keep your end in mind.

5. Do some practical project, that has value for you.

About me:

- punched with HTML/CSS; hand programmed simple static site;

- got aquainted with Drupal; digged into Drupal; installed on hosting, installed and played with some modules, played with changing themes;

- started Django - Django book, tutorials, various books - stumbled;

- read through Learning Python by Mark Lutz, did exercieses - stumbled after 60-70% [decorators, etc];

- returned to Django, continued with books & simple projects - needed to get static assets working -> had to install webserver, did not want Apache, so I tried nginx - stumbled;

- got VPS from Linode - but needed to know a bit CLI and Ubuntu nix, since server is headless; stubmled - went through CLI tutorials;

- at the same time when installing web server stumbled with DNS, had no clue how it works, stubled - so digged through wiki, blogs, etc to understand the basics;

- with CLI and DNS basics under my belt, started setting up VPS - some packages in Ubuntu repositories were old and security risk - installed from PPA, but had to compile nginx, postgres, some other packages;

- installed!;

- in one week the whole set up was hacked;

- went through too many tutorials on nix hardening; iptables; auditing tools ; honeypots; logging local and remote; server monitoring [Graphyte and friends]; rootkit detectors, etc

- now back to Django...

In the background I digged a little bit into - databases [postgres, mongo, redis]; js [charts, various other libs]; some Python libs [requests, Pygments, etc]; OLAP/BI and host of other things.

That is a short summary w/o too many details.

It is a lot of fun - don't limit yourself. Your fears are your first enemy. So just do it.


This is something I talk all the time with students that are being taught all the programming classes in college. Most of them know how to program, or at least know the syntax of a language and know basics, but getting to that tipping point of having hacked something up is kinda hard for most people. After you've built that first thing, that isn't the obvious programming exercises found on textbooks, you've passed that tipping point and hacking will then come naturally to you.


A lot of people don't like the "discomforts of exploration".

Folks have mentioned that creating solutions to your own problems helps a lot. Well it does, but it takes some out-of-the-box thinking to realize that you do have a problem to solve.

Programming is like using an Erector set. You get a lot of pieces and can place them together quite easily. But when push comes to shove, how many are going to (or willing to) build a baseball launcher so they can avoid "pickling the Beast" (Sandlot reference)?

That's where imagination and subdivision comes in. Yes, you can learn all the theories and syntax that you'd want, but if you don't use your imagination and divide-n-conquer methods, you'll never make it.

Once you'd get past all of that, the sky's the limit. I'm proof of that. I hear of all of these miracle languages and frameworks, but I stick to what I know. Why, because it had solved so many problems before. And its because I have a vivid imagination and know what it takes to get the task completed.


I remember learning to code in Game Maker a while back, so each time I had an end goal in mind: the game I want make. In that time, I made 8-10 crap games, but each time I would code, I would more and more swap out the pre-build code actions with actual code as the complexity of the games increased. Besides the fun of making games, it was great discovering the underlying code, even if it is something as rudimentary as Game Maker's scripting language.


Wow! This is how I learned to code too! I remember when I around 12-13, I wanted to figure out how to make my own message box in Windows (yes, I was weird). But I didn't know there was such a thing as "programming". In fact, I had no idea how software was made.

Eventually I stumbled upon Game Maker -- I think it was at version 4 when I found it. So I began creating little games with that cheeseburger icon and snowmen. Eventually, I realized that this thing called GML would let me do more. When I looked in the help file, one of the functions said to enter an "argument" and I seriously spent like 2 days trying to figure out what an argument was.

Eventually I got a Mandelbrot fractal going in Game Maker and discovered C at that point.


Wow.Straight from Game Maker to C? Sort of happened the same to me. Up until uni I only knew Java, Game Maker and basic PHP/MySQL then started with C in freshman year. Although I mostly do web development these days, I liked working with pointers and memory management in C (once again delving down deeper).


Well said. I still go through that cycle every time I try to learn something new. Cocoa was really frustrating, especially as the debugger threw me into compiled assembly code. But once I got through the initial hurdle it became much more fun. Had that experience with Django lately too. The best (arguably only) way to learn seems to be learn by doing, reflect(which includes summarizing mistakes, reading tutorials, talk to expects, etc), and do some more. It tends to work out best when you have an end in mind, a real project that you are working on, which is what a lot of coding tutorial fails to deliver.


Agreed. I feel like we are probably the first generation who has grown up with the world's knowledge at our fingertips. Once you know how to use it, every problem seems solvable. Yet still the majority of my friends don't have this attitude. I've forgotten how many times (as the 'tech' friend) I've directed them to an lmgtfy.com link. I wonder what stops people from grasping the concept you're talking about here - from experiencing their own 'tipping point'.


That's an excellent question. Our current institutions (school, work) are set up so that people by and large respond to commands from a higher authority.

Entrepreneurship gave me the incentive to find things on the one, and also made it necessary.


The article is nice, learning by doing is way more effective than just reading about something. I just don't feel very confortable with the word "hacking". This term is so overloaded nowdays that it's almost meaningless.

Anyways, good job :)




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

Search: