Which development skills have you acquired after 7-10++ years of experience in OO development ?

Some development skills, like refactoring operations, feel like they have an almost unlimited pontential for learning - only the fool will say he's finished learning that.

Other skills are bound to specific tools, and being good developers we learn new tools most of the time.

But some skills are related to how you think about code and how you approach coding, sometimes how a specific tool feature can be applied. Rotating pair programming and working closely with other people seem to be the best way of acquiring these skills, though certainly not the only method. (And sometimes you learn things you SHOULD have learned 5 years ago, these are not the ones I am asking about)

So I want to pair program with all of StackOverflow:

What are your late-acquired coding skills ?

Edit: I suppose I'm not thinking about the things you would have learned as a part of the curriculum if you were coming right out of school today.

From stackoverflow

• Prototyping & Mocking.

  I think about the times in the past when I've plunged feet-first into developing a feature 'in-situ' - much better to isolate the problem in a sandbox app.

  Mocking - again, following on from the principles of isolation (Divide & Conquer), this is absolutely core to any design I come up with nowadays.

  krosenvold : Together with loose coupling I suppose these are really the sign of the times. Those things weren't there 5 years ago. If you'd been right out of school today you would have learnt those ?

  Duncan : I'm not sure, it certainly wasn't mentioned when I went to uni 10 years ago! Think it's just a sign of the growing complexity of software - there are very few apps about that any one person can manage as a whole.

  krosenvold : Well I agree, my U taught me few or none of the tricks that make a good software developer

• Only when I realised that I needed people skills to complement my technical skills did I really start developing my career.

  Amazing how often this is overlooked by programmers or seen as unimportant compared to 'development skills'.

  krosenvold : Well career development is secondary to me; I'm interested in coding skills ;) My career's where I want it to be.

  Galwegian : @krosenvold - sorry if I went off track on this one. I realised this is not the question you asked, but still, it was something I feel strongly about. Over to you.

• Writing testable code thanks to dependency injection.

• Some of the skills where not around when I started coding:

  • Unit testing,
  • Refactoring,
  • Some other agile paradigms.

  You should only stop learning if you stop breathing.

  MusiGenesis : You shouldn't even stop learning then. Death is no excuse for ignorance. :)

• Working with only the logical structure of my code and ignoring physical file locations as much as possible.

• That I probably do not belong in management (where I spent a couple of years). I'm happier coding than managing :)

  Edit: Furthermore; I'm just beginning to get a real grasp on TDD, and I'm enjoying it!

• It may seem silly and obvious but... I think this has required a lot of years to get the hang of it as far as I'm concerned :

  • Knowing when to write comments where they are really needed.
  • Knowing when NOT to write comments, because the code is now self-documenting enough.
  krosenvold : I think these are the best ones; the subtle ones.

• Knowing: Although I can, doesn't mean I should "indulge" myself and build every request that comes my way. My primary objective is to provide a solution, and if that means taking something already there and expanding on it - then that's it.

• Pragmatism and People Skills.

  Being pragmatic about a situation. Yes, it may be ideal, but is it really necessary. Something may be the coolest feature in the world, but will it really generate any more revenue. Asking these questions and being realistic will allow you to filter out a lot of chaff from the wheat.

  I am still learning People Skills. It is not all about knowing all the answers, but rather being able to relay these to the Management and the Clients in a way they will understand and embrace. Being an Autistic with OCD and Bi-Polar makes things a little tricky sometimes.

• Hmm, writing testable code thanks to dependency injection. How did we manage before...

  For me it's, knowing what to test.

  I was a zealot for a while who said everything must be tested, DTO's get/set methods etc. This is impractical and unecessary. You must test (to death) the complex and critical stuff, because that's where your complex and critical defects are. Lightly test the rest.

• It's the soft skills around being a better developer in a team than the nuts and bolts of actually being able to make an application that (more or less) meets the spec and compiles and makes the user/tester not shout too much.

  1. when to defensively write extensible code because you know that it will save you time in the end.
  2. when to explicitly not do point (1).
  3. how to work in a team
  4. how to read and react to a specification that isn't wonderfully exact or clearly written
  5. when (and how) to let someone else have the funky project because you are too busy with drudge

  Mainly it's about being a better pack animal, there are times and places to be an alpha-male, but too often programmers can't take criticism and we can't always be playing with the projects like they're our toys.

  If you can't do that, then Guy Kawasaki and Joel Spolsky have written a lot of good stuff on founding your own company.

  MusiGenesis : Great comment: "it's about being a better pack animal".

• Software Architectures, Programming in the large. I realized that software >> code, and the question of programming languages is tertiary at best.

• I've learned not to be personally attached to the code I write. I no longer feel a personal attack/violation when people change my code or are critical of my code.

  krosenvold : As in shared code ownership ?

  Daniel Auger : Well yes, but specifically in the sense that I don't feel a personal attack/violation when people change my code or are critical of my code. So I guess it could be stated as learning to come to terms with shared code ownership.

  Chris Brooks : Good point. Think I'm there on the criticism side (Having learned I'm not perfect ;)) Haven't learned to be happy to pass it on to offshore resouces yet though - unless I don't have to look at it again...

  krosenvold : I think there's 1000 miles difference between accepting peer changes and the stuff that comes from some offshore places.

• The humility of seeing so much code, some good, some bad and then some that is just weird, that you recognize what you want to have where you work and what you don't want to have. For example, some like a "Cowboy" style programming while others are totally methodical and won't do anything with it being part of a plan that has been written up, vetted and signed off on by 3 upper management folks to have the blessing to do something that may take a couple of weeks.

  Getting better at organizing code and seeing where one can refactor to make something more generic so it has more uses or when to try to lock something down so it gets done as opposed to cosmetic changes done over and over again as the customer doesn't know what they want but they don't want the 101 prototypes they have seen.

• I really agree with the "People skills" post, but aside from that:

  To name one - I've really understood how languages are actually not languages. They are dialects.

  It seems that for each micro-piece-of-knowledge that goes into the autonomous parts of my fingers, I'm blessed with the ability to generalize into a higher level of understanding of things. -- These are words from my father who is a welder/steel-worker. Couldn't agree more.

  /Robert