News: Tech Talk with Dave Thomas on the 'knowledge portfolio'
Dave Thomas, one of the Pragmatic Programmers, talks about ways to improve programming proficiency by diversifying the "knowledge portfolio," and discusses the place of Ruby, Python, and Groovy in the developer's tool belt, in how they broaden the developer's exposure to various approaches as well as in how they offer different abstractions.
- Posted by: Joseph Ottinger
- Posted on: July 12 2005 11:28 EDT
View Tech Talk
- Don't give up on reading the script. by Abhay Bakshi on July 13 2005 15:11 EDT
- "Can you explain the five steps of the knowledge portfolio?" by Abhay Bakshi on July 13 2005 19:58 EDT
- Tech Talk with Dave Thomas on the 'knowledge portfolio' by Erick Reid on July 13 2005 15:47 EDT
- Dave touches an important topic with "package scoping" by Jorn Bettin on July 14 2005 04:12 EDT
- Linux - mplayer !?!? by beton beton on July 16 2005 17:19 EDT
- Tech Talk with Dave Thomas on the 'knowledge portfolio' by Charles Lee on September 04 2005 10:15 EDT
Dave Thomas is quite engaging in his talks. But, if you don't have audio, you may read the script.
I encourage that you don't give up on reading the script. Dave generally talks a lot, and mentions interesting, useful points.
More on Dave at - http://www.javalobby.org/articles/nfjs/.
This tech talk is one of those where questions are less and and answers are many!
I finished watching the entire video after I got back home.
Really, the heart of the tech talk is
the question "Can you explain the five steps of the knowledge portfolio?" and the answer to it.
TSS, thanks for posting a great tech talk with Dave Thomas.
An excerpt quickly:
The second thing is to look for value. In the same way, if you invest based on fads, rumors and those kinds of things, you tend to lose money. You need to look at the underlying value and the knowledge that you're getting. Clearly, there is faddish technology and there is core technology and if we look at the core technology first, this is where we should be investing a lot of our time. The other side to that coin is that we need to think about how much additional value each hour of investing gives us. For example, in Java world, there are new libraries arriving every week and we could sit there and say, "Okay, we are into Java, we are going to learn all these new libraries and we will invest significant time in picking up latest the persistence framework," or whatever it might be. Is the incremental increase to your value from doing that as much as it could be if you learn something totally different? For example, you might argue that with the Sun and Microsoft marriage that there is more likelihood that we're talking about .NET front ends talking to J2EE back ends. In that environment, someone that knows both is going to be very valuable. Maybe your time will be better spent learning some of the .NET basics compared to learning the latest JSR or whatever it might be.
presently reading pragmatic programmer, and am enjoying the time. i've done some code generation for a couple projects and am excited to see it noted in the book as a to-do.
this interview adds a current events aspect to much of what is presented in the book. a good test of the insight ability of an expert is in seeing how well the statements they made years ago stand up to modern times. dave and andy's items seem to be highly durable, lending greater credence to what he has to say in this current discussion.
a related example is that many of the items of hypothetical functionality that would comprise a great ide as cited in the book were answered soon after publication by eclipse.
i'm curious to hear more on what people thought about dave's take on packages being seen more as courser-grained encapsulations, presenting facades to the outside world while the actual classes within relied more on package-level access to one another. i've seen a couple of cases where a package was treated as a cohesive module, an entity in its own right, but much more often, i've seen packages used just as subdividers of functionality. in these cases, the subdivisions were logical and served an organizing role, but the packages in this sense were not first class entities...
Excellent interview. Towards the end Dave touches on one of my favourite topics, namely dependency management within code. He hits the nail on the head, but is only able to scratch the surface of the problem in the last minutes of the interview.
In order to prevent long-term design degradation, and in order to efficiently execute software development in-the-large, the introduction of dependencies between components needs to be actively managed. If you want to dig deeper into this issue, you can read an extended paper on Complexity and Dependency Management that I wrote on this topic a while back.
Further articles on topics related to large scale software development are available at http://www.softmetaware.com/whitepapers.html.
To -> TheServerSide team
Guys, can you make *nix people happy and post a non microsoft version of the interview.
I mean, I like to be able to use mplayer or something alike for linux, and be able to watch the interview.
Your "Simposium" presentation are ok - can watch them in linux.
Can you do the same with the tech talks?
Works fine for me with mplayer (through the MediaPlayerConnectivity plugin) on gentoo.
Thank you SIR!
I was not aware of this firefox plugin.
I will give it a try.
I am in two minds about the talk. First I totally agree the diversity issue and that we as developers should make an effort to try different things in order expand our knowledge.
Also I agree that not all applications needs a 'heavy' implmentation. However I am not 100% sure the idea of promoting simplicity without warning of important of a structure way of doing things. This may somtime be longer but it does provide greater managability. Especially the idea of avoiding using a private method. You can always test that method with a public facade. no?
Some fo these talks I am afarid will promotes 'cow boys' behaviour. Which encapulate the phrase 'although somthing works it doesn't means that it is well engineered'.
However this interview maybe more of a plug to promote Ruby then a real effort of trying to help to increase our knowledge profolio.