To learn how to write real programs, you need to read real programs. Is Emacs bugging you? Open the source and see how it works. Web server crashed? Read the source and fix the bug. Not sure how to configure cron? Take a look at its config parser!
Many "programmers" spend their entire life treating everything as a black box. Take a look inside the box! That's how you really learn to program.
I'd start with something considerably lighter than that, but I do agree that reading code is a really important part of really learning how to program (well).
As for 'code monkeying' not being programming, I disagree with that, programming is the creation of specific instructions in order for a computer to reach a certain goal and I couldn't care less what the goal was or the way in which you arrived at your program. I'd definitely not go so far as to demean anybody that got in to coding that way, just like not everybody can be Michaelangelo we can't all be Peter Norvig.
From Excel to LISP and everything in between, it's all programming.
I ended up building all of my reports using MVC, before I even knew what a design pattern was.
One of them got so successful with his VB program formerly spreadsheet that he ended up making a very impressive fortune with it.
When I was a kid my 'toy' programs would be a few hundred lines of assembler or basic, rarely beyond that. Then the first time I hit a thousand lines (a score editing program) I realized that my old techniques didn't work any more and I discovered structured programming. This worked well for a while until the limits of organization for a single file were reached and I had to start splitting up the code in to large chunks that 'belonged' together in separate files and so on.
And that's just the organizational stuff, never mind the actual code or data structures.
To throw someone in on the deep end of that and saying 'Swim!' is not going to work except for a very few people that are genius level. The GGP might be one of those but for the rest of so (let's say ordinary mortals) that's not how you learn the fastest.
Of course, once you're ready for a 'big' program (say 50K lines and up) it really will be a great step forward, once you've mastered to read (and work on) a program of that size it will be a huge achievement.
I've never met someone that learned how to code out of the gate by studying emacs though.
And don't underestimate how much you can get done with 'toy' bits of code, libraries are so easy to tap in to that a few hundred lines will go a long way if all you want to do is solve some problem.
Check out some of the more involved 'R' programs that float around here for good examples of that.
You might be adventurous and read the rest of the file. Now you know how a whole major mode works.
Before you know it, you are applying those techniques to your own code without realizing it -- and now your code works like the rest of Emacs.
Show me any Emacs extension on the Internet, and I can tell you exactly how the author learned Emacs Lisp -- that's how different "I learned everything myself" and "I read the Emacs source code" methods of learning are.
> Is Emacs bugging you? Open the source and see how it works. Web server crashed? Read the source and fix the bug.
Both emacs and web servers are major programs, and analyzing them 'from the source' for debugging purposes is a different thing than analyzing how a single minor module works in it's normal environment. Debugging can have you rooting around in the basement fairly quickly, which is more than likely to overwhelm a novice.
Sure, emacs is built that way, but Lisp code isn't quite as easy to understand and debug as you make it out to be (judging by the number of people that hack around in emacs vs those that don't) and you have to keep in mind that you are very good at this, so it may be a bit hard to put yourself in the shoes of someone just starting out and maybe not at your particular level of genius.
What's easy for me may not be easy for you and vice versa, and hacking emacs as a start - at least to me - seems to be a bit much.
Plenty of people have trouble getting slime working, let alone hacking around on the guts of emacs without an experienced hand around to guide you.
If you say, "it's too hard", it will be. (You don't have to be productive on day one. But some day, you should at least take a look.)
If they read the source code, the magic would become understandable. The problem that people have with things like SLIME or monads or pointers or classes is that they build a mental model that's a lot more complex than the real thing. Take a look at the real thing, and your mental model becomes simpler and more in line with reality.
I am interested in well written code that falls into the light to read category. Can you provide examples?
You can memorize every line of the emacs code base, but unless you have a problem with emacs itself that you'd like to solve, it isn't going to get you far.
On the other hand, if you can't find a web-app to manage projects that works for you, and you decide to code one, you will learn much, much more.
For example, I learned C by myself when I was in middle school. The memory management technique I developed independently was "the library allocates, the application frees". No errors in valgrind, and my app works.
Then I started reading other people's C code, and switched my technique to "the application allocates, the application frees". Now C is a lot easier to write!
Assuming that you're the smartest person on Earth only gets you to a local maximum. To get to the global maximum, you have to interact with other people.
The way you interact with programmers is with source code.
I've learned probably 95% of all my programming from doing.
I do take issue though with the idea that the learn by doing crowd is somehow less accomplished. It smacks of baseless elitism.
Seeing other people's code does little for me because I miss all of the reasoning that went into it's creation. However, when I've fought through the same problem myself, I understand very thoroughly the traps, pitfalls, and solutions the task entails. When I reach this level, I can read other people's code and clearly see why they did what they did, and how it's better or worse than my method. I have to take a crack at the problem myself first, though, in order to learn well.
Reading other people's code is, for me, a way to refine and reinforce my techniques, not to learn entirely new things. I learn much less effectively when I try that.
At the end of the day, it takes all types to make software. Those who build the boxes, those who peer into the depths and improve or maintain the boxes, and those who use the boxes all work together to make great software.
If you have a real concrete goal, and your web server crashes, you'd try to fix it just like you say.
You need a CS degree to answer some programmer interview questions and as a quality indicator for kids right out of school, but plenty of really solid developers started learning by taking up smallish web dev tasks that became increasingly and increasingly ambitious over time. To get really good it takes years and years of doing this though.
That's interesting, the prevailing opinion here on HN seems to be that being in 'finance' is better then in CS.
Why is that different in your case?
I strongly disagree, as to HN's "conventional opinion". I think most participants and probably most lurkers, would say that finance is probably, on average, a more lucrative field, but a CS degree from a no-name university would probably be better for getting into finance, the field, than an equivalent finance degree. This assumes you're working for someone else.
A finance degree is less useful for a technology/coding business/startup than a CS one. This is the raison d'etre of the forum. I would also contend that for getting FY$, personally financially independent rich, a startup is probably at minimum equivalent to working in finance. As such, neither is a bad choice, but the CS degree has better options.
It's common for folks in finance to have undergrad technical degrees (e.g., physics, math, CS) and graduate degrees in something more closely related to finance such as an MBA or MS in quantitative finance. (Although the pure quants will usually have a PhD in math or physics.)
But frankly if you're a technical person IMO finance is a ghetto: once you're in, it's hard to get out. In no other industry can you make as much money to do work that generally speaking is substantially behind the curve technically (e.g., pre-STL C++ is the standard development language and mindset, and most of the time you're just moving stuff to and from CSV files and databases). But if you're disciplined with your spending it's a great way to save seed capital if one day you want to jump ship and try a startup.
I hope that makes some sense. Obviously it's hard to say where I'd be if I had gotten a degree in CS (or if I'd have made it out alive!); hindsight is of course 20/20.
But even if being in finance is better than being in CS, in places where performance is rewarded being in finance with a CS degree is better than being in finance with a finance degree.
There are many more besides it.
Flash 6 was how I learned programming. I realized I could create visual patterns and animations through code that I could never do by hand. The visuals were my goal, coding was what I had to learn on the way.
Copying and stealing is the best way to learn for me. Whatever I need to do, somebody has done something similar. So before I start, I find a code example or tutorial. First thing is to get it to run, then I make small changes until it does what I need it to.
This second approach works great for other things than coding, too. Taking apart and imitating successful designs, for example, is a great learning experience.
What made it click for me was programming in fear. Programming because I needed to. Programming because I gave a damn about my customer being satisfied and I wanted to get paid sooner rather than later.
It must be very odd programming 'professionally', only as a job and not as something you love first and foremost.
The problem with learning anything IMHO is when you don't enjoy it enough to want to learn it. And maybe that's a good signal that you shouldn't. Things are so much easier when you love what you do.
Learning how to program in a language with a similar amount of power to one that you're already intimately familiar with is pretty darn frustrating. It's hard to be intellectually curious when you're just learning new rules for the same game.
It must be very odd programming in your spare time, not getting paid for something that is inherently laborious and valuable. There are too many other people, places, and things that I love first and foremost to list programming for free as one of them.
If all of the software in the world that was created out of passion and love for the craft suddenly disappeared overnight the world would be a much worse place.
That is a problem in my opinion. If someone is creating that much value, that person should be getting appropriately compensated.
It would also be pretty bad if we suddenly lost all the software that was created primarily for money.
This is something I think that is a great sign of someone who you should/shouldn't hire. The best interview question is "So what side projects are you working on out of hours?". If they shrug and answer 'none', politely show them the door, yet it's surprising just how many programmers don't seem to have/want side projects - I guess they're doing it for the money rather than the love of it.
Definitely, life's about balance - spending time with family, living, eating, sleeping, etc but it seems like real hackers genuinely enjoy hacking, and want to play - even out of hours.
Don't get me wrong. I love to build things. I love writing programs that improve my life in some way. I love that I can see a difficulty in someone else's life and tangibly improve it (for free if it's easy and you're a friend, or for a fair fee otherwise). Programming is fun.
What is not fun is the mental masturbation of keeping up-to-date on all the latest-and-greatest languages and frameworks. What is not fun is building something with no tangible benefit. What is not fun is being insulted and dismissed by people who expect everyone to have the same interests and motivations as themselves.
In your list of "balance", not once do you mention friends. I have a few groups of friends (totaling probably 30-40 people) in my city that I hang out with a couple times a month, some of them a couple times a week. I have more friends from my hometown that I visit once every month or two. I have other friends in other cities that I see a few times a year. If you subtracted all of that from my life, I would probably have an extra 50 hours per week to spend hacking. No deal.
Just because I don't like spending my leisure time hacking doesn't mean that I don't genuinely enjoy the time that I do spend hacking. It doesn't mean that I don't have grandiose plans for things that I want to build (and make money from!). Your attitude about what constitutes a balanced life and a good hacker is very shortsighted and frankly offensive.
I have several friends who are musicians. A couple of them make up one of my favorite bands, having a really cool and unique sound. In my time hanging out with them, we watch movies, grab something to eat, lounge around, party, and generally enjoy each other. We don't spend much time at all playing music just for fun. When they are "doing music", they are either writing a new song, improving an old song, recording, performing, practicing something new and useful, or rehearsing for an upcoming gig. All of their musical work leads to money in some form. Why do we expect hackers to work for free in their leisure time?
Damn right. I hire based on who will be good at the job.
> "What is not fun is the mental masturbation of keeping up-to-date on all the latest-and-greatest languages and frameworks. What is not fun is building something with no tangible benefit. What is not fun is being insulted and dismissed by people who expect everyone to have the same interests and motivations as themselves."
Couldn't agree more.
> " Your attitude about what constitutes a balanced life and a good hacker is very shortsighted and frankly offensive."
Sorry, but you're kinda proving my point. The fact you don't want to spend more time on hacking rather than spending time with friends, means you'd make a bad employee for a startup.
> "Why do we expect hackers to work for free in their leisure time?"
I didn't say that at all. And FWIW, I play in a band as well. But I also spend an hour or so a day just playing for fun - because I enjoy it.
When did we start talking about startups?
So yes, my original comment is talking about hackers. Not "Systems Analysis Architect"s or whatever.
That is the most absurd false dichotomy I have read this year. You sound like the "artistes" I know who think that anyone who isn't raging against the machine is a pawn of The System.
Very nice resorting to name-calling. Because you can't conceive of someone who likes and is good at programming, but who enjoys other things in his leisure time, you again try to dismiss him with a low-ball insult. Nice work.
I don't know who you are, but you'd do yourself a lot of good to try to understand others better instead of insulting them and writing them off for being different.
Anyway.... I think you'd do well to lighten up and not take everything as a personal insult.
My original point: It's better to hire people who love what they do, rather than do it just for the money.
You can "love" to program but that doesn't mean you want to do it all day long. The love can come from the act of solving a problem, not the act of admiring how elegant the code works.
You need to disassociate the enjoyment from the purpose; they are not linked.
"You can 'love' to paint but that doesn't mean you want to do it all day long. The love can come from the act of solving a problem, not the act of admiring how elegant the results are."
Many people are drawn to hacking as others are drawn to painting or playing music (and these groups often overlap).
You're getting awfully close to a "no true Scotsman" fallacy. I know I'm not going to evaluate whether the guy who paints for himself or the guy who paints for a spot on the museum wall has a higher degree of "pure" love for an action.
It's irrelevant, really.
Right. There are no Scotsmen here, true or otherwise. My point is that some people do assorted things for the sake of doing them, for some intrinsic reason, not to solve some specific problem or address some external need.
Few people seem surprised when this is what motivates people to paint or play music, but when people say they feel that way about writing software, eyebrows go up.
That's how I learnt to speak French. It wasn't because I wanted to speak French, it was because I needed to. And you can only learn something by doing it. That applies to coding and speaking a foreign language.
May I be slightly selfish, and ask a question to all of you who have a CS degree? Did you learn programming as part of your CS education? Regardless, what's you opinion about the way programming was taught?
By the time I started taking classes, I'd already been programming for fun for a while. I continued self-teaching; it was both necessary and entertaining. In class, I was taught the basics of Java, LOGO, MIPS assembly, C++, Scheme, and Prolog, and course material also used BASIC (which my father had taught me), C, and x86 assembly (which I taught myself). The earliest classes spent a lot of time teaching the language, whereas later classes assumed that students either had prior knowledge of it or would learn it on their own (except for Scheme and Prolog since these were expected to be students' first exposure to functional and logical programming). I think the expectation of some self-teaching is really necessary to ensure that students learn to do so before they graduate. Putting together simple building blocks given on lecture slides only takes one so far; eventually, you'll have to do something you didn't learn to do in class.
May I be slightly selfish, and ask a question to all of
you who have a CS degree? Did you learn programming as
part of your CS education? Regardless, what's you opinion
about the way programming was taught?
Programming per se was poorly taught. There was little emphasis on long-term code management, and only moderate emphasis on writing clean modular code. So I learned better coding practices from more skilled developers while school taught me language syntax and concepts.
All through college I was fascinated by cellular automata and artificial life, so every time I had a new language class I went off to write CA code, trying to make them run faster, cleaner, and provide nicer options. Pscal, Fortran, C; never got around to doing CA in COBOL though; dropped out of that class. :)
Personally I had the benefit of having done a fair bit of programming in high school and on my own (Amiga AMOS FTW!) so I survived but I know it was very difficult for students who hadn't had any programming experience prior to university, and the drop-out rate from the CS program was very high (> 50% IIRC).
E.g., start with a minimal implementation of the Unix 'wc' command in Python, walk through it explaining how it works, and then assign as homework adding the '-l' line counting option. As a professional it's trivial, but if you know nothing about a programming it can be very difficult to get started doing anything. It's too easy for us professionals to forget how much we know now.
Focus more on the performance characteristics and design trade-offs of core algorithms and data structures (e.g., binary search, quicksort, dictionaries, vectors, lists) and less on the nitty gritty of implementing them.
Starting with interactive languages like Python that handle garbage collection and have high-level containers built in is also useful. Noisy stack traces when something goes wrong are also much more accessible than a C or C++ core dump.
Another thing that irked me was the expectation that we were already emacs or vi experts! For beginning programmers, Notepad or Gedit is perfectly adequate.
I breezed through the college freshman-level programming courses (and pretty much all of the later CS courses too) because I already knew most of what was being taught. My friends (most of whom had minimal previous programming experience) were much worse off; I don't think I would have done even as well as they did if I were starting from scratch as I entered college. I had a 9-year head start on them, although I learned at my own pace and on a self-directed, meandering path without any structured classes or tutorials.
Most of those friends graduated with a CS degree while still not fully grasping concepts like how malloc() works (this particular example comes from one of my friends who invariably showed up at my door looking for debugging help near the deadline of every C project, complaining that malloc was breaking his program). I feel like I probably missed out on some useful tidbits because I mostly tuned out the CS classes, since I felt like I "knew it all" already (obviously not true, but close enough that I could do well on the finals), but I am certain I knew more about practical programming than most of my friends who studiously applied themselves in those same CS courses.
If I hadn't had previous experience programming, I doubt I could have become an effective programmer in just four years of academic instruction (I certainly didn't fare so well in my non-CS courses in which I had no previous experience). Observing my friends, I could tell they were having a rough time with the way programming was taught, but I don't know whether that is a solvable problem within the time constraints.
I doubt my approach to learning programming was the most effective possible, but I think it's worked reasonably well. I learned to program because it was fun, not because I wanted to make anything useful, and I enrolled in CS because it looked like a way to continue that fun. In the end, I was disappointed by the (lack of) depth in the CS courses I took and the amount they rehashed things I already knew, but I suppose it's not feasible to tailor undergraduate courses to people who are already programmers. Perhaps with the growing accessibility and popularity of programming, there is a place for "CS for programmers" that would skip the introductory content and get into the real meat earlier than the third or fourth year. Certainly the courses I took met neither the needs of myself (too basic) nor my non-programmer friends (too advanced too quickly).
programming is about languages and tools, whatever is your anger or need,
some are more approachable than others
my dark beast for 10 years have been C and by extension C++,
got this kind of stupid idea that to be a "real" developer you have to know how to program in C
and true for 10 years I tried to learn C/C++, just learning it for fun or curiosity, and for 10 years it went nowhere, could not wrap my head around it
I was just giving up after a couple of weekends, losing interest,
and that was to blame on the fact I was just trying to learn it for the sake of knowing it,
I didn't really needed it
and then on a somewhat big open source C++ project I found a little bug (really a shit of bug that can be fixed in 2sec), I could compile the project but not really write C/C++, but still could fix that bug
that's what I would call "anger", knowing that this stupid little bug can be fixed in no-time by someone like me (being a total noob)
but from this "anger" came a very unexpected thing
on my day to day work, wether it's ActionScript, Java, PHP, Python, etc.
I can code it in my sleep, sure there are still some bugs and complexities,
but still nothing that I can consider impossible
because trying to add features to that big C++ code base, was something very hard to do for me and to some extend "impossible" or "how the hell I gonna do that", it ended up being
extremely rewarding and a kind of an obsession
so my little contribution would be to add: it's not only about the anger and the need,
it is also about how hard it is for you to do it
yep, hard is fun
the harder the better ;)
Even after a year of iOS programming, I still consider myself a beginner, and I probably always will be. There's nothing wrong with that. :)
Now, I read things to see what new ideas and libraries are out there... But it when it comes time to learn them, I use them.
Honestly, sometimes you just have to do it, even without any training. Maybe do it six times.
Is this really that rare? I think I've always been that way.
It is fun to dabble and be curious, but curiosity will not get you through some of the minutia that it takes to build a real app, and thats when need and willpower get you through to learning.
One breakthrough for me was realizing that programming is now a social activity. You have to meld with the hivemind to really get anything done, and while its good to have a mental framework of whats under the hood (I recommend the book 'code' by charles petzold for those without formal engineering training) it's more important to realize how to model all the abstractions that are part of modern software.
As paradoxial as it sounds, understanding abstractions is often works out to be alot like 'code monkeying' than theoretical computer science.
Or he could leave it and I am sure a screenshot of it will pop during a flame war about rails :) (or somebody will respond 'Try PHP, David')
Sometimes I wish HN stories could be downvoted.