One day, I was told to make "a quick fix" in some horrible code. I just opened it up and entirely read it, understood it then fixed it in one row. I mechanically added some comments to explain what the code was doing, what I did as a fix and some "// TODO" to keep tracking of the improvement it would be nice to make.

It took me less than an hour.

Then I just "woke up from the flow state", and realized how natural it seemed to be. Some years ago, I just coded like that guy, wasting time on easy stuff, scratching my head and working messy. I just told myself : WOW, ok now I am a programmer.

Did that happen to you ?

+3  A: 

The day I "got" references in Java.

To this day, I still find it hard to explain really clearly how references work (and so does everyone else, in my experience). The trouble is that when you grok references it's quite hard to imagine not groking them...

Jon Skeet
Very true Jon. Lots of misconceptions surrounding them.
+4  A: 

Learning how to unit test...properly, and how mocking should be used.

Nathan W

I think I don't have as much developement experience to talk in general. I just realized yesterday the difference how I programmed my first application in my first work as a programmer. It was very similar. I was just commenting each line of code with 4 lines of comments. So that in the future I will know exactly what this line does.

From the perspective of time: I've never seen this code second time, I've changed job and now I think it was only my wishing of what programming looks like. I thought it is good to have so commented code. Now I see that there is much more than comments and even if I wrote the best comment in my life, the simplies solution in the code is the best.

Of course sometimes I need hacks but there I put long comments. But now I know more about programming and most of code I've learned on my start now is for me obvious. So yesterday I realized that and today you are asking this question here.

And second moment was when I realized how thread "looks like". It was like: "Aha! So the code goes on, but it magically switches to new thread. Oh... it's so interesting, but how you recognize in what thread you are in". It was one of the brightest bulbs above my head lately.

+1  A: 

The day I (almost) completely stopped seeing code which I felt I couldn't significantly improve, refactor, beautify, optimize... ;)

Thomas Hansen
:) is that ever possible ?
dr. evil
+1 just because of the comment.
+6  A: 

The day I had to write code in a language I hadn't used before, and I just 'picked it up'! :-)

in my CS 111 class, all the students complained about having to learn Scheme. The professor replied "I expect any competent Computer Science student to pick up the rudiments of any language within a day" :)
The hard part of that isn't learning Scheme, it's learning functional programming.
Adam Jaskiewicz
In my experience functional programming is significantly easier than object oriented programming. I find it fairly easy to break a program down into small pieces in a functional language, but much harder in a OO language.
agreed, picking up a language in the same language is pretty straight forward. Try a paradigm shift.
+6  A: 

when I realized that there is soooo much more stuff to be learned/improved. Must be one of the days when I start reading those recommended books.

From there on, it's the "Yuck, what's with this code ? I can't believe I made this." kind of moments.

Ha - so much "yuck", too true
+3  A: 

Whenever I see something clever or hear about something interesting I think "How would I do it?" This helps me to get a perspective on other people's work.

When I was 19 I started working in a company that had a big free text database. 3-4 times each year they would copy the database from VAX-VMS to MS-DOS versions of the database system. They used to export everything as huge text files and then load the database from those. This took a couple of days each time and was a hands on process due to the fragility of the communication protocols involved.

I asked them if they had tried to just copy the database files from one operating system to the other. They just replied that VAX-VMS and MS-DOS are completely incompatible platforms and that it would never work.

I though that if I had written and ported the database system I would have kept the files the same, perhaps with the exception of byte order.

I talked them into trying, and it worked! We saved a lot of time doing it this way ever since.

I understood then that I could think like other programmers, and it has helped me understand things better.

An even more important. A 'no' should be followed up with 'have you tried?'
Lars Mæhlum
+13  A: 

When you realize that your answer to the question "Can this be done?" is always, "Yes it's possible" even when all others say "no". To prove it you spend the night making a prototype to show the next day instead of going to bed with your wife.

This is weird. :-D But still true, especially the "Can this be done?" - "Yes" part, so +1
I think this should help you to realise not only you are a good programmer also you are a fairly obsessed person :) -kidding obviously-
dr. evil
@Slough, My wife says that too! ;)
+1 for "anything is possible"
@Stefan: she just might be onto something.
Adriano Varoli Piazza
@Moranar, nah. ;)
If you think that "anything can be done" then you haven't worked with incompetent project management yet. The old saying: chose two out of three of high quality, low cost, or quick development.
San Jacinto
Haha, I love this answer. I constantly get asked "is this possible." It's the wrong thing to ask.

At some point in time during college, I was able to answer anyone (within college) who asked a question of the form "Is it possible to make an application/algorithm to do so and so?" with an answer of the form "Yes, it can be done", "No, it cannot (within acceptable time/memory)", within 30-120 seconds. The answer doesn't necessarily tell you the way to do it, but it tells whether it can be done or not.

At that time, I felt that my algorithms study was at last fruitful! :)

(Disclaimer: There is always the possibility that my answers were wrong :D )

Hosam Aly
+22  A: 

The day when It became clear to me that it doesn't matter what programming language is used to solve a problem, and that the ability to exactly describe a problem in natural language is the key to solving it. Everything else is just syntax.


When I started I wanted to write beautiful code, and have nothing to do with the user interface. Now I realized that to write code that the compiler understands is easy, its difficult to solve a complex problem in the most simplest way, in such a way that the next pair of eyes that read it can understand easily.

The day I started looking at the user interface as just as important as any other aspect of development I felt I have perhaps advanced to the next level.

Today I feel that I have had a successful day, when I solved a complex problem, and somebody looks at the code and proclaim, oh this is easy.

I hope to reach a level where I would be able to say No, that cannot be done, not because it is not possible, but because of all the other factors that goes with software engineering.

