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

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

    Practice, practice, practice. And never be satisfied with the first thing that comes to mind.

    +1 for Mark Ransom...The difficulty comes when you're still not satisfied with the 100th thing that came to mind!

    Not wasting any of my time on Programmers Stack Exchange site helped me improve my coding skills immensely.

    Like many things in life, it is 1% theory and 99% practice.

    @dodgy_coder, note that this question was first asked in 2008, and that the guidelines for what makes questions acceptable for [programmers.se] has changed over time. To make sure that the quality of the site stays high, it's important to mark out questions that may no longer be acceptable, even if they are popular.

    @Mark Trapp how is this not constructive?

    @WTP - Read the description. "This question is not a good fit to our Q&A format." - as someone who asked this question, I agree. It was asked in more relaxed times.

  • In no specific order...

    • Working with people far smarter than myself

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

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

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

    • Pair programming

    • Disagreeing with everything Joel says. ;)

    Definitely agree with actively seeking out the smartest people. Conversation floats *everyone's boats*

    I know it seems really gratuitous and potentially reputation whoring, but if you separated those items out to one per answer people could vote up which ones they agreed with, allowing for a more specific end vote "solution" of this question.

    Disagreeing with everything Joel says, while nevertheless reading it all and finding it extremely thought-provoking...

    Bill- ayup. He never ceases to get a reaction from me... I love to hate him, and hate to love him.

    what if there are no smareter people around? i mean i know i could improve in a lot of things, just there are nobody around who i could learn from :/

    @Zizzencs - that's a good question and I have a simple answer (which is, admittedly, nerve wracking and difficult to implement): Get a new job. We're hiring, if you're interested. ;) (www.vendasta.com)

    Watch how smarter people handle mistakes - that's when I learn the most from them

    I don't think it's wise to ignore everything Joel said, or for anyone for that matter. You should listen, then analyze, then make your own judgment.

    @Hao Wooi Lim: who was ignoring Joel?

    if this is a list in no particular order, shouldn't it be an unordered list rather than an ordered one? :P

    I agree with mmyers - just because you disagree with someone doesn't mean you're ignoring them. Actually, it's the opposite - in order to disagree with them you're actually paying attention to them.

    I don't cart-blanche disagree with everything Joel says, I think much of the time he has some interesting things to say. My comment was tongue in cheek. There's a lot of stuff that I agree with when it comes to Joel, but about once a month he makes me shake my head and ask "What? Are you serious?!". Which I love, as I find those the most challenging things that force me to really check my position and what I believe.

    +1 for Pair Programming, doing consulting work also made me learn a TON about very weird issues and how things are used in different ways, ways that are wrong sometimes, and ways that are clever...

    What Joel does is to frequently play devils advocate which makes people question their current thinking. This can only be a good thing and is what makes him so interesting and helpful to follow.

    +1 Sometimes you can't agree with everyting Joel says! You MUST have your own opinion!

    "job title doesn't mean anything." that's true, I have known a CTO who is a jerk, storing plain password as text in DB, doesn't know that a `span` cannot have a width, hiring college friends who didn't know SQL well to be the main backend guy, hiring girlfriend's brother who had zero training in software testing to be the head of Testing, stole ideas from the previous company and founded his own company. He is stupid, but that was ok, because he has money

    And then, I also known somebody who went to a 4th rated university, got spectacular reviews on LinkedIn.com as well as giving spectacular reviews to those other people, talk really well, crash the whole system many times, and when faced with those situations, mention the nicest and bully-able person's unrelated issue so as to give a false impression to the group that it was his fault, so as to back stab him. Yet he called himself Scalability Architect, and he gets hired because he knows how to talk.

    support pair programming but *smarter* part is hard to come by and implies you aint smart enough (since it's virtually impossible to get smarter; knowledge/experience - yes but not really smart)

    Umm... Forgive me my ignorance (or dumbness), but... 'Joel' as in 'Joel S...y'? It's just that so many people agree on that being alright to disagree with that person, so I'm wondering where I could see what he says or thinks about things.

    @cranley, what will you do if Joel agrees with you on the things you list here?

    @bestsss: It is also hard because smarter people might themselves prefer to co-operate with those smarter then them. You then have to find a way to convince them why they would benefit from co-operating with you...

    The first argument is so damn right ... I've been doing stuff all alone since I started programming and it feels like such a waste to not have a mentor / someone who is actually at least as smart and has been there/done that. I mean .... it's tiring to reinvent the wheel (when your wheel is square, you unfortunately have to) and never have anyone to tell you in advance that MySQL is a farce, that PHP has major limitations, that all languages are in fact limited in different ways, etc.

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

    "Jack of all trades, master of none, though often better than a master of one." -Adam Savage

    I completely agree with this. Learning lots and lots of different and similar things will teach you knowledge that is worth something for a lot of time. For example knowing how values might be handled in a language will probably help one learning new languages forever.

    I would call this the Professor Challenger principle.

    Excellent advice, up voted. The "orphan tech" in my past was my 8-bit Atari, which lost out to the C64. I reached the same conclusion though - to quote Heinlein, "specialization is for insects."

    Couldn't agree with you more! My ADD has kept me from focusing on anything long enough to specialize and it is really the defining characteristic of my career!

    hmm, actually i was deciding whether to specialize in something or learn and explore various technologies eg. Zend Framework vs ASP.NET MVC vs Ruby on Rails, Flash vs Flex vs Silverlight. and i guess from here i can deduce that to a certain extend i shld generalize... but the hard part will be to take time off... and that also means i lose some chance to be even better in what i am currently doing

    There are always tradeoffs, and there's only 86,400 seconds in a day -- you'll have to decide how you want to spend them. In my case, I've chosen to spend extra hours (above and beyond my 'work' hours) to learn things that I thought were interesting or were going to be in demand in the future; you'll need to make your own choices.

    "Specialization is for insects." - Heinlein

    Where is your "Generalist" badge? ^^

    What was the database you worked with that lost out? I still do a large amount of work with a 1990s product (R:Base) that has become very much a niche product, notwithstanding that it's still manufactured and updated. Also, I heard somewhere that the decay rate of software knowledge is 20% per year.

    Pick -- a combination OS and database. Also know as Universe or UniData (when hosted on Unix) or Information (when hosted on Pr1mos).

    I want to be Jack of all trades and at least master of some .. :)

    @Arnis, when they implement the "Generalist" badge, I'll be there.

    Someone said something like - a specialist is someone who knows more and more about less and less, until person knows everything about nothing.

    A generalist is someone who knows less and less about more and more until person knows everything about nothing.

    this is a good ideal until you try to get hired somewhere with no tangible experience

    Getting the first job is always hard, but if your skillset is broad and flexible, then you've got more opportunities that someone who only knows a single skill. The hard part is in selling yourself, and then delivering on what you're selling. Once you've got that first job, then you'll be getting tangible experience, and if you really put the effort in to learn new things (above and beyond the day-to-day needs of the job) then the effort will pay for itself.

    Be "The Jack of all trades" but first master One

    @n10i When does mastery start? I therefore disagree. Be good enough for the current task at what you do, then move on to the next thing.

    I prefer to be "master of one and jack of all" :) although i haven't succeeded at being "master of one" or even at "jack of all" for that matter

    I've generalized pretty well in my career, with a wide range of technologies and platforms. Recently I've specialized into the fields that I find of most interest. This has paid off greatly in my career. There is to many technologies to truly generalize, even if you only stick to open standards.

    I can vouch for the success of this strategy, at least for remaining employed. It also makes life more interesting to keep learning new things.

    Well I've been doing that and it's not as good as it looks when you say it ;) - Honestly, doing the same but having a mentor in every and each technology sounds great to me, but learning everything by myself on every technology I meet (which I currently do) looks like such a waste of time ... I still would like to at least be master in the best dbms available (postgreSQL) and master in the best language available (no goddamn clue so far) - I like creating stuff.

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

    That typically works both ways. I've come into a few companies now as an 'Aaron' and found that once I get the other coders energized that they start to give me a run for my money and encourage me to redouble my own efforts. Great post!

    awesome post, and the first comment hits the nail on the head as well.

    Great post, and I have witnessed the rub-off effect as well.

    +1 for "Aaron was always talking about how I should never stop at the first working version, but refactor and refine until the code is elegant"

    "never stop at the first working version"??? - when are you supposed to get the rest of your work done? :)

    I've attempted to be Aaron, sometimes it works, but sometimes I'm wrong. "Those who cannot learn from history are doomed to repeat it." It's good to keep our minds open to new ideas, but it's bad to listen a n00b over those who've already made the mistakes for you. Everyone needs some skepticism, as we learn from asking questions of ourselves and others.

    Everyone should have a guy like Aaron. However, as you also put it, *consciousness* is crucial -- one must be open to new things and willing to learn, otherwise improvement will never happen. I'd say the desire to learn new things is the key for continuous improvement!

    I like stories like this. My Aaron was a guy named Andrew. I actually got back in contact with him 5 years after we parted ways, and seeing where he is now gave me another kick in the backside. Plus, i'm currently going through some old code and refactoring/beautifying it at the moment.

    @Ronnie: during all the time you're now saving because you wrote quality code three months ago.

    @Dan: On the one hand, there are people who come in thinking they're Aaron and trying to change everything without listening to the reasons things were previously done the way they were. On the other hand, there are people who have learned their own lessons, and are trying to continue to learn lessons. They teach, and they listen. That's what being Aaron is really about. It's always worthwhile to listen. Once you have listened and understood, you can then decide whether you should do what the n00b's suggesting, or stick with what was done before.

    Why anonymous? Sounds to me like the man deserves some credit.

    The problem is too many people think they are "Aaron"

    I don't care how long ago this post was made. This is THE best post I've read on SO!

    I love this answer because I work with a guy named Aaron (no joke) who is brilliant and has taught me a great deal.

    Another thing I've learned after ~12 years of coding, to paraphrase Mark Knopfler: sometimes you're the Aaron, sometimes you're the Doug. ('Doug' being the guy who's, you know, not Aaron. Rhymes with 'bug'. Just go with it.)

    Such a sweet and great answer!!!

    There are 10 types of people in the world, those who want to improve, and those who don't care. They literally don't care, they'll never be good or great at anything and that's how it is for them. The others cannot stand to do anything worse than they know they could and inevitably get much better every single day. Aaron was of that type, you too - even though more passive - and that enabled the knowledge transfer. All my life - till I was around 23 - I tried to help others be better, and then I realized and accepted that they didn't care. at all. They're bent on being bad, don't force it.

    damn this company must have been really mediocre.

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

    AND one of the best ways to learn what NOT to do :)

    You can see how they do something. Maybe they do it in a better way than you?

    I had to dig into a really old and completely undocumented project, document it, fix some bugs in it, and port it to a new system. I learned a lot, and not all of it was what not to do. Though I did learn the value of comments.

    And while you're writing the documentation, maybe write some unit test cases for it (if they don't exist). Then you'll also know how to use the code.

    So true, that was the hardest part of my job for a long time.

    whats neeed of reading documentation . they sucks

    +1 Sydius. I recently had to work on an old project, looking like a real jungle. I can't say I've learn a lot of good programming practices reading it's code, but I definitively learned a lot of bad practices to avoid at all cost, as well as the value of comments!

    On a similar note, try writing unit tests for other people's code, it'll help you pick out ways to improve it (e.g. allowing for dependency injection & not enforcing singleton behaviour)

    +1. Learning Haskell for me has definitely supported this. LYAH presents code straight from the Prelude, and really got me into checking the library source to understand how stuff works.

    I personally cannot read code from others without seeing the flaws in it and feeling the urge to rewrite it. makes me furious and I'm not going to write a single comment until I rewrite the code - I know I'm evil but whatever.

    Number 1 makes my head hurt and Number 2 makes my fingers hurt.

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

    The sad fact that a majority of people don't exercise or even stretch at all on any sort of regular basis is a huge problem in today's world.

    I'll extend this, if I may, to any amount of physical excursion. Sometimes, when I've not done much manual work for a while, I start to crave physical tiredness. It's kinda novel when you're so used to being mentally drained and it helps you break out when you're just thinking yourself round in circles.

    yes that's the big problem today. we don't have the time especially in pakistan where the working hours are lot more

    +1 as a reminder *to myself* to get more exercise.

    I find that a sport is a great motivator - for me, it is basketball.

    Just make sure that you still got lots of sleep, otherwise this can have a negative effect (that i keep re-learning).

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

    I agree. Getting my hands dirty in a project has been probably the biggest contributor to my improvement. ; )

    Exactly. The single best way to become a better coder is to code. You can learn all you want from books, podcasts and co-workers, but you have to apply it before you really understand it. Code more, and code more different stuff. Because you don't learn much from repeating the same old trick.

    Choosing challenging and intriguing projects to do. I think the struggle to overcome outside of your comfort zone really speeds up your skills. They didn't go to the moon because it was easy.

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

    I can vouch for that.

    how did you get into that?

    An instructor at the university told me about the opening when I was still a student. I stayed for nearly a year (part time) after I graduated.

    As Douglas Adams writes in "Dirk Gentley's Holistic Detective Agency": "the best way is to try and explain it to someone else. That forces you to sort it out in your mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas."

    Too True. Teaching photography made me a better photographer. Not much of a coder tho :(

    Yes, it forces you to go over the basics again and again. Not particular for coding, but for any profession.

    mutuo ista fiunt, et homines dum docent discunt - Seneca

    I am totally with this one. i have learned a whole lot too when tutoring, especially stuff i wasnt sure about before

    They let major students help TA the intro programming classes at my university. It was *great* experience!

    “The process is mutual; and men, while they teach, learn.” - Seneca.

    Yes, teachers teach themselves mostly. Rare is it to find the true sponge-student.

    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

    I can only agree; "pet project in a previously unknown language" is good, I can confirm

    Very good suggestion to learn something halfway familiar.

    Great suggestion "something you have experience with + something you don't "! Thanks

    I need a pet now.

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

    I gotta vote you up just for bringing back wonderful memories! Maybe I even teared up a little :)

    I still mentally translate C/C++ into 68K assembly language. It's amazing how that helps you write efficient code for any platform.

    Ah, the 6502, brings back great memories. I learned so much with assembler on this chip.

    EVERY student of programming should have in-depth exposure to assembler early in their education!

    I did the same thing as a youngster. It really taught how computers work, moreso than a high-level language ever can.

    Indeed, +1. Being forced to be frugal and disciplined early on leaves useful scars.

    On the 6502 topic - here's an incredible article about the guys that created it http://research.swtch.com/2011/01/mos-6502-and-best-layout-guy-in-world.html and also a deconstruction project to run it in js (they've regenerated the only known circuits by literally photographing the insides of the chip) http://www.visual6502.org/JSSim/expert.html.

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

    I second that... I can hardly even read some of my old stuff.

    When I go over old stuff of mine I get nearly-irresistible urges to delete the whole file. Sometimes the whole directory.

    +1 for objectivity. Looking over your old code won't tell you how to improve, only if you've improved and how -- or conversely, if you haven't.

    I have done this--I wrote this whole script interpreter in VB6, I wrote it over two years; it could make windows, handle their events, etc. It grew so large and out of control that I could no longer add to it without breaking everything. That was the last thing I wrote before I gave up programming for books about programming. Now I am much better *phew*. Reading back on that monster project makes me realize just how far I've come

    @Christopher Mahan: And on really bad occasions, the entire volume.

    @Thanatos One word: re-image.

    Grant Johnson - i certainly agreed to that how bad they were

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM