What is the single most effective thing you did to improve your programming skills?

Question

Looking back at my career and life as a programmer, there were plenty of different ways I improved my programming skills - reading code, writing code, reading books, listening to podcasts, watching screencasts and more.

My question is: What is the most effective thing you have done that improved your programming skills? What would you recommend to others that want to improve?

I do expect varied answers here and no single "one size fits all" answer - I would like to know what worked for different people.

Answer 1

In no specific order...

• Working with people far smarter than myself

• Always listening to what others have to say, regardless if they're junior, intermediate, senior or guru. job title doesn't mean anything.

• Learning other frameworks/languages, and seeing how they do things, and compare that to stuff that I already know

• Reading about patterns, best practices, and then examining my old stuff and applying those patterns where necessary

• Pair programming

• Disagreeing with everything Joel says. ;)

Answer 2

Deciding TO be a 'Jack-of-all-Trades'

Fairly early in my career, I was an expert with a particular database and programming language. Unfortunately, that particular database lost the 'database wars', and I discovered that my career options were ... limited. After that I consciously decided that I would never let myself become boxed in like that again. So I studied everything I could get my hands on: Windows, Unix, C, C++, Java, C#, Perl, Python, Access, SQL Server, Oracle, Informix, MySQL, etc. Whatever tools and technologies are new or unusual, I became the 'go-to-guy' -- "Ask Craig, if he doesn't know it, he'll learn it." As a result I've worked on all sorts of projects, from embedded systems for environmental telemetry to command and control systems for missile defense.

The only problem I've ever had is with companies that insist on pidgeon-holing me into a specialty, when my specialty is being a generalist. [EDIT: Also known as a Polymath or Renaissance Man or multi-specialist.]

Something to keep in mind ... what's the half-life of knowledge in high tech? It tracks with Moore's Law: half of everything you know will be obsolete in 18-24 months. An expert who chooses the wrong discipline can easily be undermined by the press of technology; a generalist only has to add some more skills and remember the lessons of the past in applying those skills.

Answer 3

I always thought of my self as a pretty hot-shot programmer. Then a new guy, call him Aaron, was hired into our team. Aaron was obviously much better than me in most areas. He was younger than me, too. He made me realize I hadn't really improved much in the past years. I was an ad-hoc hacker, and a mediocre one at that.

This alerted me to consciously try to improve myself and especially the quality of code I write.

Aaron lead me to learn a lot of things. He taught me how most of the code I write will have to be maintained and extended for at least several years, so I should write the code with that in mind. I should write automatic tests for my code. Aaron was always talking about how I should never stop at the first working version, but refactor and refine until the code is elegant. I've discovered that the languages and tools I was using had a lot of room for improvement.

The most important thing I learned from Aaron was to never stop learning.

After a couple of years, Aaron left the company. I felt empty. The past years with him had lifted me to whole new levels of skill, and I realized I was now much better than the rest of the team. They were still writing bad code, and doing the same mistakes as before. I tried to teach them, but they had no interest to learn. In fact, they were annoyed that someone would be so arrogant to tell them what mistakes they were doing.

So, a few months later, I left the company as well. I moved to a smaller company with a very talented team. Everyone there wanted to learn more, and I loved it.

I'm glad I met Aaron. Without him, I'd probably still be working at the old company with the old gang, going nowhere, and thinking too much of myself.

Answer 4

Two things:

1. Read code written by different people.
2. Write documentation for code written by other people.

Writing code is extremely easy; every other person I know can do that. But reading someone else's code and figuring out what it does was a whole new world to me.

Answer 5

Hit the gym regularly.

Seriously, my brain works a whole lot better when I'm in shape. Problems become easier and less overwhelming, goofing off is much less of a temptation, and working through things step-by-step doesn't seem like such an arduous task.

Answer 6

Programming. Working on interesting projects. There is NOTHING like getting in and working on stuff. Especially under pressure. I always tell anyone who asks me how to program - just find a cool project (even if you have to make it up) and work on it.

Answer 7

Took a part-time job tutoring CS students at my university. It really forces you to understand something at a completely different level when you have to explain it to someone else.

Answer 8

1. I'm a big fan of the "learn one programming language every year" system. One year gives you enough time to get past the "okay, I know the syntax, so now I know the language" bias, and forces you to go a little farther and understand what's beneficial in that language, and program in a style native to that language (By which I mean, you don't end up writing java applications using Ruby syntax). Each language will change the way you think about programming- I knew how to use recursion, but thinking in recursion didn't happen until I took a class on prolog (I imagine a functional language like ML would have the same effect).

2. Start a Pet project. My personal equation for a good pet project is, something you have experience with + something you don't = app you would find useful. For instance, Migratr (my own caffeinated-weekend-turned-ongoing project) started out as "I know c#, but I've never coded against a web API. And I want to move all my photos to Zooomr". It could just as easily have been "I've coded against web API's before, but I don't know C#"

Publishing your pet project is an amazing educational experience in itself. Suddenly all the things practically nobody teaches but everybody's supposed to know (for me it was setting up your own testing system, getting the most out of version control systems, how to pace yourself when nobody else is setting your deadlines, how to interact with your users and how to know when to say "no" to feature requests), all that stuff bubbles to the surface and forces you to self-educate on a level you weren't before- at least not by idly reading flamewars on dzone about the pros/cons of the "foo" vs "bar" way of doing things.

Doing these two things covers both ends of the spectrum. Learning a new language will make you a better coder. The pet project will make you a better developer:P

Answer 9

Taught myself assembly. Did it on an old 6502 chip when I was 13? 14? Too long ago. But I can't think of anything that will improve your development more than getting down to the bit level.

Learning assembly gives you insight into the way computers 'think' on a fundamentally lower level, and the elegance at this level is surprising... there are no wasted motions, no 'disposing' of data. Developing at this level will teach you efficiency and hone your critical thinking and logic skills. It will also cure you of any sloppy habits you have fairly quickly!

The 65xx chip had three registers (the accumulator, X, and Y) and no machine level instructions for multiply or divide. I remember coding a routine to calculate battle damage, looking through the book, and suddenly realizing that I would have to write my own math library. Spent a couple of weeks scribbling 1's and 0's all over my notebook, trying to figure out what 'divide' and 'decimal places' really meant.

I've studied C++, pascal, .NET, many others since then... but none of them have taught me as much, intrigued me as much, or left me with the sense of 'wow' that assembly on my old commodore did.

Answer 10

Looking back at old things I wrote and realizing just how bad they were.

Answer 11

Read

• books, not just websites
• for self-improvement, not just for the latest project
• about improving your trade, not just about the latest technology
• read code, not just you are working on.

Just develop the appetite for reading.

Answer 12

Programming.

Seriously, there are books, there are coding katas, there are sites like this, but I believe that the best way to improve as a developer is to work on real project, with real fickle customers with real, ever-changing requirements with real engineering problems. There's no substitute for experience.

Answer 13

I think the most important thing you can do is make a conscious effort to improve. There's no single silver bullet, you have to keep looking for new sources of information, new experiences, and more practice.

And the second most important thing, think about what you're doing, why you're doing it, and how you can do it better. Same thing with previous projects. Look back at what you've done, and how you might do it differently now. Think about what could have been done better, or where you could still improve on it.

I see two great examples of this at work every day. I have one coworker who loves to learn, and wants to be the best developer he can. He's uses any downtime to read blogs, read books, discuss programming techniques, and ask tons of questions. He's also very noticeably improved in just the past year. Another coworker does his job, and does it fairly well. But that's all he does. He sticks with what he knows, doesn't make much effort to improve, doesn't work on any projects outside of his existing ones, and after 4 years, he has the exact same skill set and programming ability that he had when I met him.

Answer 14

Many people have suggested writing code. I'd have to say that reading other people's code is much more beneficial.

Answer 15

Pair-programmed with very diverse and opinionated people

Answer 16

The basic things that helped me as a programmer:

• Learned Touch Typing.
• Learned to overcome shyness and ask questions.

Typing for a programmer is essential. Everyone has had a "programmer" coworker who typed using exactly two fingers and had to look at the keyboard for everything. Not fun. Learning to touch type give a huge boost to your productivity as a programmer.

And if you don't ask, no one is gonna tell you.

Answer 17

Contributing to/participating in open-source projects was by far the biggest thing for me.

Answer 18

You can read all the books, code, and open source projects you like, but you need to understand the end-user aspect of software development. You need to step out of the echo chamber. So I'll address a couple non-technical points that will help your technical career.

1. Step away from the keyboard and interact with the end-user and see, through their eyes, how they use the software. End users are typically not technical, so they see software as a magical piece of work, while you see software as a logical set of steps. The two worlds are completely different. So what seems easy and logical to you may seem cryptic and intimidating to others.

2. Test, test, test. A lot of the software I've seen in large corporations use test cases. Hell, they use JUnit, xUnit, and all the other unit testing languages out there. But the problem I've seen is that most programmers never see what their software looks like in Production. Learn how users (or systems, if these are batch jobs) interact with your application, library, or interface to find out what kind of abhorrent information they throw at it. This will help you generate good test cases and stop assuming your program will always be fed the correct set of data.

Answer 19

Writing code and lots of it.

Answer 20

Learning regular expressions .

Answer 21

Competing in TopCoder Algorithm contests.

Answer 22

Go all out: create your own project, your milestones, your resources, dependencies, requirements, and test plan. It will force you not only to improve your programming skills to operate within specific parameters, but will also serve to highlight exactly where you most need to improve. Make regular updates about your progress, whether through a blog or more formal project updates, so that you can see exactly where you've been and where you hope to go.

Answer 23

Quit my last job.

Answer 24

I think constantly questioning what you are doing is the biggest thing. Never think that your code is perfect, always strive to improve it.

It seems like I've had 2 or 3 times when I thought my code was perfect, then realized I had a long way to go.

I guess the biggest thing was when I started seeing my code itself as consumed by other programmers and not a machine. It's easy to write code your machine can process, but it's tough writing DRY, understandable code.

And I don't mean just understanding "What does this line do", I mean making it trivial to figure out "How does this class fit in with all the other classes" while making the classes interface so well-formed that it's virtually impossible to misuse it.

Answer 25

They say that 70% of good code is error checking and handling. When I started programming that way, my code got a lot better. Thinking about what can go wrong and then handling it right away has made a huge difference. It feels like doing all that checking is just getting in the way of getting the code up and running, but it shortens the time from start to finish by a factor of 2 to 4.

Just who are these people "they" and where do "they" live?

Answer 26

Constantly learn and practice what you learn.

By means of:

1. Personal Projects: Ever since I started programming I have been doing personal projects. Ranging from little games, image processing, steganography, implementing file type specifications, implementing various protocols from scratch, or implementing various programs over time.

2. Reading books: I decided to read and follow through various books in my spare time. There are a lot of well written books by experts just sitting around waiting to be read. The depth you can get from a book is unmatched by for example reading various forum posts.

Answer 27

My coding skill improved a lot when I started wondering before implementing something how am I going to document this thing.

"Thing" here should have all the possible granularity. From the method to the whole product. For instance at the method level it prevents adding a method in the API that doesn't fit, or is unclear, before actually writing it. And if I really need to implement a method I cannot document (easily), it's a sign there is a design problem somewhere...

Automatically, the attitude "if I can't explain it, I don't write it" filters out bad code and conversely once I know how to document correctly a thing, it becomes simpler and cleaner to implement.

Answer 28

This is usually my chronological order of learning any new technology:

1. Regularly read good blogs (Atwood, Martin Fowler, etc.), Keep up-to-date with technology news, Follow stuff about interesting new technology. These steps will let me decide if I find anything interesting to further explore.

2. Read the right book or any other resource to learn for your level (e.g. for beginners if you want to learn design patterns, I would suggest 'Head First Design Patterns'). I have also specific preferences for books.

3. Roll out a toy project or two using the thing I learned. I don't worry about the usefulness of the project. My intention is just to exploit my learning. (e.g. A calculator project for OOP would be fine)

4. I would see if I could use the stuff at work. (e.g. Though we don't use subversion at work, I use it as my local repository, I used Ruby for a task which would otherwise be too monotonous, and time consuming)

5. This is the best part which I think most people miss out. Knowledge sharing sessions.Give a session or two to fellow team members for example. I believe teaching is one of the best ways to really learn the technology. I guarantee your level of understanding of the technology will become multi-fold, whether you audience gets it or not. :-)

Answer 29

Hack on some open source project for a few months; the larger the better. When you're interacting with some highly opinionated, geographically diverse people who don't know you, you can't help but learn from your mistakes far faster - I think it's a certain embarassment factor. Plus, if you identify one or two really smart people, then you can glean valuable insight, if not pure knowledge, from them.

Answer 30

Unit testing and TDD.

Once I started unit testing I was consistently producing virtually bug-free (yes, I know, there's no such thing) code. And once I started TDD I was able to reduce the time it took to write both the code and the tests.

Answer 31

I don't know about the single best thing, but:

• trying to solve other people's problems

has been very helpful. Somehow it's very motivating to see an opportunity to fix someone else's problem. I end up looking up details not only in areas I'm familiar with, but even in areas I know nothing about, in order to answer people's questions.

This is true on SO, or on domain-specific mailing lists, or among my colleagues at work.

In the process, I

• learn things I didn't know before,
• refresh details I might otherwise forget,
• gain skills in diagnosing problems,
• gain understanding of what kinds of concepts are frequently unknown or misunderstood in my field

And sometimes it's just a good break from my own problems. :-)

Answer 32

Be open minded and work with other people more experienced and smart than you.

I learned lot of things in college, reading books, magazines, blogs, attending conferences but nothing was even close to learn with peers who knows what I need to know.

Working with smart fellows teach real world solutions to you.

You can learn a lot reading their code, watching their practices and listening their opinions and stories.

Be careful with amateurs posing like professionals. Working with them will give you the opposite, your skills will down.

Answer 33

Walk, Talk, Eat and Drink.

Walk away from the computer away from my comfort zone. Go talk to a real person about what we need to make happen. Eat lunch with the team. Drink after work.

Programming, I've found, is an extremely social communication-intensive activity. The coding occupation is dominated by people like myself who would much rather not be social. I'd rather figure things out myself rather than ask a question. I'd rather grumble about the inherent superiority of my design than collaborate. I'd rather be passive aggressive than confront someone.

The agile approaches recommend a lot of face time. I become acutely aware of my anti-social tactics. My effectiveness as a programmer went up by leaps and bounds. And believe it or not, my code got better too.

Better requirements from better questions. Improved designs from more input. Beer helped relax me.

Answer 34

Honestly, I'm noticing that answering questions on SO is making me better. Of course, it's a slow process but I have noticed that in the effort to address other people's questions, I have learned intricacies that I wouldn't normally have explored while solving my own problems.

Answer 35

Deciding NOT to be a 'Jack-of-all-Trades'

If you're serious about programming as a long term career, understand that you'll likely never be hired because of your versatility, but rather your expertise. To make an analogy, the least popular character in Everquest (at least when I played) was the Bard, who was good at nearly every skill but wasn't excellent at any of them. Pick a specialty and devote your time and energy at mastering fewer technologies rather than being so-so at many.

Answer 36

Read. Code. Read code.

Answer 37

Pair programming with other folk by far raised my quality, broadened my horizons, and helped me understand the practical issues of day to day development. Couple of big points:

• it doesn't matter how elegant your code is - if someone else can't understand it you're already sunk.
• be ready to divorce your code in a heartbeat. The romance is in the "doing" not the "outcome".

In response to Thorbjørn's question about pros/cons of pair programming. I feel I've been lucky enough to sit next to devs with quite different backgrounds (languages, experiences etc.)

• Usually starting with a reasonable but often incomplete spec, we'd work through the problem and decompose it. While often there is complete consensus on approaching the problem - I learned most where our opinions deviated. (e.g. the sharing of negative experience of a particular approach)
• Before coding we'd often spend much time at the whiteboard diagramming and walking how we thought the components would play out too. Having someone else validate your thoughts or poke holes in your supposedly watertight solution is quite humbling for the first time, but makes you better in the longterm.
• Sometimes the hardest thing to do was compromise on the "right approach". Sometimes we'd step beyond pseudocode into class designer to role play what the code would look like. Often it became clear from doing this which approach was most natural. Much of it came down to a level of trust that we had in each other to do the right thing.
• Worst aspect of pair programming was resisting the urge to grab the keyboard and just do it yourself because it was clear in your head how to do it. Giving space to let people's thoughts playout was sometimes where I learned the most.

In general though sometimes frustrating, it is also sometimes very rewarding. I feel I get as much out of pair programming as I give.

Answer 38

Working with other great developers has taught me a lot over the years, that and actually doing stuff just for the hell of it from time to time.

For instance, I wanted to learn how to draw charts in GD so i wrote a simple biorhythm generator just for the fun of it. Not rocket science and I don't really believe in the pseudo-science behind it, but it was a good chance to learn what I wanted to do.

Answer 39

Going to a good university.

Answer 40

Tech support. If I was the Programmer King of the World, I would decree that no one could be a programmer without first putting in 2 years as front line, customer facing tech support. I dont mean "flip-book" & "read answers from a script" tech support like you'd get from a telco, but rather the kind where you have to actually research, test, and experiment to duplicate problems, report on them, interact with the customer, and if possible, find resolutions.

I find that when programmers go that route, they have a better feel for the 'ecosystem' of their products, and they develop a better feel for what the common weak points and problem areas are. In the end that lets them create more reliable products.

Answer 41

Top thing: worked with other smart people and learned

Others, in no particular order:

• active reading (books, blogs, nerd sites)
• trying out new development concepts/methods
• learned everything regex

Still want to try: contributing to an open source project.

Answer 42

stopped reading books and blogs and sat down and actually coded something

Answer 43

I definitely agree that programmers and writers have the same mantra. For writers, it is simply to write, there is no way around it. For programmers it is to well.. program. With that said I think there are a few things that all programmers should do.

Most of these areas are really about stripping away the mystery and getting you to think about what is really happening below the level you are operating at.

In no particular order:

Learn several languages Learn LISP/Scheme, asm language of your choice, C/C++, SmallTalk

Get yourself exposed to different programming languages for the same reasons it is worth learning other spoken languages. These expose you to totally different modes of thought and will get you to look at problems in an entirely new light.

Write a language.
This will get you to think about languages at a deeper level. Just get something out and working before you try and create the next big language.

Write a multi-threaded OS Writing an OS will expose you directly to hardware, memory management, threading, protected memory, and get you to understand the machine. Be prepared for immense frustration, and deep satisfaction the first time you get a machine to boot to a prompt. :)

Write a game I'm a bit biased on this one. Games are immensely practical applications that force you to not only dig into numerous computer science and code construction problems, but they force you to be practical. For real fun, try writing to an older platform such as the PS1 or even the Atari 2600 (Stella manuals can be found online). These are "tricky" architectures that will force you to really understand them before creating anything interesting.

There are clearly many other areas to work on and things to do in order to improve yourself as a programmer. Some will be very craft related, and others are going to push your boundaries of knowledge. The above list is a great example of projects to set out to accomplish. You will be forced to grow as a programmer when working on them, and they will also set your resume apart for the future.

Answer 44

The most effective thing I did to improve my programming skills was to read the book Code Complete by Steve McConnell. I had been programming for many years without paying a lot of attention to the craft of programming. Reading Code Complete was a real eye-opener.

Here there were whole chapters discussing the naming of variables, the lay-out of if-statements, and how to write good commnets. It was really nice to see how much there is to learn about these seemingly simple things.

I got the first edition about ten years ago, before there were any blogs. But the book contained a good reading-list at the end. That got me reading classics like The Mythical Man-Month and Peopleware. These days of course, you need to read blogs as well as books.

I would also recommend working with testing and support for a while, even if your main thing is development. It really helps to broaden your view, and in the case of large systems (in my case telephone exchanges) gives you a good understanding of the important areas of the working system.

Answer 45

Sleep!

Don't underestimate this!

Without a certain amount of sleep my programming skills vanish like a sandcastle in the waves. If your goal is a constant output of good code, do not work when you're tired, and don't try to fight sleepiness off using coffee, coke, candy or cocaine!

Answer 46

Wrote Smalltalk Best Practice Patterns and the Java version, Implementation Patterns. Thinking carefully about my habits lets me program more quickly and confidently and identify situations where the cookbook doesn't apply. I'm doing something similar with design right now and I find it really helps my effectiveness--productivity and quality.

Answer 47

What I did is this: I looked up how to improve my skills and found this answer on StackOverflow ;)

It came with a good value-for-money and information-per-square-pixel ratio.

Answer 48

After 30+ years of business programming it's hard to pick one event.

But I definitely have to go with one concept:

The most important target audience for code is the maintenance programmer.

Can I tell one story? (Tough. I'm going to anyway.)

Many years ago, back in the days when a minute of CPU time cost about as much as an hour of programmer time (nowadays the ratio is more like a MONTH of processor-core time per hour of programmer time), I was working in a batch-Cobol shop and was asked to help with a maintance problem outside the projects I usually worked on.

The program in question, right in the middle of its work, did a complex calculation about electrical power management.

My relevant background for the task:
* I speak fluent, native (American) English. Amy, the programmer attempting to do the maintenance, only sort of spoke English.
* In college, I had dropped an electrical-engineering course.
* I had more programming experience in more languages, and a bit of a reputation for solving code puzzles.

So I looked at this mass of Cobol code that Amy had identified as the area where the bug apparently existed. Yep, it was the power-management calculation. After ten years, after the people who created it were gone, the client had realized it was calculating incorrectly.

Most of the program was unusually clear and comprehensible for Cobol. Excellent style, reasonably good technique. Nice meaningful variable names, but not absurdly long ones.

Then there was this part - about eighty lines. Amy could not make heads or tails of it.

Neither could I, for a couple days. Even after I noticed that the first third of the block was just moving data from variables with names like (making them up twenty years after the fact) Killowatt-Hours-Per-Day to other variables with Fortran-compliant names like FFGFXKCD (not to be confused with FFGFKXCD), and the last third was moving the data back.

I suggest:
1) Don't do this sort of calculation in Cobol.
2) If you're going to do it in Cobol, have a Cobol programmer write it. Not a Fortran programmer who's never seen Cobol before.
3) A programmer who understands the subject matter and has tried to maintain a program before, would be a nice touch too. I think the Fortran programmer was missing at least one of those attributes, but couldn't determine which one - possibly because I didn't understand the subject matter.

But after about four days I figured out what the formula actually being calculated was, identified a part that looked wrong to me (and in fact was wrong), and had Amy send it off to the client for feedback. Got the correct formula back a few days later, and replaced those eighty lines of cross-species monstrosity with ten lines of pure Cobol that Amy understood.

(I have no doubt that in a Fortran program written by a competent Fortran programmer with a reasonable understanding of the subject matter - the situation that really should have been in place, at that time, for this project - it would have been one or two lines.)

Answer 49

Ask lots of dumb questions on Stack Overflow. Seriously.

Answer 50

I decided to 'step in' instead of 'step over'. That made the difference. :)

Answer 51

1) Teach

2) contribute to mass open-source products

Answer 52

Joining, posting and participating in stackoverflow was extremely significant in broadening my horizons, seeing what else was out there, how best to code things, getting advice. Also, by giving back to the community (by answering questions), it forces me to delve deeper into the questions I'm answering.

Answer 53

Try your hand at writing a compiler.

When you get right down to it it's not really all that difficult, but the exercise gives you tremendous insight into how a language turns fancy, pretty, structured code into processor instructions.

Then again, simply taking some time to pay attention to what your favorite compiler produces can be quite enlightening too.

Answer 54

Stop! Hammer time... Rather than adding a lot more code, improve your code and thus add less. :-)

Rather than to keep writing bad code you could stop and see how your code can be improved, some ideas:

• Documentation
• OOP, Functional programming, ...
• Reuse.
• Readability.
• Small procedures by extracting methods.
• Testing.

Answer 55

Engage on a open source project.

Answer 56

Working in a small company

In big structures, you're (often) cornered in such a small angle of the big picture that it is quite difficult to improve on the whole.

If you work in a small structure, with a little team (but obviously a quality team), you can learn not only from others, but also just because you can set up things.

On the past 5 years, we've set up our scm (svn), our project management (scrum), our CI server (Cruise Control and PHPUnit) - in a big structure all of that would be already in place and you'd just learn of to use it - in a small structure you learn how to set it up, you learn why you need it (and what you gain from it), and you're free to improve. It needs more willing probably, but it's much more rewarding (imho) !

Answer 57

So far the single most effective thing was probably the choice to learn Python (granted I'm just un petit enfant in the programming world with < 1 year professionally and ~10 years personally).

Most people will read this and "Say what??" but I think the choice to learn Python was the root cause of expanding my knowledge base about programming. When I first picked up Python, I was in my freshman year in college (I'm a Junior now...) and was learning C++. When I started learning Python on the side it required a shift in thinking to understand how to do it "the Python way". Because "There should be one-- and preferably only one --obvious way to do it.", I needed to develop the ability to think about things in a different way - wait what? everything is an object? We're really just storing references to those? Ohhhh, and when we add two string we're actually just referencing the object that is the sum of two strings. Ahhh, and that's why lists behave so "weird". That makes sense.

These mental acrobatics helped me to understand abstraction and object orientation a lot better. I think learning assembly may have been even easier because I had already spent so much time learning python (and pointers in C++). Python has also given me a reference to gauge other programming languages with.

So far, almost all other programming languages have a subset of features that Python provides. When I learned Java it was only the syntax - I already knew all the other "ideas" that Java presented. So far the only language I've come across that I went "Holy cow, you can do that???" or "Wait, you do what now???" has been Lisp. Attempting to learn Lisp has made my brain stretch and twist and do somersaults and do really crazy stuff. But if I didn't already know Python, I don't think I would have wanted to learn anything better. I think I would have still been programming C++ thinking it was cool to program, but not that great.

So yes, the decision to learn Python was probably one of, if not the most fundamental choice I made to improve my qualities as a programmer.

Answer 58

Decouple the money from the solution. As soon as you realise that the money you earn is not dependant on the code you write you realise that the people you work with and for depend on you being top of your game and trust you.

This whole process of trying to be the best that you can be for a client who depends on you for the best possible solution enforces you to become a better programmer.

Yes at the end of the day its all about the money, but there comes a time when you can demand more money for the skills you bring to the table. However you should always make a decision of whether your doing it for the money or are your earning money for something you love doing and get a kick out of it.

Never loose sight of the business need and what your there for. Customer is king.

Answer 59

here is mine.. writing code of open-source projects over and over.. just get any source code and rewrite it on paper till you actually understand it.... it usually works

Answer 60

Many great answers here. However, one of the most effective things for me personally was to join Stack Overflow. There are many people here that are smarter then me, and I learn a lot from their very thorough questions and answers

Answer 61

SQL - it changes your view of the world to data-centric rather than process-centric.

Answer 62

The best thing I did was start my own side business with some partners.

Since my personal time & money was on the line, it forced me to re-evaluate & analyze everything I used in development & determine how to best utilize them for this project.

• frameworks
• source control hosting
• unit
• testing development
• methodologies
• development tools
• third party controls

Answer 63

Learn C and C++

Answer 64

Answer questions on StackOverflow, of course!

Answer 65

Learn Regex, as early as possible. Every tiny little string problem becomes a no-brainer later.

Answer 66

Writing code, I tend to read too many books,it's good to know the theory but the practice is really where you can become a master.

Answer 67

Solve hard problems with code.

In my own experience it has been the code that I didn't know how to write that taught me the most.

If you seek out hard problems you will learn to learn to work hard; learn to do your own research; learn the best language for the job; learn to use development tools (IDE/debugger, source control); meet people who are like minded, and above all else become inspired.

When you are inspired there is nothing that you cannot learn or do.

Answer 68

1. Try and make errors..
2. learn how to search.
3. try to solve other developers problems.
4. read and try to understand the concepts not the details.

Answer 69

Writing code on a paper or a whiteboard as against using the compiler. Apart from the syntax, I could realize so many nitty-grittys which the compiler\IDE does for us.

Answer 70

Appreciate that there is no magic. There's a tendency to shy away from reading or understanding a piece of very complicated and magical looking code, with the feeling that it should be left to the masters and gurus. Any code written by a human can be parsed and understood with enough time and patience.

You'll never get better if you stay in your comfort zone.

Answer 71

Write code-generation software. Create a simple database with a few related tables. Then write a web interface to interact with it using whatever tools you can find. Then, using the same language, write software that will write what you have just written.

You'll see that a well designed relational database, with well thought out field definitions (type, length, nullable, default, etc), contains all the information your code generation software will need. Write a code generator to generate your data abstraction layer. Then write one to create a web interface (list view, add form, edit form, etc).

The more you write, the further you realize you can go. It gets addictive and you get better...

Answer 72

I asked really smart colleagues "stupid" questions I was embarrassed to ask. As Einstein said, "If you can't explain it simply, you don't know it well enough." I have also investigated the codebase at work on my own time. You have centuries of programming experience at your fingertips if you work for a decent sized programming outfit.

Answer 73

1) Learn an assembly language (any chip, just learn it well) -- it will make all of your other code much better.

2) Learn how to find the documentation and actually read it. I am pretty convinced that the most programmers refuse to read the instructions that are available for their tools.

Answer 74

What I am following,

1. Write Code for every single concept you learn.
2. Buy books and read on the subject.
3. Talk with the experts.
4. Never lose hunger to become an expert.

Pbn

Answer 75

What about projecteuler? I've started to solve the first few problem, will see how efficient it is..

Answer 76

Documenting my code. At first I didn't bother because it was for school projects that no one would ever need to look at again. Then I realized that even if other people didn't need to read it, I would need to years down the line, long after I had forgotten why I had made the choices I did.

Working through the same hard problem twice is a pretty good motivator to document future work completely.

Answer 77

Trying to build a game engine from scratch, just for fun. It touches on so many different aspects of programming that I had to learn all sorts of new things in order to get various parts of it to work.

Answer 78

I got an internship in IT.

Still in HS here. :)

Answer 79

Participating in programming contests

I didn't specifically do this to improve programming skills. I just realized that it seriously affected them.

Contests made me learn about—and actually implement—a lot of standard algorithms and operations with common data structures. They taught me to find "corner cases", and to write programs in such a way that these cases do not make my code look like a mess. They taught me to find an effective algorithm for many problems, and, most importantly, not to be afraid of difficulties when I'm to write something non-standard.

---

By programming contests I mean contests where you're to write small programs that solve simplified problems. A participant (or a team) is given limited amount of time and a small problem set. The goal is to implement the problems in such a way that they pass all the sets prepared by jury. Usually requirements (time and memory limit) force you to implement effective algorithms.

Answer 80

Two things:
1. Code complete 2
2. Reading a lot of open-source code

Answer 81

I enjoy picking up any language that I can get my hands on. Then I can decide what the language would best be applied to and throw it in my "toolbox". I really like being able to pick the right tool for the job.

Answer 82

Working as a programming lab teaching assistant -- having to teach another person to code, particularly through example, really made a big difference in the quality of the code I wrote.

Answer 83

Ensured that no matter what role I was in (e.g., currently software architect of a large project), I would be writing code. I've seen too many former developers stop coding entirely and they went up the technical or management hierarchy, and gradually lose touch with the reality of building software. The only solution to that is to keep writing code.

Learning new languages, writing in different environments, doing different kinds of applications... as much diversity as possible helps to round out your programming skills.

But the bottom line is that the only way to get better at something is practise, and to continually challenge yourself with projects of ever-increasing difficulty.

Answer 84

The obvious answer is:

Learned my first programming language.

Answer 85

Math degree.

Answer 86

1. Read. Books, Blogs, other people's code - anything you can.
2. Program. A lot. I won't say practice makes perfect, but it certainly helps.
3. Along with #2, keep an open mind. Be ready to accept criticism. Don't take offense; take it as a challenge. Admit and learn from your mistakes and get better.
4. Review others' code. Figure out how other people think about problems. It can be really eye opening. Perhaps they're doing something more efficiently than you are. (or perhaps less)
5. Challenge yourself. Take on crazy difficult projects that branch into the unknown. Try to learn something with every project you do.
6. Tinker. Never let work/school be your only development experience. Invest time in toy projects.

Answer 87

This is very subjective, but I find that teaching a concept to other people really helps me master it myself. I think this works for a few reasons:

1. It puts some pressure on you to really take the time to understand what you're talking about (you usually can't just Google it in the middle of a lecture).
2. Explaining something really helps you find the gaps in your won knowledge.
3. Just adding a social element seems to help motivate me.

Hope this helps.

Answer 88

Learn Haskell.

Answer 89

I felt like my turning point from "okay" programmer to "good" programmer occurred during college. Two things, which happened to coincide:

1. Take a compiler construction class (Compilers Construction and Finite Automata), where I built a C compiler
2. Learn a decent UNIX text editor: I picked vim.

Answer 90

Learning Java and getting a Java Certification. It's a really well thought out language, with great support and community.

Answer 91

Getting involved in an open source project with a lot of developers that are smarter than me. For me, it was getting involved in the Asterisk project (www.asterisk.org). However, the key thing is finding a project that you can be passionate about.

Answer 92

When coding, thinking like a von Neumann machine.

Answer 93

1) Be curious. Learn from the smartest people around. Read books, articles and code on how things have been done or may be done 2) Think. Play around and try out your own ideas 3) Fail. You only know what is good when you now what doesn't work

Answer 94

Leaving university.

Spent 1 year there, before realizing that this is not the place where I will learn programming, and started applying for job postings. I was lucky to get one, and it was all down hill from there.

• Working with experienced people? check.
• Getting a shitload amount of experience from them? check.
• Seeing different languages? check.
• Seeing what tools other people use? check.
• Learning that the client is always right? check.
• Standing up in office politics? check.
• Experiencing the first "oh shit the deadline is tomorrow and we have almost nothing" moment? check.

And I could just go on about how much more useful it was. I'm never going back. Maybe it's not the same everywhere, but here, they really really suck at teaching programming.

Answer 95

Here's mine:

1. Strictest possible use of design patterns

2. Implementation only by using best practices, in the strictest possible way

3. Unit testing, as strict as possible

4. Strict commenting in the code, every single line gets a content in grammatically correct English, with correct spelling

5. Learning the tools, the language and the infrastructure I use thoroughly, coding everything in a strictly Microsoft - compliant way

6. Avoiding workarounds, hacks and P/Invoke where possible

7. Learning functional programming

8. Considering only code that is not written good code

9. Forget everything I learned during the years I wasted with lowlevel timesinks like "C++"

10. Forget everything I learned during the years I was forced to use RAD - and then learned to use RAD - tools CORRECTLY

Answer 96

The single most effective thing I learned about good programming was to be disciplined about refactoring. I have decent design skills, but good designs can go astray either during initial implementation or ongoing maintenance. This is especially true when new features are added later on as they tend to increase code complexity and brittleness.

Discipline matters precisely when refactoring becomes harder. We should usually be doing the easy, trivial refactoring on an ongoing basis as part of normal coding. It is when refactoring becomes hard that it can be of the greatest value in maintaining code quality and keeping design/implementation flexible and reusable. One has to keep return-on-investment in mind about when and where to do major refactoring, but it is a necessary part of good programming.

Lastly, taking on the harder refactoring scenarios helps to reinforce and ingrain the importance of refactoring as a standard part of one's coding practices in more trivial situations. The earlier and more frequent, the easier it usually is to keep code quality high and extend the usefulness of the existing software designs.

Answer 97

Over the duration of my career I learn one important thing that if its a difficult task programmers tends to do everything together. take small breath ,forget about the deadline ,break it in small bits and don't think about what you have to do after that (the next bit).

I forget to implement it sometimes. but when i do it do wonders for me.

Answer 98

From a programmer I met on a flash conference and I totally agree with him.

1. Never think you know everything you should.
2. As soon as you reached the state of "Woow I am the greatest programmer in the world in [fill in area]" bang your head on the wall untill you don't remember it.

Answer 99

In the last year of my Computer Science undergrad degree, I took a compiler writing course. It was a full year course and in that course we created a pascal compiler from scratch. I wrote everything in C and I did not use lex or yacc.

That project advanced my programming abilities more than anything else that I have ever done.

Beyond that, the most important thing I've found that improved my coding abilities is to improve my analysis and design abilities. If your analysis and design skills are poor, you will be a bad programmer.

Answer 100

Work with better programmers.

Answer 101

Not writing code.

I learnt to use existing tools, and redefine problems to see if they could be solved by not writing code.

I read a lot to learn about data structures, algorithms and existing solutions (books, code, email, blogs, ...). Why reinvent the wheel?

After all, code that doesn't exist has provably zero bugs.

Answer 102

Reading other's code.

There are many open source written by expert programmers. Read their code, get to know their idea.

Answer 103

Subscribing to Coding Horror lol. Actually I found that getting a new job on a project that interested me helped the most. Mind numbing web programming for the great state of NY was kinda depressing and was holding back my coding potential.

Answer 104

I spent the first several years of my career maintaining other people's code.

(The second most effective thing would be spending a few weeks grokking Common Lisp.)

Answer 105

1 - Read about a specific, narrow topic in a book like Code Craft, or Code Complete

2 - Apply just that one lesson to a project I'm working on

3 - repeat

Answer 106

1) Writing code. Lots of code. Most of it were only fun little dinky programs to solve a special problem, but since I've been on the workforce, I've written some production code. Every time I've seen something that I have done wrong, so next time I did it in a different way. In one word: experience.

2) Reading code. Before I only wrote code, but recently this is changing. I've been doing some code reviews, reading and evaluating open source stuff, sometimes even modifying some of it. This gave me a lot of tips, know-hows. Also, I can handle open source stuff with bad documentation somewhat better.

3) Show your code to someone. Other points of views can show you stuff you never tought about. A programmer on embedded systems may recognise something that can be done with less resources, a security programmer can point out failures, etc.

4) Tutor someone. Despite what some people say, programmers have to maintain human contact. Also, it gives something back to the community. I've met some of my friends during tutoring sessions. It makes you a better programmer because you'll be able to communicate better (which is realy important if you want to write good documentation).

5) Learn a wide range of languages at least to some degree. The difference between them is not just syntax. ASM needs different thinking than Java. Lisp programmers program different than PHP developers. Knowing a lot of languages at least to some degree gives a perspective.

6) Work on something for a while. If you have a cool idea, work it out. Try getting your peers involved. It's realy fun to work in a small group, solving your own problems. The company I work for started this way. But before you begin your career, it will help you understand teamwork. Also, you'll get to see how an application is designed, implemented and maintained.

There are more reasons, but these helped me a lot.

Answer 107

Probably digging into GoF design patterns, which certainly opened my mind in terms of source code reusabity and maintainability. Also, Martin Fowler's book and articles on refactoring made me a better programmer.

Answer 108

All the advice here is nice, but you asked for a single thing:

Reading The Pragmatic Programmer. After 9 years, still no other book is as relevant. Religously live the advice given.

Answer 109

Practice.

I have a personality quirk that leads me to re-invent just about everything. I want to know how everything works, and that tends mean writing a huge amount of code. I've become very good at it.

Programming is a lot like playing the piano. The more you ACTUALLY WRITE CODE, the more skilled you will get at that. The more you debug code, the more skilled at debugging you will become.

I had a step-father who was a really amazing pianist. He told me that he estimated you needed to play about 10,000 songs on the piano and then you'd be excellent. He didn't think it mattered much what kind of learning styles you used... you just had to get the practice in. The goal is to retrain pathways in your brain and get yourself all tuned up.

Obviously playing chopsticks 10,000 times isn't going to make you a concert pianist, so don't be stupid. However, anything halfway reasonable should work.

If you think code reuse means spending 8 hours on the internet searching for someone else's solution to a problem and then copy and pasting that in... sorry... you aren't going to improve very much.

I've met a great number of people who want to believe that with the right tools, you don't need to program very much. You must absolutely, totally purge any inkling of this concept from your head and stomp on it until it's about 2 nm thick. It's horribly destructive from a self improvement point of view.

"New software for concert pianists from Rational Software! Convert your Symphony Modeling Language diagrams directly into sheet music! Export to all current platforms using MIDI, perforated scrolls, or music box cylinders! No more hours and hours slaving over the keyboard!"

Answer 110

Learning Haskell gave me a fresh perspective on my programming approach. This has improved the way I approach programming problems considerably. I cannot recommend enough trying out different programming paradigms in order to improve your problem solving skills. It doesn't mean you have to abandon your favorite environment. Just look at how things can be done differently and learn from that.

Answer 111

Fixing/enhancing other peoples code.

Answer 112

Never think you have all the answers...there is always something to learn.

Answer 113

Read "Code complete" by Steve McConnell...

Answer 114

For myself, being open to new ideas and trying to see the bigger picture which gets to be a bit of a paradox at a point. Some examples:

• Design Patterns - Reading about them, using them in new projects, seeing where they may already be used but I don't know that that is a pattern. These can also be work patterns or patterns in how projects are done though these are usually viewed as practices...
• Practices - In my case this is learning refactoring, Agile, Scrum, estimating work using a modified Fibonacci values, TDD, as well as new tools like Resharper, SVN, etc. Also in here can be concepts like technical debt and broken windows that can be really neat ways to convey ideas in some cases.
• Architecture - See how some big systems are tied together and how different components come together to build say a CMS or CRM system.
• Evolving technology - I can look at how I use VS 2008 and try to remember back to using VS 6.0 many years ago and some parts of how I build web applications has definitely chaned over time which can be beneficial to see new ways to put things together.

The paradox comes from that at some point, I'm looking at things from such a high level that nothing is really in focus and so the challenge them becomes trying to get back down enough to know how to put together the smaller parts while still understanding a big picture for where I'm trying to improve something.

