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.

Edit: Wow - what great answers! Keep 'em coming people!!!

Answer 1

Writing code and lots of it.

Answer 2

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 3

Pair-programmed with very diverse and opinionated people

Answer 4

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

Answer 5

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 6

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 7

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

Answer 8

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 9

Competing in TopCoder Algorithm contests.

Answer 10

Learned Scheme.

Answer 11

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 12

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 13

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 14

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 15

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 16

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

Answer 17

In no specific order...

• 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

• working with people far smarter than I

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

• Disagreeing with everything Joel says. ;)

Answer 18

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 19

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 20

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 21

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 22

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 23

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 24

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

Answer 25

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 26

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 27

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 28

The obvious answer is:

Learned my first programming language.

Answer 29

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 30

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 31

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 32

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

Answer 33

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 34

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 35

Answer questions on StackOverflow, of course!

Answer 36

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 37

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

Answer 38

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 39

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 40

As of c++: strict const correct code.

Answer 41

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 42

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 43

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 44

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 45

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 46

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 47

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 48

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 49

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 50

Stopped writing procedural code and started creating objects.

Answer 51

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

Answer 52

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 53

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 54

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 55

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 56

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 57

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 58

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

Answer 59

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 60

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 61

Math degree.

Answer 62

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 63

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 64

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

Answer 65

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 66

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 67

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 68

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 69

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 70

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 71

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

Answer 72

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 73

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 74

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 75

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

Answer 76

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 77

Learning FORTH

Answer 78

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 79

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

Answer 80

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 81

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 82

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 83

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 84

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 85

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 86

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

Answer 87

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 88

Python Challenge

Answer 89

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 90

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 91

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 92

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 93

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 94

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 95

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 96

Learning to learn from the mistakes of others.

Answer 97

• 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 98

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 99

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 100

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 101

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

Answer 102

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 103

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 104

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 105

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

Answer 106

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 107

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 108

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 109

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

Answer 110

Writing and knowing exactly what each command you typed do

Answer 111

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 112

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 113

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 114

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 115

Reading lots of books and articles..

Answer 116

Read more books, and write more codes.

Answer 117

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 118

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 119

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 120

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 121

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 122

working with people far smarter than I

Answer 123

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 124

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 an 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. Game's 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 are great sets 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 125

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 126

Going to a good university.

Answer 127

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 128

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 129

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 130

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 131

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 132

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 133

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 134

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 135

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 136

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 137

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 138

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 139

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

Answer 140

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 141

Learning vim

Answer 142

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 143

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 144

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 145

Learn Haskell.

Answer 146

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 147

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 148

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

Answer 149

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 150

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 151

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

Answer 152

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 153

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

Answer 154

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

Answer 155

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

Answer 156

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 157

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 158

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 159

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

Answer 160

100 % unit test coverage.

Doing unit testing have really improved my programing.

But using a code coverage tool to measure the coverage of the unit test takes it to another level.

A good exicise is to take a module and try to make a 100% unit test coverage.

You might even make a friendly competition with your coworkers by taking a module each and see how can get the highest coverage.

--

Follow me on CrowdNews.eu

Answer 161

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 162

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

Answer 163

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 164

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 165

Started writing code for real. The code they have you write in school is nice, it teaches you some of the functions of the language. But, to really write code to business specs, it's different. I would say that I really didn't become a good coder until a couple years after I had to start writing stuff that other people had to maintain.

Answer 166

A lot of reading and learning assembly.

Answer 167

couple of things..

1. Reading others code.
2. Working with smarter people than you & learning from them...
3. Working on variety of different platforms and different domains.

Answer 168

I had a keen interest in software process improvement after completing a masters degree in computer information systems, and studying about the Capability Maturity Model in one of the courses on the Software Lifecycle. Since the company where I worked was located in Pittsburgh, I attended Software Engineering Process Group meetings that were held monthly at the Software Engineering Institute. Watts Humphrey came to one of the meetings and did a presentation on Personal Software Process shortly after writing the book, and so a work buddy (Jim) bought 2 PSP books (one for him and one for me) at the CMU bookstore. We started doing the excercises together during lunch, and started applying the stuff to my work.

Completing the programming exercises along with the process material from the Introduction to the Personal Software Process book was the single most effective thing I did to improve my programming skills.

Answer 169

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 170

an open mind.

be critical at everything what has been written. and perhaps the most important thing, sometimes it's better not to develop.

we are already implementing everything while a simple pencil and paper works better.

Answer 171

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 172

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 173

I remember getting grueling code reviews where my boss made me think about every line of code, and taught me to be critical of every line. Now I'm a paranoid sob in exchange for less buggy code.

Answer 174

Well... For being someone without a lot of experience (I'm fresh out of university) I still must say that what changed me the most was when I started unit testing. It made me write much better code.

Answer 175

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 176

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 177

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 178

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 179

Learning how to write short, understandable comments.

Answer 180

Being Passionate

I'm not talking about the kind of passion where you're annoying and saying, "Hey everyone look at me.... I'm passionate!"

What I'm talking about is possessing an energy that makes you want to do the tasks that everyone else shies away from. It's a sacrifice for the greater good of the company and this will get noticed... it's unavoidable.

Examples might be:

1. Working on the build system (or being the one who spear heads it)
2. Digging into legacy code to figure out a nasty bug
3. Doing more QA type services that are not necessarily expected of you
4. Etc...

When one can do these types of tasks without making a big deal out of it, it tends to go much further then if one tells everyone about all the great things one's done. All of this seems to start with passion.

Answer 181

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 182

Jump into something I don't know, try to code. If I don't know how to do something, look it up, then ask questions of others. Looking to coworkers for pair programming or asking why certain things are coded the way they are helps you out by finding the history and trying to think of how to rework the way their code works.

All in all, experiment and don't be afraid to make a mistake... especially in a test environment. It's there for you to wipe out every now and then

Answer 183

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 184

Reading Code Complete

Answer 185

Give trainings. You wouldn't believe how much new stuff you end up learning when the pressure of being an "expert" for a day hits :D

Answer 186

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 187

1) Write code.
2) Read Code Complete.
3) Write code.
4) Keep reading and learning.
5) Write code.

Answer 188

personally i could not answer. However, as a group learning techniques, we've implemented weekly coding dojos and weekly lightining technical talks - be it about a particular library, language, tool, whatever is pertinent to our skillset.

Answer 189

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 190

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

Answer 191

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 192

Some of the effective ways to improve your programming skills

1. Make sure you have set of good developer's blog feeds in your feed reader and make sure you browse through them atleast once a day.
2. Listen to good podcasts.
3. Mentor people !! (surprisingly it does improve your programming skill)
4. Make sure you always work on a pet project apart from your normal project work.

Answer 193

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

Answer 194

A programmer needs only to solve 'unsolved problem'.

Do not reinvent wheel.

Answer 195

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 196

Take up a role where you are purely testing for a few months / or do a significant body of testing on someone elses application.

This will give you a much better perspective on what a user wants\needs\worrys about when using an application.

Apply this when you develop your own applications.

