next »

[FibonacciSpaghetti]

+maetheec
+iEnjoyFreeBacon

That 'birds eye'/architecture is pretty awesome once you start getting it. All the joy of building stuff that fits together (and reacts to each other) without having to actually get off your butt and make stuff. Wish that programmers had told me how awesome that part was sooner.

[RobJinman]

Never really felt the "click"... but I've always enjoyed programming, now it's more or less become "what I do".

Now that I think about it, many programmer, including me probably go through these "phases"

First is when you just started, your focus is syntax and computer science fundamentals, like OO, data structures, design patterns, etc. During this time, you probably have to carefully think about every if-statements, every for-loops... like you're learning to write a foreign language.

Second is when you're fluent enough that you don't really have to think about the syntax and the basics too much... so you're starting to write something more complex... you're learning DirectX, or OpenGL, or you're trying to put together your first game. Your code is spaghetti and all over the place, but you managed to get stuff working, and you're learning new technology.

Third is when you're starting to notice that you have to think about the "architecture" your code a bit more, because you notice that you actually want to start writing reusable code (and you're embarrassed to show your code to the public). You start coding an "Engine" and feel that your engine is "pretty cool". You're also starting to learn more advanced language features like templates and function pointers. Pointers and references is now "easy" and you didn't understand what took you so long to understand it.

Forth is the hardest one to get out of... This is when you're starting to see the flaws in your "Engine", but you're also probably good enough to get a job as a programmer at this point. You over-architect your systems, so you rewrote it, but the second time to under-architect it, so you rewrote it again. Fortunately, each time you rewrite something, you got better, and better. You're also starting to learn every little details about C++, and you can even reference "the standard" when someone argue with you about some language features. You also found multi-threading to be pretty difficult.

The Fifth, and the final phase, is when you coding becomes your "first language". You're considered a "senior" or "the best" in your office. People come to you for advice, and junior programmer looks up to you. At this point, you still don't know everything, but you can learn whatever you have to know without too much problem. System that you wrote are reusable, and usually an important part of the game or software that you're working on. You're trusted with the most difficult task, that you only see as a challenge, and you'll say "give a week on that"...

Which phase are you in?

Amazing how accurate this is. I'm most definitely in phase 4 currently. I just keep rewriting my engine, over and over again. I'm getting sick of it, but I just keep improving as a programmer and becoming unsatisfied with what I've done so far. I'm also slightly embarrassed to show off my code. The better I get, the worse I think I am compared to everyone else. I've just posted a bunch of code samples on my blog, and am nervously awaiting the inevitable torrent of criticism (actually more like a trickle, as I get barely any traffic).

EDIT: Actually, thinking about this more, I'm probably somewhere between phases 3 and 4. I'm not sure if I could work as a programmer yet.

[achild]

When I started programming I didn't have the internet. No Windows. No linux! Just DOS.

I had been messing with QBasic and copying programs out of Contact magazine. Then one day my dad brings home Turbo C++ 2.0 on like 14 floppy disks. I guess it belonged to his boss at work but his boss didn't use it. I couldn't believe my eyes. I could finally use C, the thing that the pros used.

So off I went with nothing more than the in-built help, finding functions that looked familiar to QBasic. Aha! "printf". That looks like a good start!

For the longest time my programs were simply a giant function, called "main", with many gotos (since QBasic had that too). I didn't fully understand QBasic subroutines and functions yet. Then one day I figured out how to make my own functions in C, just like all those other functions that came with it (now known to me as the standard library).

Programming began to "click".

[Raisapius]

I learned programming when I was about 13, but it didn't really "click" until I was about 15 or so. I started hanging out on an IRC channel and one day decided to create an RPG bot for it. It took me a day or so to get the basic framework down, but after that, I realized that I could make almost anything I wanted with programming.

[seagaia]

I guess it slowly started clicking over the past year. My school's 2nd programming class throws you through a bunch of languages, forces you to use stuff in unix-like environment - and then there was some systems programming (C, x86...), so I got a better understanding of low level stuff, became comfortable with the terminal and so forth -  I was comfortable with programming and learning new languages/concepts, but I'm *absolutely* sure programming really started clicking with the current game I'm working on - the scale of it basically forced me to learn better ways of architecting my program and see everything from a higher level - managing many different types of objects and their interactions has made things more challenging, but forced me to learn more.

You reach a point where, as a project scales, if you don't improve your architecture, you're basically bound to fail - from too many edge case bugs, unmaintainability, etc - but I think you just gain a skill for architecting as you keep programming. I'm still totally a noob though, so much from a few months ago is god-awful.