Hopefully one day I can call myself a software engineer, until then I will keep seeking to improve.

Rihan Meij
+7  A: 

When I realise that I can code for 30-60 minutes without bothering to try the code and when it runs smoothly when I press F5.

To be honest this is not a good indication of being a good programmer generally, however in my case it proved me that I'm over the trial-fail development, I don't have to press F5 to ensure that my code is working. It proves now I know what I'm doing and I don't have to do the following cycle anymore : google it, debug it , fix it...

dr. evil
Oh yes, that's so true ! I did think about it too. Wow, running first time. Good boy, treat yourself with a cookie :-)
Yes. It's was very satisfactory when I would write the whole application, compile it, run it and everything is perfect! :)
Hosam Aly
When I press F5 my editor prints "<F5>". What do I do wrong? ;-)
You assigned the wrong hotkey to your build script, obviously.
+2  A: 

The day I began to notice the (truly) bad practices of the other programmers around me. That being said, it could simply be my coding style, but there was a point I reached when it just seemed like all the coders I knew were dedicated to doing things the difficult way.

+1  A: 

wow, I hope at least some of these things will one day happen to me... I'm still pretty much in the google it, debug it, fix it stage... at least I know I got a little better when I look at my older code and think wtf, these 20 lines could actually be written in 5 to 10.

Things get interesting, if you would rewrite them in 30 lines, just because its more beautiful this way.
+1  A: 

I find improvement is an incremental thing. I'm continually finding that the stuff I had to really think about before is much easier now. Or the changes I need to make to improve/fix that old code I wrote a while ago are really obvious now.

+5  A: 

Everytime you look at previous code (ex: 2yrs ago) and say "Wow, I could have done that so much better now".

The day you can't say that, you aren't improving anymore.

+6  A: 

I get delivered a mushroom and a huge "1UP" floats up above my head.

Useless but funny. Geek +1

When my code went from being an example of how not to do something in a code review to be the example of how to do it correctly in code review.

Getting there is the challenge, and it is different for every person. For me, I think the realization was not just making something work, but thinking about what the correct implementation of making something work really meant to the team, the codebase, and the company as a whole.

+3  A: 

I remember working late one night refactoring some code in a Win32 C++ library. I was working with the Win32 SYSTEM_INFO struct like this:


I remember finding an example online (by Jeff Prosise or Jeffrey Richter, perhaps) that turned my world upside down:

    class SystemInfo : public ::SYSTEM_INFO
            SystemInfo() { ::GetSystemInfo(this); }

This allowed me to replace the original code with a single line:

    SystemInfo si;

That moment (and I still remember the conscience thought) shaped me as a developer more than any class or seminar I've ever attended and more than any book, article, or blog I've ever read.

Matt Davis

In general when advancing each stage, its when I look back at some old code of mine, and as a result of what I've learned from studying and practicing since then, I realize, "Why did I do it like this?" Basicially by keeping track of where I've been and where I am now and how I make code different.

+3  A: 

Vindication. When I've been stubbornly doing something that I knew was right and sensible, but had no external support for that conviction beyond my own arguments, then suddenly discover that among people more educated than those I'd been working with, it is known to be right and sensible.

Problem solving. When a situation has been sitting unanswered for long enough that I'm convinced the ability to answer it is rare, and I manage to sort through it well enough to both know the answer and explain it. When I manage to understand some excruciating piece of legacy tangle well enough to patch or re-implement it.

Success. I can't seem to take on simple projects, so any time I make one actually work, it's a pretty sure sign that I've learned how to do something I couldn't do before.

Changelogs. It's very supportive to be able to look back and realize that, a month ago, those problems were hard, those libraries made no sense, those techniques were so convoluted I could barely handle them even with notes. Facing new confusions constantly is like climbing mountains, sometimes it's good to look back and be surprised by the distance.

Kim Reece

One of my biggest aha moments was when I grasped the value of late binding and the relationship between higher order functions/function pointers, classes/interfaces/virtual functions, and template alias parameters (a feature unique to the D programming language where higher order functions can be resolved at compile time). All of the sudden I understood the "why" of object-oriented programming and how to write generic code that could be used in contexts that weren't specifically anticipated when the code was written.


When I understood how to use Table Views in cocoa and cocoa touch

Matt S.
Wow, Mac hides that much complexity, even in programming? You may have some surprise waiting for you later, mate...
it wasn't presented to me in a very good way
Matt S.

I had my moment earlier today.

I was tasked with making what I though was going to be a complicated change to a library in our server application. I had forgotten how exactly the relevant code was structured, since I wrote it almost 2 years ago and haven't looked at it since. I fired up the editor and I was amazed at how simple the change was going to be. It turns out that 2 years ago I had actually written the library with the assumption I might have to make a change like this eventually. It was a little extra work back then, but today it paid off.

Anyway, that's my "now I am a programmer" moment. From now on, every time I write a piece of code I'll try to think about how it might need to be changed/improved in the future and spend a little bit of extra effort in the present (while I still understand the code) to make the changes easier.

+2  A: 

For me, it was one day when I was sitting at home wishing I had an app that did XYZ, and then suddenly thought, "Wait, I could write it." And I did.

The growing realization that I could use my programming skills not just on boring business problems at work, but on everyday stuff that I wanted to do, was a game-changer.

Now, among other things, I use XNA to write games for my five-year-old son.

Yeah, "Hey, I could write that!" is definitely one of this moments.

Comming back to this anwser now, because I realized something.

You don't have "ONE" moment, you have milestones moments all long your life.

My last one was removing 90 % of the comments from a code I refactored. I just realised that good code need far less explanations that bad one, and with good variable names and loosely coupled snippets, a big part of the file becomes self explanatory.

P.S : by the way, I made this CW, I guess, that what it should be.