(yes I know testing is not popular/fun, but I've found that ex-testers make the best coders from the point of view of giving the customer what they want)

Answer 197

Learning regular expressions .

Answer 198

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 199

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 200

What helped me significantly which I feel is relevant was pushing myself out of my comfort zone as often as I could.

Just because you can do something doesn't necessarily mean your getting better at it. Think of it like working out in the gym only using your mind. Break a mental sweat as often as possible.

Answer 201

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 202

Reviewed Code and let my Code get reviewed

Answer 203

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 204

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 205

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 206

creating games was the best thing I ever did. now competing on spoj.pl and topcoder.com is the best thing I am doing ;P

Answer 207

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 208

Understand the hardware that runs your program, understand the people that will use the program and test every day if your knowledge of both of them is up to date.

Answer 209

I adopted different methods. 1. Doing actual programming (especially working in diverse range of applications and languages helped) 2. Learning and reading programming/software engineering books and applying knowledge (as people often just read it) 3. Learning and modifying frameworks. 4. Learning from senior fellows (wherever they are) 4. I used to be a teacher as well so i learn quite a lot from my students and their questions. 5. Never restricted to any platform/language , so got diverse thinking and always apply my experience to use one across the board. 6. And the final "Never Stop Learningg whatever offer" ?

Answer 210

RTFM and practice, practice, practice!

Answer 211

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

Answer 212

Switch Industries every 3 years.

Answer 213

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 214

Understand that knowing what question to ask is more important than knowing the answer (that's what Google or sites like this are for).

What is the best design pattern?

What regular expression...

How should I test...

Once you get that, life as a programmer becomes a lot easier.

Answer 215

Read Code Complete by Steve McConnell

Answer 216

The single most effective thing I do to improve my programming skills is read books. Not reference manuals or how-to-do-something-in-x-days books but books about best-practices, etc. Like these...

http://www.codinghorror.com/blog/archives/000020.html

Answer 217

Practiced.

Answer 218

Maintaining a constant curiosity and a passion for learning. Observing my bored co-workers stuck in a rut is a great motivator for maintaining that on a daily basis.

Answer 219

Programming! I love this, anyway, so I do it at work, and at home, on open source projects or my own little projects. I keep learning, new languages, new algorithms, new APIs, etc. The only problem is that days are too short... :-)

Answer 220

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 221

The single best thing I did for my skills? I taught for a few years during the economic downturn. (Finding "real" programming gigs was tight in late 2001!) By teaching for a few years, not only did I have to learn and know my craft at a way deeper level than normal (thus being able to explain it to other talented coders), but I also had to learn to think like a compiler.

That was the biggest benefit. I can often read a chunk of C# or VB .NET code (my strongest suit, and that which I was teaching) and determine beforehand whether or not the code will compile, and what the effects will be if it does. This helps me out on a daily basis when maintaining my clients' legacy codebases -- especially those I didn't build!

Answer 222

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 223

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 224

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 225

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

Answer 226

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 227

I decided to get better. It's easy to figure out where your deficiencies are, and it's even easier to ignore them. I read Bill Wagner's "Effective C#", and anything else I could find. I remember I was working this contract and I wasn't getting along with the internal staff, and the other consultants on the engagement were blatantly stealing bad code snippets from CodeProject and billing the client for a full day's work. I felt like there were enough poor developers out there and I wasn't going to be one of them. I always felt like I was a good developer, probably because I was just tenacious, but on that contract I made the decision that I was going to work on the hard parts, the uncomfortable parts, and that I was never going to stop learning how to do things better. Since then, I strive to live up to a standard, as Phil Haack said, "compared to yesterday, I'm always a bargain".

Answer 228

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 229

I started programming about 25 years ago when programming was not taught in classes anywhere and whaever you learned you learned by reading and trying it out. All this really to say that programming was never a job for me... Even now that I work at a large company writting code and designing solutions all day long it's still a hobby for me - something that I love doing more than anything else in the world...

So the answer is I never had to decide to do anything special to get better at programming I always did it because I loved it so I always have been in the learning mode for more than 24 years now and I still learn new stuff almost everyday!!!

Programming is AWESOME!!!!

Answer 230

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 231

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 232

Typing in crummy BASIC games from magazines, and then writing my own crummy games.

I'm a big fan of not reading code, but typing it in. For me the code is more real when I type it in because I "read" it slower and trying to understand it as I go. Downloading tutorials and clicking on buttons never really did much for me.

Answer 233

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 234

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 235

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 236

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 237

Wrote code and took an interest in improving it.

Answer 238

Having a background at mostly Perl, PHP and C++, I once started learning Common Lisp. This lead me to learn functional programming and metaprogramming, which dramatically opened my mind.

Answer 239

To boil it down into a few sentences and echo some things I'm sure others have said (didn't get a chance to read ALL the answers):