Finding better work environments is another big thing can affect my skills. If I'm working with people that produce code of a high quality, polished code with tests, that can act as a way to influence me to be better about what I add to the codebase. Similarly, if I work with a bunch of cowboy developers, this may make me be more of a cowboy coder myself.

• By cowboy I mean that kind of developer that regularly has spaghetti code that as it was all done by 1 or 2 people they know what ideas where behind various parts of it and there can be many times where one has to go, "Crap, now I go fix that," or "Whoa... how did I miss that?" or, "What do you mean someone tried to put in X as a number? That's not cool."

Answer 115

Stop being so cocky and listening openly to other alternative opinions.

Answer 116

abstract one mile long, code one inch deep

Answer 117

• Get used to the fact that longer, more verbose code (boring code) code is often better readable and understandable than shorter (clever) code.
• Get used to the fact that you sometimes have to delete what you have been working on for the past week, just to write it all again, in 50% of the time and much cleaner.
• Keep learning other programming languages and frameworks.
• Talk to more experienced programmers.
• Never "be happy" with your skills - keep improving all the time.
• Look at older code you wrote in the past from time to time - you'll see how much you improved and how much more clearer your picture of the programming language and frameworks has become.
• Write documentation. Document every single function - even if it's just one sentence. Use a tool like Doxygen, which will teach you to love writing documentation.

Answer 118

Learning different classes of programming languages...

C, Java, Python, LISP...

Answer 119

Working on a personal project...something you enjoy. For me it was game development, learnt more about programming in a month than what i had learnt in the previous year.

Answer 120

working with Nemerle

Answer 121

Reading/applying 4 books:

Elements of Programming Style by Kernighan + Plauger
Software Tools by Kernighan + Plauger
Mythical Man-Month by Brooks
Psychology of Computer Programming by Weinberg

Answer 122

I've not been programming for long - roughly a year, unless you count HTML/CSS work and very basic PHP stuff for querying databases.

I started programming in Pascal at college, and found I had a natural 'knack' for programming. Most of the tasks given to me were easy (it was only an introductory course). Since I started the college course (I'm about to start university in a couple of weeks), the following things have helped me:

Note that these are very much from a student's perspective.

• Make programs more complicated than required in the tasks given. I made all my programs go 'the extra mile' - more functionality, a better UI, more suitable for a real-life application. This gave me the opportunity to learn new things that weren't necessarily included in the course.
• Do a lot of reading. I read a lot of material, admittedly mostly online, on Pascal and how to do what I wanted. Since then, I have also done a lot of reading about other languages - C, C++, PHP. And also other paradigms, especially OOP. Reading what other people have to say, from a variety of sources, has given me a pretty decent idea of how to program well.
• Program, program, program. The more I actually program and put into practice the things I have learned from college or reading, the better understanding I have of what I'm doing and how the theory really works.
• Review your code. I find that going back to programs that I have previously written and taking a critical view of them really helps. I can see how to better write the code with the knowledge I've gained since then.
• Rewrite your code. After reviewing old code, I find that rewriting it using new methods I've learnt really helps me to appreciate what I've read. If I can successfully rewrite, for example, a holiday quote system that I wrote while at college, I can see the benefits from start to finish of using new methods.
• Ask questions. Sometimes tutorials and articles can be a little too technical and a lot seem to assume prior knowledge, even so-called 'beginners' guide to...' articles. Asking someone you know, or using place like SO means you will often receive a much more useful answer in terms you can better understand. Especially if you are a beginner.
• Design code first. We only did basic top-down design in my college course and at the start I had a habit of writing the code first and then 'cheating' the design process. Once I got onto larger programs, I really began to appreciate the benefits of designing my programs first - made the actual programming part so much easier and quicker.
• Program, program, program. This is definitely the thing that has helped me improve my programming skills the most. It's worth two mentions, I think. Having theoretical knowledge is fine, but if you can't put it into practice, what's the point?

I'd recommend all the above things to people who want to learn how to program, and probably one other thing: Don't be afraid of jumping in with both feet.

Answer 123

Practice coding and algorithm in all kinds of online judge system such as USACO, topcoder, poj and so on.

Answer 124

Become an active member of SO. Really!

• To dive into problems other people are facing and where you could give advice based on your available knowlegde but most of the times the questions push you to take it one or two steps further.

And off course also:

• Reading good books, make the examples, discuss them with colleagues, and go on...
• Make a proof of concept about a certain goal you want to reach, not doing it in production code but just a kindergarten project where you try all sorts of different scenarios
• Scraping the internet for good examples, clarifications, good blogs
• Clearly define with the (inhouse) customer what they really need, we all know this fabulous picture, it makes so much difference to communicate the desired functionality, get the details clear, discuss business rules, use-cases and their deviations.

And last but not least:

• Don't let your (proud) ego stand in the way of learning from your own mistakes and from others

Answer 125

After doing lots of the things mentioned here: get a good programmers editor (editplus for me), learn several programming languages (C++ and Lisp cover a whole spectrum of techniques), learn regexps (actually pretty simple, compared with other stuff, but amazingly powerful), learn about top-down parsers (that way you forget the idea that regexps can solve everything), I found the biggest help from an unexpected place:

Learn Mathematics.

Really.

This is not about learning calculus formulas or other stuff that is taught to engineers. That's not the mathematician mindset. This is about being able to think and write a correct proof for some theorem, sometimes grabbing ideas from the most unexpected places, or doing stuff that looks like a crazy workaround to the untrained mind. And advanced linear algebra course can be a great Mathematics intro.

After this, your programming mind literally grows bigger, by a huge amount. You can hold bigger and more complex pieces of code in your head, and it actually looks very simple. After some really hard Mathematics proofs, some complex algorithms look trivial to you in comparison.

However, there is a caveat: most Mathematics teachers will want you to be both the programmer, and the computer. You write the proof by hand, and perform all calculations of any application by hand, otherwise it has no merit. Most of them still don't understand the power of computers. In the same way, most programmers will disregard Mathematics as 'that bunch of calculus formulas with no direct relation to programming'. If you get the good bits from both worlds, you will be a better programmer than 99.99% of them all.

Answer 126

I answer this question like teachers from language classes. If you want to speak Russian, you must speak Russian. If you want to read Russian, you must read Russian books. If you want to write Russian, you must write Russian!

So if you want to write high quality programs, you must code. But writing high-quality code isn't the only measure of a good programmer. You must do a lot of other things, but I think you get the idea of the things you must do to become a pro.

Answer 127

Touch typing. Learnt touch typing during the first month of employment because I was bored.

Switching to Linux comes as a close second. It helped me understand the the background of the C programming language.

Answer 128

I implemented User Threads, a mutex library, and an I/O library for the 3rd homework assignment in the Operating Systems course I took last semester. It basically required us to implement a major part of the kernel from scratch (the whole thing was supposed to run in user space, and we weren't allowed to make any changes to the actual kernel) and managing all the data structures, scheduling issues, concurrency corner cases, and hacking around the native scheduling mechanisms was a very difficult task. After finishing it I definitely felt a noticeable "level up" in my programming skills.

Answer 129

Testing. It made me think about my design, which wasn’t much modular at the time, everything bound together by singletons and similar stuff. Testing forced me to uncouple the code, which was a huge change I am still getting the benefits of.

Answer 130

If effectivity is measured as improvement/time, then I'd say I learned the most from:

• looking at a multitude of other languages (sometimes only reading a book and introductions about them)
• looking at a multitude of frameworks (sometimes only reading the introduction and crawling through the reference)

I've learned a lot of idioms, patterns and approaches from this, as well as quite a lot of common mistakes not to make.
And also I learned a lot from trying to understand, why certain things are done the way they are and whether or how they could be improved.

Answer 131

The best thing I did to become better was finding a mentor. Having a mentor made me strive to become the best at what I do. This inspired me to read more, learn more, and yearn to become a mentor one day myself. I was stagnant before and finding someone like that to look up to was the best thing that ever happened to my career.

Answer 132

Share your code and collaborate openly with other programmers (if they can be great programmers, that's the best)

It's not only working with other people, but to review code, discuss different ways of doing things and learn for each other (even some peer programming). I've been in works when you worked with people, but each one takes care of their own code, since the design to the tests, and, well, you're on your own...

But when you can discuss freely what it's the better way of doing something and you make code together that's something that teach you a lot...

Answer 133

I started up a website where I try to share any coding tips I learn. Trying to write stuff down really helps get it clear in your mind and helps you to remember things when they crop up again.

Answer 134

To me, the inflection point was that I started reading code from great open-source projects. I saw different styles, new techniques and it opened my mind so much that it was a sensation similar to traveling and living in other countries.

Answer 135

I think one of the things that made a big difference to me was writing a long tutorial on something I had been working on as a hobby for a while. It really helped me organise my thoughts and tidy up the tutorial code as I knew other programmers would be looking at it and either learning from it or pointing out to me that I'm an idiot through it. I think doing it as a single chunk was really helpful too as it gave me a much deeper understanding of the field I was working in.

Also when I went freelance and was working for myself, that forced me to up my game. I didn't enjoy it that much and I went back to working full time after only a year or so, but it was still a very educational time.

Answer 136

Finally starting to work again in the field after excruciating years at college, at the Swiss Federal Institute of Technology in Zurich (ETHZ). I had worked as a web developer / graphic designer for a large company during the dot com boom after high school, prior to college and the mandatory army service here, and missed these days while my brain was being hammered with endless lessons on Eiffel, Prolog, compiler design, algebraic set theory etc...

Answer 137

I believe that reading and experience are the most important in improving.

When I first start a language, I like to read a couple quick start tutorials, then I work with it a bit. After I have a better feel for the language, I read a more complete book cover to cover. In order to use whatever language you choose to it's full potential, you need to know everything about the language, including it's strengths and weaknesses.

Reading books about general programming has helped me out as well. A lot of the most important concepts of programming are not language specific. A book about a single language doesn't cover the same areas since learning a language and learning to program are different things.

Answer 138

Used them.

Seriously though, I often find myself repeatedly implementing the same sort of functionality in new ways. Each is an adventure that always raises new questions. Answering those questions allows my skills to grow.

Answer 139

Learn another programming language, possibly one that has a fundamentally different approach. Scheme, D, Scala, JavaScript. It will open up your mind at what can be done with each of them, even if you do not get to any level of procifiency.

Answer 140

I switched to an editor with syntax highlighting, contextual autocomplete ("intellisense", etc), and automatic indentation. This has had a greater positive effect on the efficiency of my code production and the readability and maintainability of my code than any other single thing that I have done or learned.

Answer 141

To learn how to ride a bike you have to ride the bike. To learn how to program you have to program. The more you program the better you become IF... if you always try to improve yourself and you always strive to create good code. And this brings us to what good code is and what good programmers are. There are so many answers to this. But some basic guidelines are: clarity, simplicity, generalization. The reality is practice alone doesn't make perfect. Perfect practice makes perfect. You need to code and also have your code reviewed by some other eyes. You need to read code written by others - good code and bad code. You need to understand how code rots and good code yesterdays becomes mushy bad smelling code tomorrow when the conditions, requirements, constraints change. It seems I can go on and on forever... Okay the gist is code a lot in various areas with various languages and think critically about it while exposing your code to others' opinions.

Answer 142

I read books that have nothing to do with programming and everything to do with what my product will be used for.

Answer 143

Being open to languages or approaches that were outside my comfort zone. I would say another major player was sharing what I learned with others. When you have to explain why, it pushes you to be certain you know it.

Answer 144

lol. typing in code from magazine articles (yup, back in the day we used to do that for full-page Amstrad and Atom code listings). It may be like rote learning, but it got me from nothing to something, everything I've done since is incremental to that initial bump.

Answer 145

Stopped writing procedural code and started creating objects.

Answer 146

Teach the concepts to someone else. Then you quickly realise which parts you don't truly understand.

Answer 147

Coming to the realization that you can't rely on your company or the 8 hours you spend "at work" to keep your skill set up. Being a better developer is an ongoing process that never stops.

Answer 148

Told my boss "yeah I can fix that for you, give me two days." Then had to learn a new language to do it.

Answer 149

Taking part in code reviews. This really combines the idea of reading other people's code with having to think about presenting your own. Seeing other people's mistakes is just as valuable as seeing their whizzy clever stuff, and the pressure of having other people see your code really concentrates your mind on making your code as comprehensible as possible.

I now think about the ease of maintenance of code as being WAAAY more important than its efficiency, and I choose an easily comprehensible design over a super-efficient but incomprehensible one every single time. Of course it helps that the poor maintenance programmer figuring it out may well turn out to be me :-)

Answer 150

One of the most effective things I've ever done is positioned myself with those who knew more than I did and listened. Get on a project where you know the senior developer is working and pay attention to his/her code and way of doing things. When you don't understand, ask (when time allows). When you become a senior developer yourself things change a little and you enter constant discourse with your fellow developers on the best way to do things or fresh new ideas. But once again, you do a lot of listening.

Styrofoam Head Theory:

Often while explaining a problem to someone else, you explain yourself right into a solution. This happens frequently and is a fantastic exercise. The reason is because in order to communicate an issue to someone else you're forced to break it down to its simplest parts to make it easier to understand. So try writing an email to a jr. co-worker to explain the problem.

Hint: You've also just written some documentation.

Answer 151

Worked with other more experienced programmers. Helped other less experienced programmers.

Answer 152

Wrote code on my own time, just for the fun of it. Not just any code, but deliberately concentrating on low-level reusable objects and modeling the relationships between them.

Answer 153

Program all you can and associate with people that are smarter than you who program.

Answer 154

Learning different coding paradigms can really open your mind up to a higher level of thought. Looking at your standard diagramming vs the COBOL VTOC for example. Reading the Extreme Programming tenants. Actually trying to do a program with a top down programming method, then a bottoms up method.

Understanding your standard OO theories is helpfull - Overloading, Inheritance, Polymorphism, etc.

I used to think, before I learned so many languages, that if I only learned enough languages that would make me a great programmer, because every language has something special - Pascal has set notation, COBOL has extrodinarily efficient memory allocation for multidimensional arrays, BASIC is... basic. But chances are that simply learning a small set of languages that are radically different, like (COBOL, C++, and LISP) will be an improvement. I cannot verify that though.

Knowing that every language is just syntax - especially if your not going to take the time to learn what a language is really good at.

Digesting the grim reality that documentation really does matter.

Answer 155

There is nothing that will do more for coding skill than writing code. I would go so far as to say there is limited utility to be gained from anything that does not directly involve crafting code. If you are fortunate enough to work in a job where you are not constantly hammered by deadlines, stepping back and working through your section of the project with another programmer then doing the same with their section of code will do more for your programming skill and understanding of how to make engineering decisions than ten books [unless those books have Stroustrup, McConnell, or the likes on their spines].

.. the same could easily be said for software engineering students. Be brave, let others read your code and read theirs. Constantly be working. You will be much better for it.

Answer 156

Not believing every tutorial I've ever read. Being critical of "good" code and questioning "bad" code.

Learning to think more object minded, getting into custom collections.

Most of all, the greatest things I think you can possibly do is:

• love your craft and surround yourself with the kind of programmers you would like to be.
• Never stop re-educating yourself and never think your way is the very best way.
• There is and always will come, a better more effective way, and a lot of times you will just be flat wrong in the first place.
• Digging through libraries and tinkering around with methods and functions just to see what they can do.

Answer 157

Switching from a pseudo OO language to a fully OO language. It changed how I look at things.

Answer 158

I found that when in the initial phases of my career, moving around often helped tremendously. This forces you to expose yourself to different ways of doings things. I've interviewed people twice the seniority of myself that have spent the last 10 years at the same company and was surprised by how little they've evolved since college with respect to their programming abilities. You can easily surprise yourself at how differently people do things when you move to a different company and how much better (or worse) their approaches are. Point being, you want to expose yourself to as many different ways of doing things as possible, especially while you have the luxury and the opportunity to move around often.

Answer 159

Learning FORTH

Answer 160

Let others review my code and criticize it. I regret didn't do enough of this.

Answer 161

Learning to learn from the mistakes of others.

Answer 162

If I had to pick a single thing, it would be code reviews. You need to be disciplined about it. Have your code reviewed and review other people's code as well.

Answer 163

The singular thing that I did to improve my general programming ability was to read and apply the principles, guidelines, and suggestions in Steve McConnell's book "Code Complete". The improvement that it fostered in areas such as readability and maintainability has helped me immeasurably over the years.

Answer 164

in order of effectiveness, the ways I've found to learn something are:

• learn by reading
• have someone teach you
• learn by doing
• teach someone
• present to a group

There is no substitute for having to teach someone or present on a subject to get on top of something. I guess the list is in order of passive vs active involvement.

So for programming, presenting what I did is definitely a level above actually doing it.

Answer 165

• Join a community (Stackoverflow is a great example)
• Have an opinion. Don't just take what others say as gospel, question them.

Answer 166

When you look at a new or different piece of code, you may be faced with a lot of unfamiliar stuff.

It's tempting to make changes to existing code without understanding what all those moving parts are doing, and how. But I think that making the effort is important and ultimately pays off.

It can be difficult to do this when you're under pressure to produce results fast. But it gives you the experience to say, "I've seen this pattern before."

Answer 167

Always remember two things.
1. Bits is bits.
2. Nothing is impossible - we just haven't figured out how to do it yet.

(1) must of course be credited to William Verts of the University of Massachusetts - Amherst. His lectures instilled the realization that although we may be working with different languages, techniques, technologies all we are really doing is moving bits from one location to another.

(1) feeds directly into (2). If all we are doing is moving bits around then we can move those bits around in any way to accomplish any goal. The second part of (2) really says it all - having not yet figured something out has absolutely no baring on our ability to figure it out.

Answer 168

Writing and knowing exactly what each command you typed do

Answer 169

In order to become a better programmer, you need to step away from the computer and work on your communication skills. You need to develop and hone these communication skills to ensure that you are programming the right thing. If you don't understand what it is your customer is trying to accomplish you will not be a very good programmer, no matter what your technical skills are.

Answer 170

Learning to read other peoples' code. You'd be surprised how many programmers cannot or will not do this. They'll spend hours and hours polishing arguments on why it would be more efficient to throw out the old code and rewrite from scratch simply because they do not want to go through the pain of reading and understanding someone else's code.

Number one technique for finding problems in the code I've written is run the debugger and step through it.

Number two technique for finding stubborn problems in code I've written is explain the code to someone else. Another programmer is best. Almost anyone will do. Probably not my wife or mother.

Since 2003, I've learned that ALMOST nothing is new under the sun. Always look for an example on the web before setting out into new territory.

And read Code Complete twice.

Answer 171

1. Complete a small project from A to Z, starting with documenting requirements and ending with UAT, production and support
2. Let a person with grater experience (an architect) analyze your work and give you feedback
3. Learn from your mistakes and apply the best of what you learned into the new projects
4. Concentrate on the INITIAL QUALITY of your code. Create metrics to measure it and assess it regularly.

Programming is not only about coding skills, but also about processes, communications, time management, etc.

Live by the goal that you want to become best-of-the-best in your position at your organization.

Answer 172

Debugging other people's code. I work in the video game industry and we have hard deadlines to ship for the Christmas Holidays. In order to get out on time, at the end of the project we are forced to deal with squashing lots of bugs in short order while trying not to introduce new ones.

The ability to read through another person's code, understand what they did (and possibly what they did wrong) as well as fixing it in a way that won't introduce new bugs gives you insight into both other people's programming methods as well as how to extend your own.

Answer 173

Worked in non-programming but related jobs, such as technical writing, producer, management, etc. The perspective you get is invaluable.

Became busy. Having lots to do forces you to adapt efficient methodologies.

Stuck with programming over the long-term. There is nothing as humbling as looking back on code you wrote ten years ago.

Answer 174

I would say always try to come up with a model that solves a programming problem in its entirety and consistently. Once you nail the model then you can start to sketch out what this will look like code-wise. This applies to most disciplines.

Answer 175

I think the question is not well phrased. the "one" thing, sounds to me like "silver-bullet" and we should know it does not exist. However a few things were mentioned here. One of the most important things is that you really like programmming. If you see what you do "just" as job you never will get far IMHO. The next really important thing is practicing. You must read and write a lot of programs. I for my part suggest programs in different "programming models". Programming has a lot in common with hand crafting. Everyone successfull in that area has "learned" and practiced. There usually some sort of "master" around, it's difficult to tell who'll be a programming master, the area is that bride. You just can find out while reading code, bad code, good code, exceptionel good good, extremly poor code.

Ask yourself what was good done and what seems bad. Try to improve it. Ask yourself, can one understand the code or was the programmer just lazy to spend time on it.

Regards Friedrich

Answer 176

1) Wrote a business aplication on Ruby on Rails. This forced me to think really hard on what's the best way to do things like organizing code, naming methods, etc. This lead me to properly understand MVC and adopt a proper "professional" attitude towards software engineering. 2) Progressed to programming business applications (web) with Java ande applied my knowledge from RoR development to Java web development.

These were probably the single most effective things that helperd improve my skills as a software engineer.

But amongst these the key thing has always been: learn from others! Read books, read articles, read blogs. Reading sites like c2 Wiki, Coding Horror and The Daily WTF have really helped me gather knwoledge and undestanding.

And these days also listen to podcasts, listen to presentations, wathc screencasts etc. RoR programming screencasts were probably the most impressive learning experience to me: somebody actually coded this just before my eyes and properly explained what he's doing and why.

Answer 177

Learning vim

Answer 178

Podcasts such as DotNetRocks and Hanselminutes really opened my eyes to new concepts and ideas in development. This has lead me to many more resources, blogs and magazines that I was not aware of.

I was also lucky enough to have had a couple of jobs where I was able to incorporate development without it being in my job role, I could learn at my own pace and do things my own way.

Answer 179

Buying beginner books, it's like a kata keep rehearsing the basic so that your foundation is strong.

Answer 180

Spend at least one day a month researching new technologies and upcoming features of my chosen specialities.

Answer 181

Getting onto projects that I really enjoyed - gave me motivation to learn, innovate and develop new ways of doing things.

I have also found that working alongside other, more experienced people (having a mentor) is very useful as they pass on valuable bits of knowledge as well as different ways of doing things.

Answer 182

Reading about new ways of making things right
Make other people look at my code
read other people code

Answer 183

My programming style improved immensely once I started to use unit testing. There's nothing like trying to instantiate an instance of one of your classes in order to run a unit test to truly see its dependencies on the rest of your code. Unit testing also gives you the confidence to refactor without breaking things too badly (unit tests are never perfect) which is a great way of taking advantage of some of those ah-if-only-i'd-done-it-that-way moments.

Answer 184

It is not something I did, rather, it is something I am doing constantly. I have a my.yahoo page that has, at this point, over 50 feeds that I read every day. I subscribe to 12 periodicals. I try to buy at least 2 programming books a year and read them from cover-to-cover.

As a wise man once said:

When you're green you're growing, when you're ripe you rot! -Ray Kroc

This is something I live by.

Answer 185

As per my moto: "Never stop learning" :)

