A lot of people in the coding community talk about continuous improvement, deliberate practice and so-on - but when they talk about their current practices it's almost like they 'sprang fully formed from the loins of Zeus' because you don't hear about how their opinions changed over time or what they learnt recently.

Every now and then though I go to a talk, or read a book, or talk to someone and they open up a bit more and I find that I learn a lot from these insights.

So, if you had to pick one thing from the last 12 months that you learnt what would it be?


16 Answers 16


I learned that it takes only one rotten manager to spoil the whole project, but it takes lots of good programmers to clean up the mess afterwards.

  • Martin, I upvoted because your message make me smile on this rainy & cold saturday morning, but you don't answer to the question ;)
    – user2567
    Oct 30, 2010 at 11:18
  • Added "I learned that..." Oct 30, 2010 at 11:26
  • +1 because I'm one of those programmers this month. 70+ hours last week == "my turn in the barrel".
    – Dan Ray
    Oct 31, 2010 at 12:19
  • I recognize that one! It should be quote! "It takes only one rotten manager to spoil the whole project, but it takes lots of good programmers to clean up the mess afterwards." Nov 16, 2010 at 17:26

After learning some Clojure, I started to realize the usefulness of functional programming, and my Java coding style has been heavily affected by that. Contrary to popular belief, a functional programming language is not an absolute prerequisite for doing some functional programming.

It's possible to incorporate quite a few elements of functional programming into an imperative language such as Java, and even if it's not always idiomatic, it can be highly beneficial in some problems. For example, anonymous classes are roughly equal to closures, as described in wikipedia. Lazy evaluation should be a norm rather than something unusual. Immutability can hardly be overused. Just get over the (almost) obsolete idea that constructing new objects instead of mutating existing ones is expensive because of GC and heap consumption - in 99.9 % of cases it's simply not relevant. In fact, parallel processing can flip even the efficiency argument other way round: creating new immutable objects can be cheaper than mutating existing ones, because you get rid of locking.

More info on doing FP in pure Java here, here, here and here.

  • +1 I agree. It's sad that Java has so bad support for functional programming.
    – Jonas
    Oct 30, 2010 at 11:06
  • I've had a long standing interest in FP (my first job involved lisp) and I think it's very exciting that in the last few years it's finally becoming a fairly 'common' paradigm alongside OO etc.
    – FinnNk
    Oct 30, 2010 at 11:36
  • Java 7 should have better closures at least. And using clever libraries such as lambdaj can do wonders to patch the deficiencies of the language itself. Oct 30, 2010 at 11:37
  • I would like to have better support for tail-recursion in Java/JVM.
    – Jonas
    Oct 30, 2010 at 13:26
  • 1
    @Helper Method: the first two links in my answer are articles on FP with Java. I'm not aware of any books on the subject. I think the best method to "get it" is to learn some actual FP language, and then just start using more immutable objects in your Java code. Jan 9, 2011 at 8:35

Even if you have a superb team, and competent management for that team, your job is still not safe. Upper management can still do foolish things, like disband your entire Directorate.

In short: politics matters, and sometimes the politics that affect you, you cannot control.

  • I give you a virtual +1 because Martin already make me smile with similar answer ;) Did you read Dead March ? this is a book about what you are talking about
    – user2567
    Oct 30, 2010 at 11:19
  • (I convert the virtual up vote to a real one)
    – user2567
    Oct 30, 2010 at 11:20

I learned that the purpose of software testing is to find bugs. It is not to verify that the system is correct.

There are important psychological factors at play: If your goal is to show that the program is "correct," you will gravitate toward tests you know will pass. But if your goal is to find bugs, you will gravitate toward tests that will really push your system to the limits.

There is even an important change to the language you use. If a test finds a bug, you call it successful. If the test doesn't [that is, the program passes], you call it unsuccessful. I caught myself going along the lines of "verification" thinking, and it makes a big difference.

This psychological effect is discussed more in The Art of Software Testing, a classic book that I highly recommend. The author, Myers, also recommends that whoever is testing a program shouldn't be the author, nor even in the same management chain. You can do this if you are coding on your own, so it takes discipline.


Doing test driven development from the start on a customer delivery to see how it would affect the code quality, and only running from within the JUnit launcher in Eclipse. It resulted in a better product.

  • Note that I did not find a way to bind "Rerun latest unit test" to a key. This made it a bit tedious.
    – user1249
    Jul 3, 2011 at 12:54