1. Try new things. See a little blog post somewhere about erlang and it sounds kinda neat but you don't have any specific or practical use for it at the moment? Spend a day goofing off with it anyway. You might never use it in a real project, but the extra perspective will help more than you realize. I actually have a policy wherever I'm working that anyone who works for me (who are mainly software engineers) HAS to spend Friday working on whatever they want, and a big reason for that is specifically this point.
2. Sounds silly, but talk to people who aren't programmers but involved in the same projects/products/companies as you. Get perspective. Learn WHY somebody would want to do something, have a feature, etc. and how it would impact them. I've found this generally leads to designing more practical and well thought-out software, which requires you to think about it a little harder and thus, learn new things.

Answer 240

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

Answer 241

In my opinion, the most important bit is to keep you mind flexible as the decades whoosh by. I see so many people who are unable to embrace anything new, as they forgot the principal rule of IT: everything changes. If you lose the ability to learn and change in an environment that changes rapidly, you will soon end up fossil-minded.

I personally like competitions like google code jam, topcoder.com, projecteuler.net - it really keeps you CS skills in shape. The rest - it's just reference. After using a few OO programming languages, the rest is pretty much the same. It's all the same in the end. It's easy to learn the N+1. th language. But paradigms, algorithms and the rest don't change all that often.

Answer 242

Hello!

Improving my communication skills with bosses, other programmers and customers

This was my most effective thing to learn. Back in the beginning of my career, I usually thought I understood my boss or a client, when they told me, what feature etc they wanted in the program I was coding. But usually I did not completely understand, what they really wanted, because we usually have different views of things - this is especially true for non-coders!

But with each project and with each mis-communication I learned to listen more specific, to ask for more details and to let the other person explain their ideas in full and to make sure to visualise their ideas with simple sketches - so today I spend a lot more time to make sure I understand the task given, but I save a lot of time and frustration with coding things that were neither wanted nor asked for.

Best regard, B

Answer 243

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 244

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 245

Learn Lisp or Scheme

Answer 246

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

Answer 247

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

Answer 248

1. Working with developers more experienced and smarter than me.
2. Mentoring developers less experienced than me.
3. Paired programming
4. Code reviewing other people's code
5. Learning new programming languages
6. Writing cross-platform code
7. Coding for fun

Answer 249

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 250

RTFM, everything else had to wait until I figured that one out.

Answer 251

For me, it has always started with an idea and a problem to solve.

For example, I had learned C in 9th/10th grade on my own, and then wanted to learn this "C++" thing. I had an idea for this simple little "Quote of the Day" app that would greet me when I booted my machine (this was back in DOS and autoexec.bat). I realize it didn't have much to do with OO but I used it as a challenge to begin thinking that way and wrote the app.

I often meet programmers today who seem overwhelmed by the sheer size of the frameworks and other "stuff" around the languages and what not today. It almost paralyzes them from really exploring because the fear of the unknown stops them from spelunking.

When I didn't know how to open a file and read its contents (for my quote of the day app), I started digging (The Programmer's BBS! and spent way too much at B. Dalton/Waldenbooks back in the day.) for answers and ultimately rigged up a solution. I have also always been interested in the best solution, so when I would find a better way to do it, or learned that I had maybe not solved a problem appropriately I would refactor my code.

Start with an idea, a problem, and then write code.

Answer 252

I definitely support Aaron - being a better programmer involves solving problems, not reading about the language. For me the key event was my Latin course back in school. Each "feature" in Latin was explained in our textbook by a text solely constructed of the new grammar style, e.g. a text with an "ablativus absolutus" in each and every sentence. Wow, how I hated this. After sometime we moved from the textbook to Caesar and - BOOM - he wrote about history and I simply wanted to dig through his stuff, so I wanted to read and understand him. No artificial language any more but I created a self interest.

For me it is exactly the same with programming. It's nice to know, that a certain feature exists, but you can grasp it fully, if you use it to solve a problem, even if it's a problem you just thought up for training.

Think about a nice simple tool and hack it up in your language of choice. That's learning how to program!

Answer 253

Learning a unit test framework and integrating tests into everything I did. My code quality went from so-so to sterling in a matter of months. Learn from others who are successful and read lots - the pragmatic programming series of books are great for tips and tricks.

Pragmatic Programmers

Answer 254

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 255

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 256