Answer 186

All of these fail to hit the big one. No one is a good programmer until they learn how to debug. Especially other peoples code. Learn it/live it. Instead of reading the code from a good "Open Source" project, pick an existing bug on that same project and solve it. Try to solve another bug without your favorite debugger ... some errors do not manifest themselves in debug mode and a good developer has this skill. If you really want to know how not to design a system, or the intricacies of smart pointers versus garbage collection, or most other system complications, this is the single best way to go.

Answer 187

The most effective single thing I've found?

Adopting the white-hat hacker ideal (essentially, curiosity about absolutly everything). If I don't know about something, I'll go and find out about it.

Admittedly this has lead me down the track to attempting to learn physics at the moment, but I'm sure it'll lead to some advance in my programming knowledge eventually.

Answer 188

There isn't one single thing that improves your programming skills. It's a never-ending process of refinement using many, many inputs.

Reading books, magazine articles, blogs, other code, lots and lots of other code both good and bad, doing peer code reviews, having your peers review your code, getting fired occasionally, changing jobs to improve your skills, thinking, trying new tasks, experimenting, absorbing new languages, accepting challenges, challenging yourself, accepting that you aren't the best, working to get better, acknowledging your failures and working to improve them.

Programmer, refine thyself.

Answer 189

Reading Books, Megazine , google different type of scenario and go theu that code , writting code working with smart ppl who can give you good idea how to improve programming ,always keep updating your knowledge about new technology

Answer 190

I grabbed a development site and just started churning out web sites that would just pop into my head. This helped me learn several new languages and a vast amount of technology pretty quickly.

I still buy a programming book a month to read and learn from. I have expanded my knowledge a great amount over the last year just by doing this.

Answer 191

Maintaining other peoples code. Having to dig through 1000's of lines of undocumented, under/over designed code will do more to teach you about code structure, re-use, and documentation than any class or any amount of code writing. Being able to write clear easily understandable code is the best thing I've ever done to improve my skills.

Answer 192

Learning how to write short, understandable comments.

Answer 193

Undoublty learning assembly (or should I say assembler, as I started coding in hexadecimal? :-)

Once you know how the processor executes code, you realize what really an "if", an "while" a "struct" and any other language construct really are, and you start to appreciate these language constructs exist. Also, once you know assembly, the speed in which you learn a new language is so fast that this for its own is worth the effort.

Just to help people realize how great is learning assembly, it's like when Neo starts to see the Matrix how it really is by the end of the movie. Someone will come and show you this "new great framework" and how it works, and you'll just say "is this just it?"

Answer 194

Knowing the business of software and understanding how to become profitable. You become very adept at managing clients, requirements, and quality. From a technical perspective you apply appropriate architectures, patterns, and methodologies that lend itself toward simple, pragmatic solutions.

Answer 195

Reading Code Complete

Answer 196

I started to read and do things similar to development, but NOT development. eg

• Joel On Software.
• Managing Humans (Rands FTW!!).
• photography (creative outlet which isn't software, but uses a LOT of software)
• mountain biking (same - technical, but not development)

Worked for me :) the last two are great ways for me to work thru a problem - esp MTB.

that, and learned a new language, or atleast looked at new stuff, often. I can atleast read C#, java, VB.NET, Ruby, Python (well, getting there), Pascal, x86 ASM, Obj-C etc, even if I can't WRITE all of them well.

Answer 197

I learned to read other people's code.

This might seem overly simple at first, but being able to understand the subtleties in code before modifying it is a great asset. When you work on a project for a couple of years, code gets old, so you're bound to have to modify code you're not so familiar with. I too often see young programmers who have a lot of trouble understanding the big picture when going through code they didn't personally write.

Answer 198

A programmer needs only to solve 'unsolved problem'.

Do not reinvent wheel.

Answer 199

I took a developer job in a field I didn't have any particular interest in prior to being hired.

The specific issues encountered in this line of business that I had to solve changed the way I approach solving programming problems.

I think the lesson here is that I was taken out of my comfort zone and had to tackle issues I would never have had to solve in programming projects in fields I've already worked on in the past.

Answer 200

Always try to imagine what is going on inside the software I see running. What is the compiler doing? How does the app server implement that connection pool? What is the version control system doing with my file?

Then when something breaks I have somewhere to start to look for problems.

Answer 201

Taking courses. This might not be what you referred to but there have been three courses that helped me immensely.

• AI - A course that helps learn suitable algorithms for problems you may encounter as a programmer. Don't let the title scare you. AI courses are broad which makes them easier than they sound. These courses are more practical than generic algorithm courses.

• Programming paradigms - Courses that explores different ways to program. You should expect a lot of haskell, lisp and regexp. Beware that functional programming is like a drug that is hard to get rid of once you've mastered the wonderful world of one-liners.

• Computer architecture - Any courses that teaches you assembler and "behind the scenes" stuff. You are then forced to learn about memory, cache, DMA, floating-point calculation and the like. Some might say that C++ must be learned to be a good programmer, but it only forces you to learn about pointers and how classes are built internally (if even that).

Answer 202