It is kind of neat now, seeing code in a way that I wasn't able to a year ago.

 Also working at a company for a few weeks this summer has been useful in seeing how a really, really big project fits together, and how to work with others on a team when the project is hundreds of thousands of lines of code long.

[bateleur]

The Fifth, and the final phase, is when you coding becomes your "first language". You're considered a "senior" or "the best" in your office. People come to you for advice, and junior programmer looks up to you. At this point, you still don't know everything, but you can learn whatever you have to know without too much problem. System that you wrote are reusable, and usually an important part of the game or software that you're working on. You're trusted with the most difficult task, that you only see as a challenge, and you'll say "give a week on that"...

Regarding the section I've bolded above: if this still happens, it can't be the final phase. There is definitely a stage beyond this where you no longer get tasks assigned to you because nobody above you has the depth of understanding needed to know what you should be working on.

Knowing "everything" is impossible in modern computing, but merely reaching the point where you are able to teach yourself isn't enough to write some kinds of software. The reason is, you can teach yourself in response to perceived needs, but sometimes you don't know what it is you need to know. Only with a certain depth of experience will you start to pick good approaches to things consistently enough to design solutions to big problems well.

(In case you're wondering, I don't claim to be at that level myself. I have, however, met one or two people who are.)

[maetheec]

There is definitely a stage beyond this where you no longer get tasks assigned to you because nobody above you has the depth of understanding needed to know what you should be working on.

The stages I came up with is based on programming ability, not really responsibility. Obviously, if you happened to be a CEO or Technical Director then the only person that can assign you tasks is yourself (and may be executives/shareholders of your company). But that doesn't mean you're a better programmer than some senior programmer that doesn't like management or making business decision.
Some people chooses to stay as a senior programmer, and will not becomes a CEO, Lead Programmer, or Technical Director.

[FibonacciSpaghetti]

Regarding the section I've bolded above: if this still happens, it can't be the final phase. There is definitely a stage beyond this where you no longer get tasks assigned to you because nobody above you has the depth of understanding needed to know what you should be working on.

You're going for a Yoda-like status, right? Where he's so dang smart, he's the only one qualified to give himself orders anymore.

[bateleur]

The stages I came up with is based on programming ability, not really responsibility.

And nor am I talking about responsibility. Just because someone is above you in the chain of command, doesn't mean they can program as well. Someone can't issue you with instructions they don't themselves understand.

[_Tommo_]

And nor am I talking about responsibility. Just because someone is above you in the chain of command, doesn't mean they can program as well. Someone can't issue you with instructions they don't themselves understand.

This sounds like a big tech guy "pat on the back", reality is much different from this
you can have all the knowledge in the world in a field and it will still only be a tool. You could use that tool, or someone can ask you to use that for you.
I don't think that you finely know the details of the making of the chinese dish you eaten sometimes, or how you build a car, or even why and how the computer you use works at an electrical level, and still you can buy and use all of them.

So yeah, I can issue you something I don't have the smallest clue about how it is done, because (I think) I know what I want and you'd better do what I say

[Marty]

I feel like programming finally clicked for me when I took a class at Udacity, called Design of Computer Programs by Peter Norvig. I knew how to write a bit of C++ before that, studied OOP, played with Python, Ruby, PHP, Bash, Brainfuck, etc. But I guess when I took that class, I started to feel like programming was really easy. The elegant solutions were usually obvious (by design), and I finally realized that to design a game, I should probably start with the rules/mid-level before working on the graphics/low-level. It didn't so much illuminate me on any hard language concepts as it taught me to just code.

Alternatively, I quit trying so hard to use C++. Python is the language of choice at Udacity, and it's way easier to think in that or Ruby. I've started writing prototypes in Python and transcribing them to Actionscript, C++, even Ruby... I'm still grateful to C++, though it might have hindered me in some ways, because so few other languages let/make you think about memory and low-level data representations, pointers, raw binary data, and things of that nature. Sometimes that's crucial. Other times, it's hard to see the forest for the trees.

RE The Phases:

I've done these out of order. I've understood pointers well enough for a while, and toyed with function pointers, but never got into templates so much. I feel like I'm just now applying design patterns. Must've skipped phase two - I never tried to use DirectX directly (SDL FTW). Suppose at best I'm at phase three.

I think C++ for Game Programmers had a good linear progression of the more advanced skills, and a chunk of the other things you mentioned might be ordered by university curriculums (the data structures, algorithms), although that's several steps above simply learning loops and branching. If we were to really map out a person's progress, then I'd separate knowledge of language features from general programming/design sense.

[JobLeonard]

Peter "Head of Google R&D" Norvig? 

[Marty]

The very same. You should check out Udacity. There are also two classes from Sebastian Thrun of Google car fame. And there's a web app class from the guy who started Reddit.