The true value of egoless programming.

At some level I always knew that ego and programming don't mix, but never quite reasoned out the consequences. The notion that you have to actively review and find fault in your own practices is something that I've only started realizing last year. I'm also learning to actively seek out criticism of my designs (in both UI and code).

To be honest however, I'm still learning how to drop the ego, and I probably will be learning how to do that for the rest of my programming career.


Here's my answer to my own question:

About a year ago it clicked that automated acceptance tests needed to be not automated versions of the tests that our testers would have done manually. Focussing on tests against single specifications rather than trying to hit as much as possible in a single pass made the tests much simpler, easier to read and also helps to encourage incremental delivery.


I learned how a mathematical concept like Semirings applies to algorithms. With this you can show how some algorithms are the same except for using a different semiring. This shouldn't be that strange for me as a programmer, but my head was blown.

  • 1
    Have you an example of one?
    – Mark C
    Oct 30, 2010 at 16:21
  • There is an example in the book Element of Programming that uses a function that calculates powers and some fibonacci stuff, that calculates fib in O(log n) time. I think the example can be found here cpp-next.com/archive/2010/03/eop-ch3-preview, but that website responds with an internal server error. Nov 1, 2010 at 14:32

Besides politics Frank Shearar mentioned, I've recently discovered QUnit and JSCoverage which made my day. And month. Never thought it would be possible to unit test JavaScript with code coverage, but there it is... :-)

  • This is on my radar for next year, I've dabbled a bit in js unit testing but not on a real project yet. Didn't know there was a coverage tool available!
    – FinnNk
    Oct 30, 2010 at 11:31

My top three thanks for the last programming year would go to the following (in descending order of importance and gratefulness):

  • the functional programming paradigm for opening my mind to other, often more elegant and terse ways of expressing ideas and algorithms in code. I feel that my overall programming skill has improved much in a very short time, thanks to functional programming ideas.

    (My personal thanks go to Tomáš Petříček for his excellent book Real-world functional programming.)

  • both dependency injection and unit testing have taught me that object composition is arguably the best way for creating complex (object-oriented) systems (and that class inheritance isn't nearly as important as I used to think). Both have taught me and made me think about how to best compose systems and how to write components that are easy to use, yet still flexible enough for reuse.

    (If I had to mention a good teaching resource, I'd say Roy Osherove's Art of Unit Testing.)

All of these taken together have resulted in me writing code that generally has fewer bugs than before, because I'm now writing code that's far easier to understand and get wrong than what I previously put out.


What ever changes in the fast evolving software industry, the learning curve is always here. "If there was only a way to learn without taking time to learn."

  • The fact that there is always new stuff to learn is, to me, one of the great appeals of this profession. IT systems are often all about how to best handle increasing complexity, and I love discovering new theories and concepts in that direction. On the other hand, it can all be frustrating at times, because having to keep up with the state-of-the-art can feel a little like a constant race.
    – stakx
    Oct 31, 2010 at 10:54

I learned that getting sold to a new company can indeed improve your job. My organization was purchased from our old company in May, and things appear to keep getting better. The new company has spared little/no expense w/our new office, replaced our deprecated development machines with 21st century equipment, exhibited flexibility with managing our projects, and generally made us all feel more than welcome.

It kinda feels a bit depressing getting sold (a little like a serf having a new feudal lord because he's tied to land which changed hands), but the final result has been much better than I expected.


I would say using Microsoft unit testing within Visual Studio 2010.

I found it really easy to debug a specific test method.

I could run anytime my test project in order to see if business layer application is working fine. The testing process guarantees that my team should have no problems when deploying the complete solution for our website visitors.

  • Learnt Basic Python (using it to write quick scripts sometimes)

  • Installed ArchLinux in VM (had Ubuntu in VM earlier, my PC is fast now!)

  • Started with MATLAB (especially for plotting graphs and quick numerical checks)

  • Switched to Mercurial (from SVN) (branching and merging!)


Learning the MVVM pattern helped me become much less of a hack.


I had to start maintaining a Python web application -- so I decided it was a good time to learn Vim as well. Now I'm using IdeaVim plugin for Intellij for my Java and Flex development and I definately believe it's made my typing faster and more efficient.

  • 1
    Really -- -1? You want to unpack that for me -- people don't think that VIM is enlightening or useful?
    – Watson
    Sep 30, 2013 at 14:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.