Fresh out of university I got some of my C++ (a language I thought I knew) reviewed by someone who really did know the language. He completely took it apart and spent a long time explaining why it was awful. Up until then no-one had ever criticised my code, so I thought I was pretty hot, but after that day I realised I still had it all to learn. Getting taken down a peg or ten was absolutely essential and I'm so glad it happened early in my career by someone knowledgeable enough to set me on the right path.

Since then I've always been prepared (even eager) to give up "my" way of doing something in place of a better way.

Answer 203

Reviewed Code and let my Code get reviewed

Answer 204

Studying the best books on our profession. (E.g. the GangOfFour book about Design Patterns). Working on projects gives you experience but there is no substitute for the good old learning.

Answer 205

Learning C++ was the single greatest thing that has helped me in my programming life! It just makes everything else so much easier

OR

Learned how to type!

Answer 206

Applying the Extreme Programming aphorism, DoTheSimplestThingThatCanPossiblyWork, probably improved my overall software-engineering skills more than any other single event or practice. Of course, sometimes that "simplest thing" doesn't work, but that's OK: you've learned something, with minimal investment of time and effort. Even if you hate everything else about XP, that one principle is worth the price of admission.

Answer 207

The single most effective thing? That's easy: listening to other people.

Answer 208

Switch Industries every 3 years.

Answer 209

There are many effective things I did to improve my skills. I read and still keep reading as many programming/technical books I can cram into my skull. I also write as much code as my fingers will allow me.

Programming is an art form. Plain and simply. Just like the artists of history. Leonardo did not just see art as "just a job" but it was his life's work.

Another great thing to do is listen to other software developers who are not only better than you but who are on your same level. There are many ways to come up with a solution to a certain problem. This is where collaboration not only helps solve a solution but it also develops your programming skills as well as your team work abilities.

If you study and practice at it then you will be a great developer.

Answer 210

Read Code Complete by Steve McConnell

Answer 211

Teach someone else how to program.

I teach programming after work at the local college and it requires me to be able to plan, to think on my feet, anticipate errors that people (including mysef!) make, and to empathize with the difficulties of people learning something new which makes it easier for me to face the frustrations of learning something new.

Answer 212

Joined a relatively big open source project and contributed thousands of lines of code to it. In the process, I learned a lot about architecture of big programs, good cases to use programming patterns, advanced object-oriented design, teamwork, cross-platform compatibility and UI design. Ever since I joined the project, my programming skills keep improving.

So, to answer: it's the working with other people in a team that opens new horizons. And open source projects are very good for this since:

• there is no pressure to get the work done ASAP
• people will tolerate if you lack some skill and help you learn it
• you don't have to program some part of application you don't like or find boring
• the entire team is friendly, since it's in everyone's interest that the project goes well

Answer 213

Got a job teaching programming at university. Had to read all those text-books that I never read as an undergrad in order to try to get it into the heads of bored 19 year olds.

Answer 214

In terms of coding, it would be learning Common Lisp for me. I never got to do real projects in it, but it taught me most of the language features possibly present in other languages. It helps me learn new languages/think about problems in unusual ways.

For professional development, I learned a lot from a senior developer at my first job while still in college. He guided me through concepts/things like version control, deployment to servers, testing, and working with designers. These things were confusing to me as a new developer.

Answer 215

Learn assembler and write a disassembler to see what the compiler really does.

Answer 216

Being around people that are much stronger than I am. You pick up the scent of good skills from these folks. On the other hand if you are around folks with much weaker skills, there's a tendency to cut corners, etc. This applies more generally than just coding. I take it as a general rule that I need to always be around people better than I am. I have always benefited when I have done so.

In terms of techniques, one that has really helped is actually reading blogs. Putting together a good collection of technical blogs that you read frequently is an invaluable growth tool. For example through blogs I learned about DDD, IoC, SOC, SRP, etc. Yes you can learn them many other ways, but blogs tend to be much less book knowledge and much more real application.

Answer 217

I started life as a C programmer.

The biggest jump came when I switched from MS-DOS/Win 3.1/Windows 95 to Slackware Linux.

Close runners up:

Learned assembler. Learned about Functional Programming

Answer 218

I read "A Framework for Representing Knowldge" by Marvin Minsky - and discovered the Science part of the field, as opposed to just the Programming part, which I had gotten bored with

Answer 219

To be honest, learning LISP, Prolog and ML went a long way to improving my skills as a programmer. Looking at the programming world through the lens of functional programming goes a long way. The math behind it is fascinating. It puts you in a completely different state of mind when you go back and work in C#/C++/Java/what have you. Functional programming is clearly not the end all be all of programming paradigms, but it's a great tool to have in your mental toolbox.

Answer 220

Read. A lot.

And write. Write about programming.

Fashion a passion for programming. Let it fester, er, grow!

The thing about programming is not the programming, but the concepts. If you learn the concepts well, you can apply (most of) them with any development language.

The single most effective thing you can do though is to never stop learning. Pay attention when working with others. Even a senior dev can learn from a junior dev if the senior programmer pays attention. Just remember that you never stop learning.

Second most effective thing you can do is read Pragmatic Programmer.

Answer 221

I'll go with some bullet points:

1. accquired a relentless passion for learning
2. failed foward and always committed to learning from mistakes/lessons learned
3. made adequate time for reading and attending user groups, etc
4. made sure to take on work outside of my primary job and contribute to open source
5. made a point of taking workshops/lessons/classes with industry gurus
6. learned a new skill or programming language every year if not every 6 months

Answer 222

Took a job where I was in over my head, yet had a great mentor who was willing to show me the ropes.

Answer 223

I kind of learned it the hard way, but something that eventually really improved my programming skills is knowing when it's time when not to be using them anymore. To be more specific, to know when to take a break. I have spent hours trying to figure stuff out while being a certain state of thinking that made me run around in circles. Taking breaks really improves your skills... or at least their effectiveness.

Answer 224

The single most important thing I've done is code. Anytime I've learned a new language, or was presented with a new environment or library/assembly, I try and just write some code for it, even if it's a stupid little program that doesn't do much. I used to try and do a hex editor in every new language I learned, it was fun and challenging.

But also, things to remember:

1. Never stop learning. Also, realize you can learn from anyone even the "green" programmers. I think that I've tried to learn at least something from ever project I've been on.

and

1. Never stop growing. Don't get too arrogant to think you know it all, and stop trying to improve yourself.

Answer 225

1. Faithfully reading development blogs such as Phil Haack's
2. Reading Code Complete 2nd Edition
3. Attending developer conferences annually

Answer 226

I think that most effective moment in anyones career is the moment you decide to get out of your box and meet the real world!

Once you start reading blogs, listening to podcasts and actively include yourslf in the community - your skills will boost dramatically.

Answer 227

Blog!

Many people have mentioned reading blogs, but I think that's too passive.

For me, blogging technical topics has really helped boost my rate of learning, and also retention. As Joseph Joubert said:

To teach is to learn twice

It's important to note that I'm not talking about posting stuff like "silverlight sux". I mean set yourself the task of writing a blog post that properly explains the thing you are trying to learn.

Having to write about your learning is a great discipline, for it forces you to fill all the gaps and leaps of understanding in order to convey the topic well.

It matters less whether you have a real or imagined 'pupils', but if you write well enough then the readers will find you!

Answer 228

One of the most effective things that I did to become a better programmer was to get laid off in 2003. Once I saw how few jobs were out there for my slender set of skills, I started to work harder at growing (and maintaining) my skill set, both to get a new job then and to keep up my skills since then.

One thing I find helpful is to read a lot of programming books, and to do the exercises and type in the code in the examples - instead of just reading over them, sit down and work at them - doing the work by hand, typing it in letter by letter, helps you to pick up on where you're likely to make errors in the future - do you forget to put in ; at the end of each line, do you accidentally skip putting spaces in... and you also can figure out any system problems - if the code should work, because it matches the book, it can make it easier to figure out why Java's not working.

Reading blogs is good too - keeping up with what people are talking about in the biz is helpful to keep yourself interested and up to date. You may not end up using hot new thing X - but just hearing about it helps keep your brain ready for new things on the horizon.

Answer 229

I listened, attentively, to those who were willing to teach and show.

Answer 230

Going to local developer user groups and connecting with members of local development community. As great as it is to blog, read books, and well...do your job...there's something about going to a user group meeting, getting pumped up about a concept/technology, and going home and plugging away at it. Or just grabbing a beer afterwards and discussing tech with the fellow user group members.

Answer 231

Set aside some time every morning to do some study. In the past this was 30 minutes before I started reading email, now it is often reading books or RSS feeds on the bus on the way to work. The amount of knowledge you can accumulate simply by taking a small amount of time every day to study something new is quite startling. Equally, it is alarming how quickly my skills started to whither when I did not.

Answer 232

Lots of good answers in this thread so far.

I learned more about the art of software development, programming, testing and documenting in the first month of contributing/working on an open source project than I'd learned in about 5 years working in software companies.

Its hard to quite explain really why this is other than if you find a reasonably popular well run open source project, you tend to find many like minded peers who love to both share useful ideas and information as well as learn new things and push the boundaries of the art. You also get to read lots of existing code and documentation and see it being changed in real time to help learn new ideas and approaches.

Programming is such a broad topic from design, testing, technologies, frameworks, APIs, building tools, documentation, IDEs, patterns and being lean & agile to name but a few off the top of my head - its kinda hard to pick up this vast landscape from a few books or courses or to figure this stuff out all yourself; its better to just watch some highly experienced folks demonstrate it all in action on an open source project.

Answer 233

If we're talking about "the only" then it would be starting learning LISP. I got bored after two months, but LISP has prompted me to move onto OCaml, Haskell, Erlang... Each of those improved at least something in me.

Answer 234

learn another programming language and then go back to the first one later

Answer 235

Reading others' code and learning TDD.

Answer 236

Working with other people

It is useful even if they are not better than you are. You get to learn new ways of doing things, understand why certain ways of coding are just bad, explain why you code the way you do. This is essential !

Answer 237

to care about being better, and to be better means doing the Right Thing not just whatever works.

Answer 238

Take a programming/algorithms book,close cell phone,close door,sit at desk,
stay away from a computer and started reading.
I need to do this more often.

Answer 239

Learning about design patterns to reduce chances of duplication of code and thus embracing good software engineering practise in doing so has been the single most effective thing I am doing to improve my programming skills.

Answer 240

I took the Introduction to the Theory of Computing class at my university. It made me understand the math behind a lot of things. Or, more simply, it made me understand a lot of things. Now, when I design algorithms, I have a better understanding of the restraints I face as well as how to find approximate solutions to many unsolvable problems.

Answer 241

Doing Project Euler.

Answer 242

Visiting Stack Overflow of course!

Answer 243

Most of what I know I believe come from the blogs I read. You can learn a lot from the people out there.

I also try to read code written by others. Right now I'm browsing the code of ASP.NET MVC (amazing to see what's going on behind the scenes!) and AutoFac.

Sometimes it's hard to put into practice everything new you see, but I try to keep up with the new stuff (libraries, frameworks, etc) I consider most relevant, such as jQuery and ASP.NET MVC.

Answer 244

Never assume anything, sounds simple but I have found assumptions lead to bugs.

Don't be afraid to ask the community for help no matter how ridicoulous it may seem.

Reviewing other people's code, learn from their mistakes/genius

Answer 245

Programmed because I enjoy it and have a passion for it rather than just because it was a "job".

Answer 246

I would have to echo others answers here.

I think the best way to really get to know something (for me) is to pick a topic that you are interested in and unfamiliar with. Then look at how others have done that while you try to replicate/enhance it.

Currently, I have been very interested with low level systems programming, specifically the boot process of an x86. Looking at others bootstrap code has been immensely helpful in beginning to code my own.

Answer 247

Switching to linux.

Answer 248

Once I decided that my fingers are slower then my thoughts. I spent a week improving my typing skills.

The result was awesome! Programming became a pleasure after that.

Answer 249

1. Hobbying. My dad bought an IBM PC a few months after the original was released. Programming for fun taught me a lot and made it enjoyable.

2. My college thesis. It was hard, ambitious, and took 18 months of coding to complete. And I wrote it as member of a team of brilliant people (the MIT Media Lab), from whom I soaked up lots of things.

3. Math. As a physics major I had to take lots of math classes. As a result, I do not shrink back from tackling problems deemed to difficult by others.

4. Reading about patterns.

5. Learning UML.

6. Learning Perl. Comes in handy all the time.

Answer 250

The best thing I ever did was read Code Complete by Steve McConnell.

This had a massive impact on the way I wrote code, the way I thought about code and the way I thought about my career.

Answer 251

Hmmm - I think that the #1 single most important thing to improve my programming happened more than 10 years ago when I read the GoF Design Patterns book Although my skills have greatly improved since then by learning TDD, database design, IOC, DI, Agile processes, etc.

But those have all been a lot of small steps - the GoF book was a huge leap.

Answer 252

Write a new IT book, if you want to improve your knowlege and skills.

Answer 253

Taking the AP Computer Science courses in high school helped me the most out of anything.

I say that because prior to that I was self taught and would code in QBASIC as a hobby. I mostly just did my own thing, paying no attention to coding practices or readability. But in computer science I was taught C++ and the fundamentals of OOP.

Obviously I've done a lot to improve my skills since then, but some level of formal training can be extremely helpful to provide a little structure in your coding style. And on top of that I'm glad I had a good teacher to learn from.

Answer 254

Learning to say I'll get back to you on that when when pressured to answer the question How quickly can we do that ?

Answer 255

Pay particular attention to your life outside of work, and invest as much or more time in friends/family as sitting coding. How can you be good at work if your needs arent met outside of work?

Answer 256

Joining StackOverflow and seeing the huge number of outstanding programmers in the community. It was a kick up the bum and an inspiration at the same time.

Answer 257

Leaning Object Oriented Programming when I moved from C to C++
And the principle of SoC

Answer 258

Listening to DotNetRocks.

A number of years ago, after I started listening to each show during my commute, this podcast really unlocked a whole world of knowledge that expanded my understanding of software development, patterns, architecture, books, and the Microsoft community in general.

The quality may vary, but they still put out a lot of good stuff.

Answer 259

