What's the most important, useful or enlightening thing you learnt in the last 12 months? [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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... :-)

Answer 10

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.

Answer 11

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

Answer 12

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.

Answer 13

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.

Answer 14

• 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!)

Answer 15

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

Answer 16

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.