• Learn a new programming language every year. Include some very different, non C based, languages like Lisp.
• Write articles and present at user groups. There is no better way to learn something than having to explain it so someone else :-)
• Focus on problem solving skills instead of technology. The latter changes every few years anyway :-)
• Pair programming.
• Listen to smart people (and know when to ignore them).

Answer 257

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 258

Diversify your logic training. Any chance you get you should branch out and really explore as many other logic based disciplines as possible. It can be surprising how learning the techniques of another field can help you bring fresh insight into algorithm design and help you approach programming problems from a new perspective.

Answer 259

Read.

Back in the early 90s, I remember reading a column in C++ Report that said if you read one book per year on your own time you are ahead of 90% of your peers. It stuck with me and helped motivate me to read a lot on my own time, which helped me a lot in my growth as a developer and in my career.

Answer 260

I got myself into the habit of writing pseudocode or otherwise planning the LOGIC before starting to do actual programming.

Answer 261

Two things together:
1. Stopped (actively) programming
2. Learned security.
And then there can be 3. Go back and start programming securely. I did this when I went to become a HPC(/security consultant), and I highly recommend it.

I know, I'm a bit of a security bigot - but seriously, secure code IS better code. Works better, usually performs better, by necessity has fewer bugs, and is overall more thought out.

And in addition, I had to learn a lot more about, well, everything, things I'd never touched on while programming and things I would have never experienced. Not to mention reading HUGE amounts of MANY other peoples production code - the good, the bad and the ugly - and seeing the results of the difference between them. This also forces you to think about EVERYthing up front, in very short time frame - so you're virtually guaranteed that your design is solid from the ground up.

Answer 262

Watch all of the SICP lectures and learn to program in the way that they do.

http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/

I've known rudimentary Lisp for half a year now and programming for 1 and a half years before that. Right now I'm starting to watch the videos, and I'm almost certain I'll watch them again in a few years to refresh my memory. They're entertaining, interesting and mind bending of the way you think about programs.

Answer 263

During my university days the single most course that improved my programming skills the most was the data structures and algorithms course. I chose c++ as my language of choice and it was a classical experience.

Answer 264

On each project I try to use a new technique or apply a different design pattern. I also go back to older code and re-read to see what areas of opportunity I missed try to match those items with new things I have learned. I also read, read, read programming blogs and books.

Answer 265

Hiring really good developers and working with them, as much I was able to.

Answer 266

Learning vim AND regular expressions well.

Answer 267

Started reading the development blogs. It's almost too much information and I doubt I'll ever get to even 25% of the stuff I bookmark but it keeps me up to date and excited about development every single day and because of that I'm a better developer.

Answer 268

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

Answer 269

Be responsible for both writing and supporting the customers who use the code you write. Any lack of quality will be your own job to fix, you get the irate calls, you soon learn to make the code better.

Answer 270

Worked with other developers. Moving from a small 2 person development department to bigger outfits really opened my eyes in terms of different ways of approaching problems, different coding styles etc.

I'd say that was the "Single most effective" thing for me.

Answer 271

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 272

Just love your job, and you'll improve. If you wake up every morning in bad mood because you don't want to work, then leave your company ! Your work is 50% of your life, if you don't enjoy it you'll never improve.

Answer 273

I've found that I can read about something and I'll remember some of it. But to really make it stick, I need to work on a project using it. This forces you to get into the details of how it works and then you have experience to lean on instead of just trying to remember something you read.

Answer 274

Teach. Become a resource for other people wherever possible, and you will learn to think of things in different ways as you try to understand why their mental model doesn't match yours. Find ways to give speeches, tutorials, etc. You'll find that teaching a topic well requires mastery.

Answer 275

Learning BNF (Backus Naur Form) and its various dialects, brought my understanding of computer languages in general to a whole new level. Making my first compiler (a really simple script compiler) sky-rocketed my skills.

Answer 276

Working with developers that are better than you is extremely important to self-improvement. They can provide valuable critiques of your code, and impressing them with your code and other contributions will push you to become better. They also provide positive examples of good code, time management, documentation, etc. If you are the best programmer in your company/project, it will be more difficult for you to improve. There is usually someone around that is better at some aspect of your job than you are. Watch them to figure out how they tackle problems and ask them how they learned to do it.

