Noticeable increase in programming ability or understanding

Question

I am interested in knowing if at some time throughout your programming career, (when you first wrote "hello world!" to the present) you experienced a noticeable increase in your ability or understanding of the programming field.

I understand that our field is built upon layers of knowledge, but was there one that stood out?

A few examples might be a side project, something at work, book you read or a personal experience.

What was it about the experience/project that caused it?

Would you suggest other programmers to experience the same thing, and might they get the same outcome?

Answer 1

Anytime I've actually accomplished a business goal with a new framework or product.

For example, SQL, Sockets, WCF, HTML, WPF, ORM Tools, JavaScript . . . etc. With each one brings additional patterns and techniques, along with a better understanding of how computers/code work at very low levels.

Answer 2

Yeah with each project that gone wrong

Answer 3

Kudos to Jon Skeet and other MVPs.

I learnt a lot by hanging around in newsgroups specifically dotnet.lanuages.csharp.
And that is where I started to answer questions of which I thought I had an answer.

IMHO, that is the best process in some sense to learn from others & share.
I mean - I see a question, the answer of which I think I have and the expert comes in and answers it on the same line of thought. It validates that I am thinking on the right lines.

Also, podcasts/screencasts have changed the way people can learn.
Attending user group meeting and listening/talking to experts has also helped significantly.

EDIT: On a side note, I would like to hear experts on SO share their experience on what it took for them to take the leap from intermediate developers to becoming an expert.

Yes, I can suggest that to fellow developers. It is better than me & my friend, google. :)

Answer 4

For me, it was an open-source development class in college. The primary developer of an open-source C web application server came in to talk about some changes he wanted to make to the project, and the class of 6 of us poured a number of hours into it over the semester with some rough guidance from our professor.

Between the 'magic' code the primary developer had written (which lost it's magic qualities as I started to understand it), and the other developers I was working with on the project (yes, I'm looking at you Luke) who pushed at my competitive spirit, that experience is what pushed me from hacking at scripts to actually understanding and writing real, usable applications. That was the time I realized this is what I should be doing.

Answer 5

After I took Computer Architecture class. In other words when I learned Assembly :)

Answer 6

I read this book:

Design Patterns: Elements of Reusable Object-Oriented Software

Followed by this other:

Refactoring: Improving the Design of Existing Code

And finally this one:

Effective Java

I'm still amazed on how the first one totally confused me, how the second simply put everything in order in my mind and how the third make completely sense of the previous two in a practical way.

There is for me definitely a BEFORE and AFTER with these books.

Answer 7

When someone made me stop programming in c using TPU, and made me program in c#/java using a full feature IDE.

When I began doing coding for work rather than school, my projects became longer, and thus required being maintainable and readable.

When I discovered enumSets in java.

When I discovered yesterday that the c code to the java HotSpot JVM is available online. Completing the java source chain, so that I can trace a java library call through the java sources, into the JVM (HotSpot), then from the JVM into a JNI call to the linux kernel, and then trace that into the linux kernel c source.

When I got older and thus lazier (one of the three virtues).

When I figured out that taking a 10 minute break every two hours of working dramatically increased the speed with which I completed programming tasks.

Answer 8

For me it was when I got into a small team working on a fairly complex project and, the main thing, the team leader was a very competent developer - maybe not a 'superstar' but fairly close. Another point, he was a little on the micromanaging side of managing the team, but in my case it helped immensely because it increased the speed of knowledge being transferred between members.

So, I think, the best idea is to have a knowledgeable mentor who will watch your progress closely.

Answer 9

I've noticed my programming knowledge increases by breaking down and reconstructing my model. A period occurs where I feel stupid and incompetent for a while just before I gain a new understanding or perspective on the field. Typically these last a few days.

Without a doubt, the largest such jump occurred when I learned Haskell. For a time, Haskell programming and day-to-day programming took up separate areas of my brain; almost like I was learning a new musical instrument of something. But then, after I had spent about 4 months with Haskell, it started to leak into my everyday programming practice. I was incompetent for at least a month, probably more like three.

But after it settled and I regained my ability to program in imperative languages, I had a new, remarkably clearer understanding of almost everything. Because Haskell forced me to be explicit about all my inputs and outputs, I suddenly saw software engineering in crystal clear terms of the strengthening and weakening of assumptions. It has slightly improved my skill to evaluate good and bad designs, but the most noticeable effect is that I can identify a lot more cases of when two designs are "essentially the same", I.e. when we're just bikeshedding.

There was a meta-lesson in the experience too, which was incredibly valuable. That is that my brain is malleable, and I may need to train it to get to the best design. The way I picture my library being used may not actually be the best way, and playing tricks to get the interface I picture may be hurting me and my users in the long run -- I should be busy trying to understand my problem domain so I can change my picture of the interface until its usage and implementation are both obvious.

If that makes sense...

Answer 10

I remember feeling my brain expand when I first started doing OOP. It was some random little python project that my friend informed me I should use these magical things known as "Classes". It was around then that I stopped writing patently aweful code and started writing just plain bad code.

Answer 11

The most memorable time it happened was in regards to polymorphism. I was trying to track down a problem and I just hadn't grasped the difference between overriding and hiding ancestor methods (I was very, very green) ... anyhow, the reason it's memorable is that I actually hooted a little cheer for realizing how everything was working (or not working, in this case) ... sadly this was in the middle of a meeting that I wasn't paying any attention to.

Answer 12

Getting a new job.

Seriously, switching up between companies is instant-in-the-deep-end learning new technology, new languages, new process. If you get into a good company the exposure to a different culture of thinking is just such a boost to your own skills. It feels really Darwinian, mutating and cross-pollinating. Even if you get into a bad company you can teach yourself a lot by seeing what makes them a bad company and striking out to make things better. Being a contractor is one good way to get through a lot of companies without destroying your CV but you need to have some experience to be a contractor at all really.

Personally I feel the only cardinal sin in programming is stagnation, and staying at one company for 20 years is one form of that.

Answer 13

To me it was when I first read about design patterns. I was looking for some good solutions to the problems I was facing in a project. Studying on patterns led me to read on good design principles (SOLID etc), using ORMs, best practices, code smells etc. Still learning...

Answer 14

Test driven development was a big one for me.

Use of classes to encapsulate simple types and their validation made a huge difference in how I saw the world. All of a sudden, SQL injection attacks look painfully avoidable, even without stored procedures.

The other thing (which was part of the TDD journey) was inverting how I developed interfaces. Instead of having my classes write to someone else's API, I instead defined the API I really wished existed, and wrote to that. Once I had that, I figured out how to implement it to talk to the real API. Yes, it's a simple case of the Adapter pattern, but it's amazing exactly how much that improves your code.

The last thing that helped me was a deliberate emphasis on using void methods only. That really helped get me out of the procedural rut, and really start thinking in terms of objects. Combined with lots of network coding experience, it helped me really lock down how to code things in a way that can be isolated and be composable.

Having done those, the Design Patterns book made about 100% more sense. Classes changed from things that "did actions" to things that transformed data. Programs started looking more like data flow charts and less like procedures.

Answer 15

Learning a framework.

The first time I actually had to understand other peoples code and perspectives, not just my own. That opened up a whole new world for me.

Answer 16

I still remember the day when someone explained how critical sections worked for multi-threaded programming. It was one of those conversations where I looked incredibly dense for 5-10 minutes but then it suddenly dawned on me how and why it worked. It didn't immediately increase my skill but it really changed my understanding of how programs ran for some reason.

Answer 17

Working with a good mentor. My quick and significant jumps in abilities have almost always been through working with someone who spent a fair amount of time teaching me something significant. Examples are database design, object oriented programming, software methodologies, etc.

Answer 18

When reading old code that I have written for at least year ago. Then I notice that I have learned a lot since the time of writing code: better class design, better overal application architecture, better readable code, more usage of patterns, etc ... That are the moments that I see that I continously learn and improving my software development skills.

Answer 19

My first time was when I wrote something which looped back on itself. Back in the days of Netscape 4, it had a fairly twisted DOM, which meant you could not perform ID looksup without iterating into each layer (basicly, a positioned DIV souped up to be ready for "DHTML"), since ID lookup was local to each layer (each layer contained a "document").

