krosenvold
krosenvold

Reputation: 77201

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.

Upvotes: 4

Views: 921

Answers (14)

sharkin
sharkin

Reputation: 12498

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

Upvotes: 1

JB King
JB King

Reputation: 11910

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.

Upvotes: 2

Daniel Auger
Daniel Auger

Reputation: 12611

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.

Upvotes: 3

Karl
Karl

Reputation: 3216

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

Upvotes: 2

Galwegian
Galwegian

Reputation: 42247

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

Upvotes: 8

Unsliced
Unsliced

Reputation: 10552

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.
    • when to explicitly not do point (1).
    • how to work in a team
    • how to read and react to a specification that isn't wonderfully exact or clearly written
    • 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.

Upvotes: 5

Chris Brooks
Chris Brooks

Reputation: 309

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.

Upvotes: 3

Xetius
Xetius

Reputation: 46844

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.

Upvotes: 3

Patrick Manderson
Patrick Manderson

Reputation: 78

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.

Upvotes: 1

Franck
Franck

Reputation: 6325

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.

Upvotes: 6

Eyvind
Eyvind

Reputation: 5261

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!

Upvotes: 2

user43940
user43940

Reputation: 263

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

Upvotes: 0

Toon Krijthe
Toon Krijthe

Reputation: 53416

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.

Upvotes: 3

Duncan
Duncan

Reputation: 10291

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.

Upvotes: 3

Related Questions