The #1 skill I’ve needed to foster since I began to program professionally is the skill of -not having to know exactly what is going on-. It’s a very difficult skill to foster.
I work with, no joke, around 250 different technology frameworks/stacks. I don’t get the luxury of only having to work with one operating system. If a client uses it, I have to know how to work with it.
The trick isn’t expertise. It’s a generalized knowledge of how people tend to construct frameworks, combined with -really good- debugging tools and skills, and high levels of Google-Fu.
The first part—understanding how people tend to create these frameworks—is the most important. If you can get a strong grasp of this, you’re 95% of the way towards understanding any given framework.
Another important skill is knowing when to give up on a framework as being incomplete/unworkable/unmanageable. Those 250 are just the frameworks that have made the grade.
I heartily recommend pretty much all of Jerry Weinberg’s books to all software developers. The Quality Software Management series is awesome; a lighter but still impressively useful starter book is Are Your Lights On, which teaches how to ask the right questions when you have no freaking clue what is going on. Secrets of Consutling is another good one.
You won’t find a line of code in these books. What they tend to teach you (well, me, anyway, YMMV) is how to gain an understanding of the non-technical essence of a problem. In 99% of cases the technology isn’t the issue anyway; the problem-solving skills (or lack thereof) of the people involved are.
For the remaining 1%, pick a few products or frameworks that appeal to you and become intimately familiar with them, at the “critiquing a work of art” level. Then attempt to build something equally challenging; a virtual machine, an emulator, an OS kernel, a compiler, a whole video game, a web framework, that sort of thing. Deep expertise in any given thing will transfer well, if you have also mastered the art of problem-solving in general, i.e. when you have (to start with) no clue what is going on.
I used to be a decent Java expert, but nowadays I’d go to some lengths to having that kind of label slapped on me; the pay is much better working on problems at a higher level of abstraction.
Are Your Lights On is a good all-purpose introduction to problem-solving, but it’s a bit… basic (worth reading anyways, just because I found it amusing, though). Are Quality Software Management and Secrets of Consulting a little more in-depth?
Personally I’d recommend practice; I can’t comment on Morendil’s book recommendations, as I haven’t read those books, but now I’m thinking maybe I should.
I can’t really think of a way to simulate business requirements (Morendil is quite right − 99% of the time, the biggest problem is getting past the client’s own lack of understanding of their problem), but you could simulate the programming side of the equation.
Throw yourself into a technology you’ve never worked with before, and try to solve a problem that seems appropriate to it. Say, try to get a process to insert the contents of an Excel spreadsheet into an Access database using Apache POI feeding into ODBC drivers (provided you have no experience with either POI or ODBC) in a two hour timeframe.
The #1 skill I’ve needed to foster since I began to program professionally is the skill of -not having to know exactly what is going on-. It’s a very difficult skill to foster.
I work with, no joke, around 250 different technology frameworks/stacks. I don’t get the luxury of only having to work with one operating system. If a client uses it, I have to know how to work with it.
The trick isn’t expertise. It’s a generalized knowledge of how people tend to construct frameworks, combined with -really good- debugging tools and skills, and high levels of Google-Fu.
The first part—understanding how people tend to create these frameworks—is the most important. If you can get a strong grasp of this, you’re 95% of the way towards understanding any given framework.
Another important skill is knowing when to give up on a framework as being incomplete/unworkable/unmanageable. Those 250 are just the frameworks that have made the grade.
So, what resources would you recommend to facilitate learning this skill?
I heartily recommend pretty much all of Jerry Weinberg’s books to all software developers. The Quality Software Management series is awesome; a lighter but still impressively useful starter book is Are Your Lights On, which teaches how to ask the right questions when you have no freaking clue what is going on. Secrets of Consutling is another good one.
You won’t find a line of code in these books. What they tend to teach you (well, me, anyway, YMMV) is how to gain an understanding of the non-technical essence of a problem. In 99% of cases the technology isn’t the issue anyway; the problem-solving skills (or lack thereof) of the people involved are.
For the remaining 1%, pick a few products or frameworks that appeal to you and become intimately familiar with them, at the “critiquing a work of art” level. Then attempt to build something equally challenging; a virtual machine, an emulator, an OS kernel, a compiler, a whole video game, a web framework, that sort of thing. Deep expertise in any given thing will transfer well, if you have also mastered the art of problem-solving in general, i.e. when you have (to start with) no clue what is going on.
I used to be a decent Java expert, but nowadays I’d go to some lengths to having that kind of label slapped on me; the pay is much better working on problems at a higher level of abstraction.
Are Your Lights On is a good all-purpose introduction to problem-solving, but it’s a bit… basic (worth reading anyways, just because I found it amusing, though). Are Quality Software Management and Secrets of Consulting a little more in-depth?
Very much so; QSM especially (originally a 4-volume series, JW has reissued them in ebook format along with other titles).
Personally I’d recommend practice; I can’t comment on Morendil’s book recommendations, as I haven’t read those books, but now I’m thinking maybe I should.
I can’t really think of a way to simulate business requirements (Morendil is quite right − 99% of the time, the biggest problem is getting past the client’s own lack of understanding of their problem), but you could simulate the programming side of the equation.
Throw yourself into a technology you’ve never worked with before, and try to solve a problem that seems appropriate to it. Say, try to get a process to insert the contents of an Excel spreadsheet into an Access database using Apache POI feeding into ODBC drivers (provided you have no experience with either POI or ODBC) in a two hour timeframe.