Reverse engineering. Looking inside massive compiled proprietary applications, and web applications from only the client side gives you a great view of how things are currently being done in the real world. Also teaches you what to avoid when programming.

Answer 260

Getting to 10,000 hours of programming... Experience and just do do do...

Answer 261

Mentioned several times and voted up, but without a doubt - working with smart(er) people and better developers has had the most impact for me. It gave me a chance to learn from them something I didn't know or how to do better what I already did know and motivated to work on my craft as a developer.

Also, there's a great book by Chad Fowler - "Passionate Programmer" - covers very well a lot of points discussed here, and I think very relevant to the discussion.

Coincidentally, my 2nd one would be being passionate about / liking what you're working on - nothing as motivating as labor of love. Once this happens, you do want to make your end product better, and this leads to trying better yourself as a developer.

Answer 262

I have some dissatisfactions against many inefficiencies in the internet world. These inefficiencies are usually gone if you start paying some money to the service provider, eg. stockcharts.com, where it provides more services.. But being a cheap guy, I started my own pet projects trying to mimic the provided services.

Lucky me, Google app engine provide free resources, from which i can start experimenting.

So I guess start with your own need and displeasure as (internet) user, and see what can you improve.. (i am stuck with app engine jdo relationship now btw..help...)

Answer 263

Learn to justify (in your head) other people's code. It's just too easy to hit programmer's block because of existing code is written badly and needs refactoring. Instead of immediately re-writing and re-testing everything, try to find some perspective from which that code would seem more reasonable. Your perception of code depends a lot on how you look at it. It can be hopelessly bad, or be slightly out-of-date at the same time.

Example: for a long time I hated visual studio .sln and .vcproj files "poluting" my folder structure. It bugged me that my main folder should start with some application specific configuration files. I saw other people's projects that had folder structures like:

ProjectA\
  ProjectA\
  ProjectA.vcproj
  ...
ProjectA.sln

And it made sence to me, simple and elegant. But still, for own "ultimate" projects, it was too poluting...

Well, finally I found a perspective, from which this folder structure made sence - think of it as a generic file listing. Those .sln and .vcproj are just some standard, that is common enough to be chosen for declaring all the files in all subfolders. Kind a like declaration of functions in c++ header files. It's just there for Your convenience, and at the same time it can be used for pre-compiling executable binaries from c++ code. Sure, it's xml-format is improssible to read or modify, but for now we can ignore that. As long as it saves time for us to start new projects we can live with it.

Answer 264

Studying "Software Engineering" at a Technical University.

Answer 265

Sorry if this answer is a duplicate (as I did not read most of the old answers with score less than 2) - in any case it combines some stuff from others (yes, I did upvote them):

1. Look back at your old code, and rewrite it (from scratch if it is horrible enough)
2. Read about design patterns and notice the ones you are prone to
3. do not re-invent the wheel. Ever. If there is a perfectly good freely available library for something USE IT, do not re-write it (unless you can convince the original programmer to accept your re-writing as the next major version). Using good libraries written by other people will teach you more than writing a shoddy one yourself.

Answer 266

I spent roughly six weeks working through one of Charles Petzolds great books, Programming in the Key of C#.

I went through it front to back, things i used to struggle on became a breeze and now I'm borrowing books about programming from the University library as often as i can.

For me the best thing to do was to just keep going, unless your forcefully try to learn something you're never going to make any advancements. It takes effort and patience which is well rewarded.

Answer 267

One thing that really improved my programming skills was watching and applying Misko Hevery's Clean Code Talks from the Google Tech Talks (available on Youtube, here's a playlist). They're presented in Java, but instill principles that can be applied to any OO language.

By getting into test-first-design I realised that code maintenance and maintainability was multitudes more important than just getting the first working version out. By applying TFD & TDD my code became cleaner, easier to maintain and had far fewer bugs than my non-TDD/hacked code.

I agree with the other comments about reading other people's code to improve your own coding, but one beneficial method was to print out some open source code and look over it with your development team and perform some code analysis. Find ways to improve certain code, find ways of refactoring the code to be more efficient and easier to understand. Look acutely at the variable and method names chosen in that code. Do the names of the variables and methods explain their function? Ask questions!

Answer 268

Creating 3D scene with phong/gourad lights and phong shading rendering terrain using only... setpixel - it was my university project, it was hard but I learned much

Answer 269

Learn languages other than object oriented languages.

One of the most effective things for me was one of my undergrad classes where we worked with functional languages, logic programming and constraint programming (in my case it was ML, Prolog, and the prof's own constraint language). With languages like Java and C# being all the rage today, it's easy to have a one track mind when it comes to programming, but I found it extremely beneficial to learn something totally different.

The other big thing for me was working with others that have more experience. When I was working as an intern I learned a LOT by reading code of the most experienced developers. Also learned by having the more experienced developers rewriting my poor code, so I saw first hand better ways to accomplish what I was trying to write.

Answer 270

1) Learned to use a good text editor for everything (Emacs)! You can become so much more efficient if you never have to take your hands away from the keyboard! Keybindings have made me a faster programmer! 2) Learned to use Bash to it's full capability. I can do things twice as fast because I do not have to code everything. I can write two small programs and send the output of one as the input to another using pipes. It is surprising how many good programmers don't know how much time can be saved using the shell.

Answer 271

Learning from mistakes and refactoring old code

Answer 272

• Make mistakes and take criticism as an opportunity to learn
• Learn how to read code and understand the original intent
• Learn when to ask for help (and when NOT to ask for help!)
• When to read books vs start hacking.
• Break the build...but please fix it :)

Answer 273

also innovative about doing something new. this is not a matter that you know much more and have a small knowledge. i am agree to doing practice. and also be passionate about your work.

Improvement + Innovative + Practice = successful programmer.

Answer 274

Interesting projects in new technologies (to you) are the best way to learn. I picked up C++ and Python because they were the best options for specific projects.

Answer 275

I accepted the patterns revolution

Edit

I know patterns always existed but we were not conscious of them in the way we are now.

Answer 276

On a long term: Constantly trying to adopt new technologies and development techniques. Also, reading Design Patterns by Gamma et al.

On a very short term: Getting away from my computer for a while. I often get the best ideas when I am NOT staring at the screen. Works almost every time I am having a hard problem to solve.

Answer 277

Reading Effective Java and The C Programming Language.

Answer 278

Network with other programmers. Nothing beats human interaction.

Answer 279

Debugging other people's programs. Teaching / tutoring. Playing with a lot of different languages. Reading books and tutorials and browsing the net. The greatest shortcoming of my professional development as a programmer was working in isolation. I could be wrong, but I think one of the best things you can do is find better programmers (individuals and teams) to work with and learn from.

Answer 280

Learning symbolic logic, particularly predicate and deductive logic. While studying philosophy I was able to immerse myself in this area of study and it actually pointed me to studying mathematics and learning to program.

This helped me learn programming since I almost saw it as a real world application of this logic. Specifically deductive/truth-functional logic helped me easily grasp boolean values, binary/ternary operations, and conditional statements, among other things. Studying predicate logic has helped me understand areas concerned with scope, object-relational mapping, and program flow.

This study of logic also pushed me into mathematics which also helped in a plethora of ways.

Answer 281

I wrote some coding standards documents for our company, presented them in a course and then set about reviewing code against them.

This involved time spent researching and investigating and documenting. It then involved time spent trying to format it into a manner than could be communicated and presented clearly. Finally, it involved reading other people's code, and learning to separate the good bits from the bad bits.

Answer 282

Writing your "programs" on sheets of papers b/c the access of a computer was the heaven's bliss and actually almost that rare... or storing the program on a cassette tape since the computer didn't have a floppy disk, or writing plain hex since there was not even a normal assembler. That's what makes you realize you do love programming and you are born with enough passion to do it.

---

But most of all reading books and later reading (others') source code, just try and play it in your head. Unfortunately, lots of nowadays open source code has quite appalling quality, however understand why (or if) it's appalling make a good starting point.

Answer 283

Using Excel

Using Excel every day helped me think about problem solving, with basic logical operators, IF() NOT() AND()

It also helped with the whole point of functions and variables, and showed me how to layout data that should be in a database. VLOOKUP()

Answer 284

Work for a small company - lesser layers of management and others bossing around - more responsibilities, more learning! This way, one can learn more in less time cos' small companies generally have a lot of work to be done in the least amount of time possible. No matter how you chose to implement the solution - that is where the 'learning' part comes in. Ask the great folk here at SO to verify your solutions and I always had people suggest most elegant solutions here.

---

I am with a small company, pay is crap but I have no boss. I am given requirements and I go about achieving those goals in the most elegant/efficient manner.

Answer 285

This isn't really specific to programming, but I like to hang out with people who are smarter than me and are willing to help. Whenever I come to them with a problem and ask them how they would solve it, their logic is what improves me. Learning to think in different ways, finding shortcuts (while still understanding why they work), and just improving yourself by watching others is the best way to get better at almost any skill.

Answer 286

Have an open mind. Be interested in other technologies. Don't be overly religious about your current favorite language or platform.

Answer 287

Reinventing the wheel many times, in the form of implementing all the kind of algorithms and programs I could find interesting, was very useful for me. Chess programs, device drivers, data structures, network servers, and so forth. About design skills, I think reading many RFCs is a great help.

Answer 288

1. USACO (train.usaco.org)
2. TopCoder (topcoder.com/tc)
3. Codeforces (codeforces.com)
4. CodeChef (codechef.com)
5. Project Euler (projecteuler.net)

Doing these problems help you face challenging tasks. And makes you confident with most of the stuff out there.

Answer 289

May be this sounds muddled, but I think it's important:

1. Code guidelines - formerly I named my vars like a = b * c, instead of more readable employeeSalary = avgSalary * fte, reused a code by copy-paste and did many other bad things in the code. My code was like a mess of unreadable routine. Learning of writing a beautiful code was not easy to me, but as soon as my code was more readable by me and in a team, I understand that I did less bugs. Now I write a beautiful code (thanks to Resharper) easy as one-two-three.

2. Usability and design - usually developers forget about this important thing. But knowledge about it may help to improve programming skills. How? This is fully connected to 'code guidelines' described above. A beauty not only in the code, but in user interface that you develop, has a good influence on developer's happiness, which in turn affects the quality of the code.

Answer 290

Reading "Clean Code — A Handbook of Agile Software Craftmanship" by Robert C. Martin. It made me aware of lots of characteristics of good and clean code that I din't even think of before. Absolute must-read!

Answer 291

I think you will learn a lot by reading books and taking a look on the code of open source projects.

Answer 292

The most effective thing I did to improve my programming skills was while I was in college I learned to teach myself any subject and not to rely on an instructor or a course to learn somthing.

Answer 293

Get your feet wet doing some basic "hello world" programs. Read programming books, read blogs, get to an intermediate level and do a lot of programming in different things, keep yourself challenged, pair program as often as possible, contribute to an open source project. Next, read "code-complete" Write more code, start to write good code.

Answer 294

Reading what other people had to say about good practices. Writing more code will only get you so far.

Answer 295

Working in the team which used Extreme Programming
Especially the following aspects of this approach

• Pair programming – the best way to learn biggest and smallest things from your fellow programmers that improve your programming skills, from advanced programming methods to using editor shortcuts that you would never be aware of otherwise
• Continuous Testing
• Writing self explanatory code that does not require comments

Answer 296

Find something outside of work that you can develop. I'm just starting to jquery and there are heaps of JavaScripts people have written that simplify tasks. I've been looking at these javascript files and learning how they work. I broad answer I was trying to get at was to use other people's work and incorporate it into your own (following copyright laws) Then understand how they they do. Good hunting.

Answer 297

As of c++: strict const correct code.

Answer 298

Typically, I didn't really get into languages until I dived in and started actually working with the code -- preferably, other people's code, so I could see how things actually fit together.

Also, from the first day in college classes, legibility was emphasized almost over functionality. Write code you can make sense of the next day. :-)

Answer 299

I found reading Code Complete 2 by Steve McConnell from cover to cover (and actually trying to follow most of his advice) has drastically improved my programming skills, especially since I don't get the benefit of working with other programmers in a large corporate environment.

Also, practicing good design (explained in the book) and analyzing other people's design is important to moving in the right direction, skills-wise.

Answer 300

I think the single most effective thing I've done is to force myself to use various languages and alternative tools on projects based on what fits best. IOW I tried to look at the capabilities of the language to see if it is a better fit than one of my standard choices. This has forced me to learn and use various tools based on their individual merits.

I try VERY hard to never stuff square pegs into round holes when it comes to my programming style also. We have many languages available to use because there are many different ways of doing things. The more I can understand about other styles the better!

Answer 301

One way to improve programming skills is to learn different business domains and how software is used to solve problems in those domains. For example, if you only work on business web applications, you may gain substantial knowledge of HTML, CSS, and relational databases, but not necessarily ever have an opportunity to master concepts like concurrency or 3D graphics programming.

Answer 302

Write a non-trivial app in multiple languages/systems. I've written a betting pool app in VB6, common lisp, java/jsp, java/spring/struts, rails, grails and django. I am now writing it in ruby/cocoa OSX

Each implementation is different. And I've learned how the systems differ from each other.

Answer 303

Working with a diverse set of more experienced and intelligent programmers.

People who say 'just write code' are being short sighted. I have seen many a project where someone 'just wrote code'. That doesn't give anyone insight to good habits and practical programming, nor does it help develop solid skills in the secondary parts of coding. Specs, documentation, clearly getting ideas across.

Answer 304

1. Reading the source of whatever (open-source) software is brilliant and important in your area of expertise.

