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.

| improve this answer | |
  • 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 '10 at 11:18
  • Added "I learned that..." – Martin Wickman Oct 30 '10 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 '10 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." – Amir Rezaei Nov 16 '10 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.

| improve this answer | |
  • +1 I agree. It's sad that Java has so bad support for functional programming. – Jonas Oct 30 '10 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 '10 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. – Joonas Pulakka Oct 30 '10 at 11:37
  • I would like to have better support for tail-recursion in Java/JVM. – Jonas Oct 30 '10 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. – Joonas Pulakka Jan 9 '11 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.

| improve this answer | |
  • 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 '10 at 11:19
  • (I convert the virtual up vote to a real one) – user2567 Oct 30 '10 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.

| improve this answer | |

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.

| improve this answer | |
  • 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 '11 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.

| improve this answer | |

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.

| improve this answer | |

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.

| improve this answer | |
  • 1
    Have you an example of one? – Mark C Oct 30 '10 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. – Peter Stuifzand Nov 1 '10 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... :-)

| improve this answer | |
  • 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 '10 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.

| improve this answer | |

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

| improve this answer | |
  • 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 '10 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.

| improve this answer | |

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.

| improve this answer | |
  • 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!)

| improve this answer | |

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

| improve this answer | |

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.

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

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