Answer 277

In inverse order:

• Programming
• Thinking before starting to program
• Discussing my thoughts with other developers

Answer 278

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 279

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 280

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 281

Loving what I do and striving daily to learn, learn, and then learn some more.

Answer 282

If there's something I can't do, and I know someone else can, I usually ask them to do it for me the first time, and then try to do something similar looking at their code. This is how I learned MySQL, OOP, a whole lot of machine learning, version control... the list is pretty large. The good thing about having a person do it instead of a textbook is that you can ask them specific, pointed questions about their code should you get lost, and you don't have to skim through three pages of discussion around a piece of code, like you would with a textbook.

Answer 283

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 284

Not being afraid to say or suggest dumb things.

A good listener (dev + team player) will tell you why it's not such a good idea and you learn heaps from the experience. Kind of like not being afraid of rejection. Use it sparingly, though. ;-)

Answer 285

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

Answer 286

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 287

I realized that I had a problem understanding the more advanced topic in software design, so 8 years after completing my bachelor degree I signed up for a number of cources at one of the IT universities here in Denmark. I have often heard that the subjects was only of interest for academia and was of no use outside campus. In this case those rumours were dead wrong, as most of the stuff can be used in real life. Both the SQL and Advanced Design Patterns classes were excellent. Btw. I totally agree with Bill the Lizard, teaching forces your to KNOW your subject in each and every detail.

Answer 288

Locate and attach the fellow travelers in your area. If you don't have a Group or a community that meets regularly to support, challenge, teach and learn from each other, start one. If they don't know more than you, they know different from you, and for that, each and every one of that community is priceless.

What also works for me is to have at least one thing I'm working on, always, to get better. Whether it's working through a book, or doing a project, or downloading some cool thing and playing with it.

Answer 289

Reading others' code and learning TDD.

Answer 290

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 291

I've been programming in various languages for about five years, and I have to say that the single most important thing I've done to improve my skills is to simply keep doing it.

Allow me to illustrate with a (true) story.

---

Improving my coding skills