2. Learning and appreciating different programming paradigms (i.e. OO isn't the answer to everything)

3. Writing libraries/components rather than monolithic 'systems', learning the value of interface design, documentation, conceptual simplicity.

Answer 305

Programming with at least one other (experienced) person, ideally in an Extreme Programming environment. Debating alternative approaches will assist in hashing out the pro's and con's of each.

Answer 306

Write lots of code as many already have written here.

But, write so much that you don't want to write so much more, get lazy basically, the first of the three great virtues.

"Brevity is the soul of wit" -- Shakespeare

Answer 307

I saw a huge improvement after I started learning how others (best programmers) code. One of the things I did is started watching "How do I" videos by the experts/gurus of any technology I am interested in.

I see great benefit in Learning Videos compared to reading a book. Not to discount the fact that reading books is a great way too. But videos are more interactive, quick and make a great visual impression (that is if the videos are good)

Tech Podcasts, dnrtv are my other favorites. Read this SO thread.

Answer 308

I always have a list of "small" project in my head. Every time I think of a "there oughta be..." I file it away for future use. Then, any time I come across a technology that looks interesting and I want to play with, I compare its features against my project list. If one seems like a good fit, I'm off to the races.

This allows me to always have something more practical than "Hello, World!" to work towards.

Answer 309

I think is important to improve your skill that you work on a proyect that really like you
an it's important share your knowledge you others.
on the other site you need to make some research on a topic that you need to know more about.
Finally work on an open source project has been very usefull for me as programmer.

Answer 310

Actually programming for a purpose. Once I started working and writing programs that would actually be used by users and not just handed in for a grade I started to get a better understanding of the impact my programs had. I was able see the big picture.

Answer 311

Doing fundamental computer science and learning that it's all the same. It all comes down to the same concepts and it's all built on logic and turing machines, and you can do it all the same.

Applying OOP to Assembly and Digital Logic is entertaining...

Answer 312

When I began to write code that looked "beautiful" and very clean, my programs started to work almost at first run, with very few bugs. If there are bugs, they tend to be very easy to find.

So I simply look for simplicity, cleanness, and beauty. :-)

Don't ever write code in a "clever" or complex way. Write as clean and readable as possible, and the programs just work and are easily maintainable.

Answer 313

Reading good books like Effective C++. Mind you, I had already programmed in C++ for several years, but it wasn't until I started reading good C++ and other programming books that I felt a jump in knowledge, which translated into becoming a better programmer.

Answer 314

Doing lots of code reviews with the principle that I wasn't done with the review until I found at least one piece to critique.

Incidentally, in many cases to be able to do such a code review I needed to sit next to the original author and ask them to explain the code to me line by line until I understood it. If you happen to be lucky enough to be asked to review code from great programmers, you will quickly ramp up your skills too.

Answer 315

For language proficiency, digging though the core API and writing code that utilizes each method/class. This has 2 benefits:

1. You learn the API, so you can stop reinventing the wheel.
2. More importantly, you get a good grasp of the major idioms of the language. This keeps your code clean and readable. Like when you finally stop trying to code procedurally in Lisp.

Answer 316

reading, working with others, and general get in and play with it :)

Answer 317

Anything that encourages you to write more code. I'm currently working through Project Euler to improve my skills, but I've also learnt a lot in the last year, just through looking at the codebase I'm dealing with at work. Also, reading more books doesn't hurt, although it's best to focus on Software Engineering ones until you know what languages you actually want to program in.

Answer 318

1) I made a lot of mistakes and learned from them by asking others or reading
1) Had a mentor
2) Listened to a lot of podcasts and then read up on the subject matters that I heard about
3) Paired programming
4) Reviewing open source projects for style and techniques (and investigating pieces I didn't understand)

Answer 319

Python Challenge

Answer 320

Writing code not only at my job but also at home. This has given me the time I don't have at work to find out very interesting and useful things.

Answer 321

Painfully copying the printed samples from computer magazines in the 1980's. Line by line. Only to figure out there was an error somewhere.

In general, reading other peoples' samples and modifying them; finding bugs in them; extrapolating from them.

Answer 322

Moving from the team I was lead programmer in to a new team which deal with a widely different technology I know nothing about.

And then doing it again after 2 years.

Answer 323

Wrote a Scheme compiler in C. Not only did I have to learn Scheme inside and out, but I learned all about compilers, how code is executed on hardware, how garbage collectors work, among other things.

Answer 324

As a lot of others have said, write A LOT of code, and ensure that you learn languages of a few different styles. By that, I mean don't limit yourself to languages that are similar. For example, if you know Java then learning C# will not be too difficult because there are quite a few similarities (automatic garbage collection, etc) but learning c++ after Java or C# will improve your skills much more because if forces you to think about your app differently. Also, learn to use the correct tool for the job. There is no point writing a simple file transform in Java when you can do the same thing with half of the code in Perl or with standard tools like awk

Doing things that were a challenge for me helped the most

Answer 325

In my experience:

• Practice heavy test-driven development (TDD) until you feel comfortable writing tests before actual implementation. It will make you a better programmer.
• Have pet-projects on the side or simply participate in open-source projects.
• Try to team-up with people better than you. Observe what tools they use and how they approach problems.
• Always find new things that keep you excited about programming. Be passionate.
• Create. If you're in just for the money, you can forget about being a programming guru.

Answer 326

• Making mistakes and learning from them - One of these was writing a prototype in three weeks which 12 years later I am still maintaining, because I allowed it to go into release, instead of re-witting it correctly.
• Doing algorithms 300 and especially order of complexity. In someways it is the bleeding obvious, but it crystallized in my mind concepts that I use everyday.
• Going back to basics and witting code to the OS and in 'C'. (This was partly a reaction in part to putting a a prototype into production.). Makes code so much faster and more robust. I think that as the improvement in the performance of computers flattens out, this will become more important in the future. I am not a big fan of frameworks. I suspect I am in the minority here, and might post this as a question later.
• Reading 'Code Complete'. From that the biggest thing was the layout of my code and the focus on simplicity.

Answer 327

Working on a variety of technologies and programs. The key is to continue trying new things, so I guess the ONE thing is challenging myself to do things that I have not done!

Answer 328

I read Effective Java by Josh Bloch. Overnight I was a better programmer.

Answer 329

A lot of people have said to program, and I agree. Specifically, I like to:

1) Do programming Competitions! I just did my first one this summer and it was actually pretty worthwhile (although I admit, I didn't do phenomenally). It forces you to work on interesting problems quickly. Google Code Jam is excellent for this.

2) Write algorithms I know well (sorts are awesome for this) in languages I've just picked up using the helpful features of that language to do it. It just doesn't make since to write an imperative sort in ML when the elegance comes from doing it functionally.

3) Talk to people who LOVE particular languages about WHY they love those languages. Rather than picking a side in the Perl/Python debate, I'd rather talk to a person from each side about why they like their language of choice and grab the useful bits for future reference.

4) Read Tech Blogs. You'll discover a lot about different languages by reading the blogs of the people who know about them. Of course, this applies to a lot more than programming.

Of course, these things tend to do more to make you a better programmer and may or may not help you with Software Engineering.

Answer 330

1. read research papers [ACM, IEEE] on topics that interest you

2. try to solve hard problems; even if you fail, you will learn from it

Answer 331

Figured out my learning style (or maybe my learning disability.)

I discovered that listening to people talk is the hardest way for me to learn. So classroom lectures, podcasts and videos are the least good way for me to learn and I don't waste my time even trying them if I can help it. I'm way better at learning by reading. So I buy and read lots of books and web articles. (You know. Sort of like this site.)

Just as there is more than one way to solve a problem, there is more than one way to learn. Optimizing what works for me has been the best way for me to improve my craft.

Answer 332

I tried to apply good programming technique to a language such as TI-83+ BASIC.

Answer 333

It is easy to get caught up in coding marathons. It is critical to stand back once and a while, look at how other people have implemented similar projects.

Read books written by excellent authors. Go through books such as "C: A Programming Language", "The Perl CookBook", or any of the best for your favorite languages. Read about the problems they solve, don't look at the code samples, write them up yourself, and then compare your code with theirs. Figure out why theirs/yours is better.

Answer 334

Used different frameworks, IDEs, operating systems, and languages. In general, if you're not confused you're not growing. The bad thing is not to be mediocre. The bad thing is to be mediocre when you think you're great.

Answer 335

1. I joined developer centric communities web and physically
2. Read/Try to read other people's code.
3. Write code.
4. Read read read (Blogs, podcasts, books etc.) and do do do what you've read read read.

Answer 336

Reading lots of books and articles..

Answer 337

Read more books, and write more codes.

Answer 338

I think the biggest thing for me was when I took a step back from implementation and started looking at the bigger picture, and better understanding architecture, patterns, processes, requirements analysis etc.

Answer 339

I'm sure this is simply reiterating previous comments:

1: Read code from numerous languages. Understand how the language handles a given situation. It may make you more enlightened in the language you are looking to become better at.

2: Teams...Debating programming practices, approaches, testing, planning, implementation, etc.

3: Use the above to focus on a smaller set of languages.

4: Never assume your 100% right, then you'll have no reason to question anything.

Answer 340

working with people far smarter than I

Answer 341

Use your computer and understand it thoroughly.
Write code for whatever you thought you can.
Read good code and learn how to write. Read bad code and learn how not to code.

Answer 342

There are many things but the following had great impact on making me a better programmer

1) During university days, I was in a continuous competition with a highly talented classmate for creating the best game/program judged by other classmates. It was like 2 small start-ups fighting for market share.

2) Reading "Deep C secrets"

3) Participating in Open Source projects where smart people can comment on your code.

Answer 343

When you are programming alone, it is very easy to assume that the things that come easiest to you or which seem most obvious are therefore the best. However, when you are in active contact with a group of knowledgeable others (especially ones that have more experience than yourself) you will probably find many problems that you never considered, and solutions to them that might not have occurred to you either. It is much better to learn from someone else's experience than to make your own mistakes and by doing so screw up an important project (of your own or of your employer's). If you can learn these things from your peers before you are ever confronted with them yourself, you can avoid many early missteps that catch most programmers unaware. It is possible to become a programmer with a junior amount of experience but a senior's understanding of software development if you pay enough attention to what other more experienced people are doing.

Probably the most useful thing that I did was to spend a few years reading online forums such as comp.lang.c, comp.lang.c++, and comp.lang.java regularly (on a daily or at least weekly basis), and participating in forum discussions. (In the day when I actively frequented forums, most of them were on Usenet. Now, they tend to associate with specific websites and developer communities.)

In active discussion groups such as these which attract large numbers of professional developers (and in particular high-level professional developers, such as language authors and the implementors of important libraries) it is much easier to get a sense of which programming techniques are considered useful versus discouraged, and which programming languages, tools and libraries are coming into favor or out of favor. Also, it's useful to pay attention to what software engineering techniques other professionals are using, ranging from version control systems to visual modeling languages to programming methodologies and so forth. Learning which areas are controversial is important too -- Watching an extended debate between two high-level experienced developers with markedly different views can be a tremendously educational experience.

You may find after a while that your favorite language or programming approach is not as universally liked as you at first believed, and you may find you are starting to consider alternatives -- that is good! That means you are starting to become more nuanced and more realistic about your beliefs (rather than just adopting the latest fad), and hopefully expanding your horizons to include different ways of doing things.

Answer 344

Spend some time actually thinking about it, rather than just doing it.

ie

think about what skills you have.

think about what skills you dont have.

think about what skills you would like to have.

think about what skills you think the industry would like you to have.

Answer 345

Learning a new language a year has been great (Although I learned 3 languages last year alone). I still prefer C++, but knowing different ways of solving things has improved my coding skills in many ways. That and I have a series of "Katas" or small coding goals I keep trying out on my spare time, each time applying my new knowledge to them.

Answer 346

Work with the smartest people I can and ask them questions. Don't be afraid to ask.

Someone should build a website to do that...;-)

Answer 347

Participating several times in ICFP Programming Contest.

There is no other programming competition like that! Every time I learned a lot. Especially working in a team with people much smarter then I am.

Answer 348

I read K&R2 for a 2nd time. And then read it again a 3rd time.

Answer 349

Back in elementary, I wanted to create a fake login screen that would steal passwords from my dad's office PC. It was just a batch script that run on MS-DOS and there was nothing fancy. Then, in high school, I went on to write simple MSWord macro viruses because I found it fascinating to be able to "customize" MSWord according to my liking.

The programming skills that I learned then were just side-effects on doing something that I found fascinating.

Answer 350

There is no single think you can think of to improve it. its a learned skill. it will make u better by practice. By practice i don't mean of single attribute. the most important attributes i can think of are 1. Write code 2. Pairing or collect persapactive from different ppl (activity like coding dojo -http://www.codingdojo.org/). 3. code review

Answer 351

Working in pair programming with a 50+ programmer who is an expert on Smalltalk. We were programming in java, but I really learned a lot about object oriented design and debugging techniques.

Pair programming with an experienced mentor is something to be recommended, as long as we keep an open mind.

Answer 352

Working with people who are smarter than I (not that hard) and being curious about how thy do stuff. Reading a lot helps, but you have to be able to find your own way on how to solve things.

Answer 353

Working with another people was the single thing that made my skills to explode. I started learning from their failures. :)

Answer 354

code a lot don't be afraid to learn new things

Answer 355

I know most of these have been previously mentioned but I will reiterate them again as they have worked for me.

1) The most important thing is to have an interest in what you are doing. If you are interested in it you are half the way there. Nothing kills your desire to work/improve more than disinterest.

2) Find someone in your organization that is smarter/better/faster than you and absorb as much of their knowledge and expertise as you can. This applies to anyone, junior/senior/etc. Job titles are entirely meaningless as far as I am concerned. I've seen "junior" level developers who had far more expertise/knowledge than supposed senior level ones.

3) I've tried as best I can to follow my own Code of Coding. Write, Read, Analyze, Review, Discuss. Once you Write your code, Read it over. Is it maintainable? Is it commented well? Does it look like it does what it should? As part of this you need to Analyze the code. Is this the best way you could have done this? Could it be improved in any way? Make changes accordingly. Next, Review it, test it out. Does it do what it should? Does it do anything it shouldn't? Do your best to try and break your code. Once you are happy with it, Discuss your code with others. What is their take on it? Do they or Don't they agree with your decisions? Have they any other ideas on what could have been done to improve it.

4) Always be willing to learn new things and/or idea's.

Answer 356

Started teaching programming and program design. I was mostly clueless about OO until I taught a Freshman-level Java course and a Junior-level Software Engineering course.

Answer 357

Using my brain, instead of hammering out pointless code. Code once, code correct.