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

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

Writing testable code thanks to dependency injection.

Answer 4

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.

Answer 5

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

Answer 6

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!

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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

Answer 13

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.

Answer 14

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.

Answer 15

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