4 ms·

Long experience in development is often more about knowing what won't work as much as what will. Older developers can often rule 80% solutions out immediately

by mtkd 14y ago

Long experience in development is often more about knowing what won't work as much as what will. Older developers can often rule 80% solutions out immediately - but a younger developer would have to work it out the hard way.

rapind 14y ago
I for one definitely solve problems significantly faster and cleaner than I used to when I was starting out. Nothing sticks like learning patterns the hard way. I'm not sure that means anything relative to the whole though. Maybe I was just a bad coder when I was young and now I'm finally catching up.
cunac 14y ago
also older people should be more aware of what and how much they don't know. Keep in mind that any decent 'old fart' did ship to production and support at least handful of applications with actual users (hint: time before internet )
adrianhoward 14y ago
I listened to rather a nice talk by George Fairbanks at GOTO Copenhagen kinda related to this topic on Tuesday (http://gotocon.com/cph-2012/presentation/Master-builders%20have%20rich%20conceptual%20models%20of%20software%20design http://gotocon.com/cph-2012/presentation/Master-builders%20h...). One of the things he brought up was the idea of what you'd tell your twenty year old self to get them to be as skilled as you are now - and it was a hard thing for me to answer off the cuff. After a couple of hours I was thinking about things like that I pretty much totally misunderstood in my twenties. * Building software is much more about people (both the team and the users) than it is technology. So called "soft skills" are vital to shipping. * Value starting small and growing a system, more than starting large and solving everything. * Validate what you produce. Do it with the shortest feedback loops possible. * Build up abstractions from working code, don't create working code from abstractions. * Make sure that you build the abstractions from the problem domain/solution into the code, not just the abstractions you need to make the code easier to produce and comprehend * Always be able to explain the decisions that you make in development. ... and of course the shit load of experience that doing development for thirty years in multiple domains, teams, languages, contexts, etc :-)

by mtkd 14y ago

rapind 14y ago

I for one definitely solve problems significantly faster and cleaner than I used to when I was starting out. Nothing sticks like learning patterns the hard way. I'm not sure that means anything relative to the whole though. Maybe I was just a bad coder when I was young and now I'm finally catching up.

cunac 14y ago

also older people should be more aware of what and how much they don't know. Keep in mind that any decent 'old fart' did ship to production and support at least handful of applications with actual users (hint: time before internet )

adrianhoward 14y ago

I listened to rather a nice talk by George Fairbanks at GOTO Copenhagen kinda related to this topic on Tuesday (http://gotocon.com/cph-2012/presentation/Master-builders%20have%20rich%20conceptual%20models%20of%20software%20design http://gotocon.com/cph-2012/presentation/Master-builders%20h...). One of the things he brought up was the idea of what you'd tell your twenty year old self to get them to be as skilled as you are now - and it was a hard thing for me to answer off the cuff. After a couple of hours I was thinking about things like that I pretty much totally misunderstood in my twenties. * Building software is much more about people (both the team and the users) than it is technology. So called "soft skills" are vital to shipping. * Value starting small and growing a system, more than starting large and solving everything. * Validate what you produce. Do it with the shortest feedback loops possible. * Build up abstractions from working code, don't create working code from abstractions. * Make sure that you build the abstractions from the problem domain/solution into the code, not just the abstractions you need to make the code easier to produce and comprehend * Always be able to explain the decisions that you make in development. ... and of course the shit load of experience that doing development for thirty years in multiple domains, teams, languages, contexts, etc :-)