The first time I did any programming was a small personal website for my Bar Mitzvah (with which I managed to make half my family mad because I didn't bother with paper invites). That was simple HTML and JavaScript, and I hate to say that a lot of the HTML -- at least initially -- was done in FrontPage. And I used frames.

Next, I made up a small site for a project I was doing with a friend, and based the first version on my Bar Mitzvah site. Still with frames. But I wrote my own (insecure, yes) JavaScript password handler with only one or two hard-to-debug errors (a mismatched brace).

Fast-forward to me learning CSS for the second version of that project site. I redid the entire thing, HTML and JavaScript, to be single-page (no more frames!) and tweaked the password handler some more. Then I discovered that the server I was using had PHP installed. So I looked up a reference (I think it was php.net) and started teaching myself the language; I learned the basics in about six hours at a coffee shop while I was supposed to be doing my homework.

From there, I developed the site template system and coding practices I have used and evolved since then into the Southwest Robotics Team website.

---

So, it was just a matter of just continuing to program for me. I've also talked to other programmers, read books, looked at the source for everything I could (at least HTML, CSS, and JS), and played around for no reason sometimes. It's definitely worked for me; I'm only learning more stuff (my knowledge regular expressions, for example, actually started with me using AutoWikiBrowser on Wikipedia).

Answer 292

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 293

1. Don't be bashful. Ask questions no matter how dumb you feel they may be.
2. Code as much as you can. The more you code, the more mistakes you are going to make, but as you progress, you will notice that your mistakes start to lessen.
3. Read books, blogs, forums.
4. Listen to podcasts, watch videos.

Answer 294

Watching the SICP videos

Answer 295

Never walk away from a coding challenge.

Solving the unsolvable will work magic for your confidence and reputation.

Answer 296

• Curiosity

Wanting to know, how it works has probably got most of us started in this field.

• Quality

When you have done something and dont feel right about, and regardless of advice the people around you give, you keep searching for a better way to do it, until it "feels" right.

Those are the two things that have indirectly caused me to question things, and learn a lot.

Answer 297

I forget who first said this but "try to learn a new language a year". I think it helps you to approach writing solutions from a number of different angles.

Answer 298

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

Answer 299

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 300

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 301

Working on and founding a lot of Free and Open Source Software projects...

There has been nothing that have helped me out more then this...

Answer 302

Some great answers in here and definately some things I should try out.

One thing I do sometimes is code with no aids at all. So no warnings, no stylecop, no fxcop, etc, and my profiler (ants) not running.

That way I see just how good I am without aids. It's like riding a bike with stablisers, and then having them taken off.

But when I am writing code for commercial-intent I turn all these aids/tools on and improve my code where necessary.

Answer 303

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 304

When coding, thinking like a von Neumann machine.

Answer 305

Besides writing alot of code , i think understanding everything i wrote actually helped quite a bit. There are too many copy and paste coders out there.

Answer 306

Doing Project Euler.

Answer 307

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 308

I worked for 2 years with someone remarkably more intelligent and well-versed than myself. I'm sure he became frustrated at times, but through that work relationship I was able to develop a perspective on application design and development. I stopped just going through the motions. Approaching design and development from a more well-defined position has made all the difference.

I hope that answer isn't too abstract.

Answer 309

Visiting Stack Overflow of course!

Answer 310

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 311

Always go a step beyond what's required.

If a project requires a new technology, rather than asking for training, I'll study some existing code and documentation, then start a pet project on my own. It's always good to have suggestions beyond what others have considered.

Never leave a question unanswered if you can help it. Always satisfy your curiosity. Chances are you'll learn a lot in the exploration.

Answer 312

Fixing/enhancing other peoples code.

Answer 313

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

Answer 314

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 315

Having an open mind all da time!

Answer 316

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

Answer 317

Try not to build anything you design for a few weeks. Often other scenarios will come to you then before things get locked in.

Answer 318

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 319

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 320

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 321

Switching to linux.

Answer 322

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 323

Learning as many languages as possible.

Answer 324

Code Reviews: We implemented code reviews within our team. We read other people code beforehand, then all the developers sat in a room on a Friday afternoon and the person who wrote the code explained what they did and the reason why they used that approach. When I came over similar issues later on it definitively helped me look at things in new ways.

Arguing: Even though it sounds a bit strange but arguing with colleges. When people have different ideas about the best approach to take on an issues it makes you think about the problem in more detail, research it etc... and normally in the end you end up with a better solution that either one originally suggested.

Lastly being around passionate talented people...

Answer 325

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 326

Read "Code complete" by Steve McConnell...

Answer 327

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 328

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 329

Learning PHP and get rid of Windows

Answer 330

Reading, understanding, extending, and modifying source code of programmers who were more expert than me -- i.e. K&R, source code for ThinkC Foundations Classes. Then applying the methods/patterns I learned in my own projects.

Answer 331

Started learning C++ a year ago

Answer 332

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 333

If you are interested in OO programming, I would also recommend to ready Object-Oriented Software Construction, Second Edition by BERTRAND MEYER. It really helps me to understand the OO concepts and improved my C++, Java and C# coding.

Answer 334

read some of the books listed at http://blinkmonitor.com/tag/5-stars/

actively use what you learned above within a few days, or you will lose it.

contribute to a wide variety of open-source projects.

Answer 335

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 336

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

Answer 337

Learned to read!

...seriously. If you think about it, we wouldn't be able to code anything without that basic skill.

Answer 338

1) Learning varied programming concepts: PLC programming, Assembler, Scripting, RAD Concepts, SQL and various Languages definately gives you a wide range of ways to attach different scenarios. Sometimes this is easier in the situations you find yourself in and sometimes not easy in an commercial/working environment. You can however use new technologies in isolation in smaller projects or disctrete parts of projects as "proof of concepts" to learn and test these technologies and learn new ways of doing things.

2) Reading Books (for particular help in specific areas) If you find books dont help you its because you're on the right track.