I don't recall the code anymore, but I just couldn't make it work (I'd been "programming" HTML/Javascript for a few months at this point), so I walked over to one of the "real" programmers (doing backend), and I asked how to tackle this, and he showed me how I should view the NS4 DOM as a tree, and how I could then walk it, and locate the correct ID, using recursion.

Was probably one of first, and biggest "oh wow" moments, esp. since the resulting code was so simple.

Answer 20

I think the biggest turning point for me was when I decided to take on a freelancing career. Just prior to that I had a manager who used to say that design patterns / best practices are just unimportant additions (sic!). Because now I am my own boss (mostly :) ), I can make decisions on how to approach a particular problem, what to learn and from whom. I started reading blogs from the best (subjective) people in this industry, participating in some communities, bought a couple of books (and still haven't finished reading them) recommended by others. I think that with each new project I'm getting better and better and learning from others is the key. I didn't have that opportunity (with some minor exceptions) before.

Answer 21

Understanding the recursion idea, embodied in Towers of Hanoi:

procedure Hanoi(n: integer; source, dest, by: char);
Begin
    if (n=1) then
        writeln('Move the plate from ', source, ' to ', dest)
    else begin
       Hanoi(n-1, source, by, dest);
       writeln('Move the plate from ', source, ' to ', dest);
       Hanoi(n-1, by, dest, source);
    end;
End;

In my case, the language of illumination happened to be Pascal, like the Wikipedia example.

Answer 22

Deciding to try to understand how things work internally, which is made possible in an open source world.

Before that I generally used frameworks or libraries as black boxes. This can be fine for your first steps. But if you are not willing to invest in learning the internals you will never become an expert for anything. So you have to make the transition from "I don't know" to "I don't know yet".

Of course it is not possible to understand every detail in every situation. But as soon as I am surprised by some behavior I try to get the source code and understand what I observe.

Answer 23

The big step-changes as I recall them

1. A first formal Software engineering course

2. Event-driven programming (a bigger conceptual leap than OO, IMHO)

3. Moving to a new job with a team lead who was actually prepared to mentor and had both an academic and broad-ranging commercial development background

4. Deciding to learn other languages outside the 'C' family (dynamic, functional, ...)

Answer 24

For me, it was on either my third or fourth reading of Modern C++ Design, when I finally grokked what was being described to me. It was a little like discovering an extra colour: suddenly, C++ wasn't just C With Classes any more.

Also, it gave me something of a hunger for technical books, so I ended up with a bunch more of those as well (and actually read them).

Answer 25

I had been developing (or so I thought) for a long time when I happened to read The C++ Programming Language by Bjarne Stroustrup. Not only is it an excellent resource to learn C++, but it also contains general (but invaluable) ideas about software developement, and even patterns (like RAII, so simple and yet powerful that it managed to make its to way to the .NET world).

Software development has since been a very different (and even more interesting) field to me :

• on the one hand, I have been (almost instantly) cut off from most of my fellow coworkers (who were not interested in learning things in general).
• on the other hand, it gave me the basics to grasp a vast amount of knowledge by myself (OOP, patterns, practices, new languages [Java, C#]...).

Answer 26

I've had a few leaps over the years:

1. Learning about types. Initially I programmed in BASIC, Commodore 64 and Watcom dialects to be more specific, and we just had numbers and strings. Being able to create my own type is a rather powerful thing to learn.

2. Software Development Lifecycle and Waterfall methodology. When I was programming in BASIC or Pascal there wasn't a big formal method used and the coding was rather confined. Given a simple sequence for developing software helped add some formality as well as enhanced my testing as this was also part of that course. Learning version control was also a part of this.

3. Algorithm heuristics. I remember having a course in university about, "Algorithm Design and Analysis" that summed these up for me in a way that clicked better than my previous courses that covered similar material, e.g. Divide and conquer, dynamic programming, create a new abstract data type, or being greedy are a few of the big ones. The big white Algorithms book was the textbook of the course.

4. The magic of short code. I'm not sure how else to describe this other than to say that I remember someone that I interviewed with on my first job tell me that most functions will only have about 10 lines of code. I find it amazing that it has turned out to be so true as you generally don't want large functions doing a lot of things.

5. Design Patterns. While I had seen these in a previous job, I didn't know what the name was and that there were a lot of these. Adding this to what I use to create code made me a better developer to think of, "Here a strategy pattern makes sense," or "Adapter seems like a good fit here," kind of thing.

6. Pair programming/TDD. A while back, there were a couple of consultants brought in to help the team I'm on get used to various practices like pair programming, writing tests, using Continuous Integration, and other practices that have been really useful in making me a better developer.

Answer 27

when I had to make a virus detector in assembly code when I was 16 ... and before that writing a several scheduling algorithms in one sitting for an Operating Systems (subject) machine problem ...