in reply to Re: Code re-use: productivity gains vs. skill deprecation
in thread Code re-use: productivity gains vs. skill deprecation

This is true, the quality of much of CPAN is quite remarkable in parts. I do see their point with regard to skills however, it's too easy to rely on the high-level view you end up with when using modules and end up not knowing the 'essentials' of computer science such as data structures etc. I don't think they was saying that they'd not have any code to write, more that they feared their command of the 'computer science' aspects would wither and die.

I've seen this reach a quite significantly scary level in some of the Java programmers I've worked with. They're used to their nicely insulative APIs, and that is good enough 'to get the job done' reasonably well most of the time, but when the problem suddenly needs more indepth knowedge of datastructures, network protocols, graphics algorithms, general optimisation, or other things they've been insulated from they just fell to pieces as they couldn't deal with it. It seemed anything outside their little books of APIs was outside their knowledge and abilities.

They almost all did computer science degrees, so assumedly were shown at least the data structures and networks parts, but now they've spent so long in their supportive language that they're unable to deal without it.

I'm not saying that code reuse is bad, far from it as can be seen from my post above, rather that reliance upon higher-level APIs/modules can be detrimental to your low-level understanding. Reuse, but make sure you still know what's going on.

  • Comment on Re: Re: Code re-use: productivity gains vs. skill deprecation

Replies are listed 'Best First'.
Re: Re: Re: Code re-use: productivity gains vs. skill deprecation
by perrin (Chancellor) on May 22, 2002 at 15:00 UTC
    I would say it's not very important that these Java guys suck at graphics algorithms if they are great at rapidly building web applications and that's what their line of work calls for. They may not be uber-coders, but they may have a lot of very satisfied users who appreciate their talents.

    For those who long to earn more programming street-cred, there are always new areas where modules have not yet been written. Everyone knows something they think should be on CPAN that isn't there yet. Or else they know a feature that an existing module needs. Or a set of unit tests that an existing module needs. There are lots of ways to get experience without re-inventing wheels.

[reply]

      Sorry, should have specified a bit more context. Their lack of knowledge of graphics algorithms kind of hindered us when we were building a visualisation toolkit. These weren't server-side Java coders.

      There are many ways to get experience without building wheels, but quite often the reason those wheels exist is that they're what things rely on. I've rebuilt CGI, HTTP, email, and so on to make sure I understood the basic protocols involved, and rebuilt Data::Dumper as an experiment in how to do high-level data access and XS code. I'd never put these into production, my wheels aren't as good as others, but I'm very glad I did them so I can be more confident in my knowledge of them.

      Personally I find I'm more productive on something, and can see more flaws in potential implementations earlier, if I have that level of knowledge in the technologies it relies on.

      I am now working happily through something which may become a CPAN module if it stabilises and progresses enough, but it's relying on the preliminary work I did rebuilding wheels.

      There's a saying about building telescopes which I can't recall the original source of, it says it's quicker to build a four inch mirror and then a six inch mirror than it is to build a six inch mirror.

      That's what these re-invented wheels are to me, they're my four inch mirrors. I'll not use them, but I need the experience of building them to go onto other things. The module I'm now working on is the six inch mirror.

      I know a lot of what I've said here is similar to what I said here, but in a different context. I thought restating it in the new context made more sense than just linking to the old node though, so I hope you'll excuse my repetition.

[reply]

In Section Meditations