3) Main Point: Doing varied types of projects, Windows, Web, Windows Services, Screen Savers, Win IP Hooks, etc definately gives one a good overview of how things work and what works. Doing small projects when learning a new technology, either rebuilding existing apps you've built or cloning other small apps can definately take you throuhg the development processes quicker. 10 years of varied expereince is better than 10 years of repeat expereince.

4) If you dont like certain things in development eg Regular Expressions, JavaScript, become an expert.

5) Code Generation: Use code generation tools, you will soon learn to spot repeatable patterns to implement using code generation to save you time.

Answer 339

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 340

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 341

First, writing code. It helps you to improve your basic programming skils. Trying not to copy paste. Trying not to repeat yourself, find another aproach. Trying to learn different languages and new technologies and best practices. Also trying to understand what other people are saying rather than what you think. Trying to read other people's code. Those helped me a lot to improve my programming skills.

Answer 342

Read. Code. Read code.

Answer 343

One of the ways that I have used to learn to be good at programming has been through code reading, lots and lots of it, practice everyday and invest in books. Again, there's no one trick that helps - you decide what works for you and stick to it. But what ever you choose, it's always important to keep coding daily if you can.

Here are a few list of books that I have recently bought and found very useful.

Answer 344

Started Caring.

Answer 345

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

Answer 346

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 347

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 348

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

Answer 349

abstract one mile long, code one inch deep

Answer 350

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 351

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 352

Wrote a custom VM with a custom ASM syntax and a custom C-style language. It helped really a lot in understanding low level programming and architecture..

Answer 353

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

Answer 354

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 355

The single most effective thing that did improve my programming skills, was to initially invest much more time to think about the design of a program before starting to implement it.

Learning from other people helps optimizing the style and engineering and detail parts of programming, but it does not help much you when it comes down to finding a solution for a given unique problem.

The solution finding process is still a creative process, that you have to go through for yourself (or in a team). There often is no standard process and/or pattern to help you resolve the problem as a whole (if there is one, then you are probably solving a known problem once again, which still happens often in programming..).

After all it can be an extremely great satisfaction when your program takes shape. Even before you wrote a single line of code. And its an even greater satisfaction if your design, concept and plan works good when you write the code.

The coding is not less important, but its just the second step of programming.

Answer 356

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 357

The ability I believe aided my programming skills the most is:

Take a complex problem and split it up into smaller manageable chunks; arrange them in a logical order; handle them one at a time....then TA DA! you look around and it's DONE!

Aside from that...Know the business process you are assisting...AND KNOW YOUR DATA!

Answer 358

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 359

Lookup programming coursework in a language of your choice online and try and solve assignments.

Answer 360

Studying "Software Engineering" at a Technical University.

Answer 361

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 362

Documenting my own code as i write the code. It helps to clearly define the interface (what goes in, what goes out) and to find corner-cases before they pop up in real-life use. It also makes the code re-usable, in that six months later i can look at the API docs and know WTF the code does without having to decode it. My mantra has become "WTFM" - Write The Fine Manual.

Answer 363

• 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 364

1. Read Code-Complete and other books on the philosophical design of software [as opposed to technical books]. Technical books help too, but you don't really need to absorb as much because you can just look it up.

2. Read blogs-You won't agree with everything but you should evaluate everything and take away what you think works best.

3. Don't ever, ever think you know all there is to know about a topic. Even if you do, consciously thinking that is a good way to stop learning.

Answer 365

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 366

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 367

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 368

Learning different classes of programming languages...

C, Java, Python, LISP...

Answer 369

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 370

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 371

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 372

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 373

working with Nemerle

Answer 374

Ask lots of dumb questions on Stack Overflow. Seriously.

Answer 375

Learning from mistakes and refactoring old code

Answer 376

• 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 377

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 378

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 379

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 380

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 381

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 382

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 383

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 384

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 385

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 386

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

Answer 387

1) Teach

2) contribute to mass open-source products

Answer 388

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 389

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

Answer 390

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 391

Learn C and C++

Answer 392

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 393

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 394

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 395

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 396

Quit my last job.

Answer 397

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.