good skills

Steve Wessels stephan.wessels at sdrc.com
Wed Apr 5 13:11:26 UTC 2000


Lex Spoon wrote:

> Fun stuff!  I can't help but reply to a couple of things.
>
> First, just because *sometimes* software turns out to be enormously
> complicated, doesn't mean that it is always hopeless.  In fact, most
> Open Source developpers are more concietious about having good code than
> Netscape is.  :)

You got that right.  Peer pressure when working in the midst of legends does tend to make one think about the quality of the code
that gets published.

> As an example of this, I once stared at tcpdump traces
> for a while and noticed that Linux was sending out ABORT packets
> (whatever they're called, FIN I think) in a circumstance that was really
> frustrating.  Well, hey, it's open source, I can change it.  So, I dug
> into the kernel with absolutely no knowledge of how Linux's networking
> code works, found the line that said tcp_fin() in a relevant looking
> place, and commented it out.  Recompile and it worked.  I still don't
> know how Linux's networking works, but I was able to make a small tweak
> by using some simple reasoning and then throwing a "hail mary".

This is an excellent example of the viewpoint that new Smalltalk developers need to take to keep from being overwhelmed with the
substantial body of work that Squeak represents.

>
>
> In fact, skill at reading software is woefully absent in most
> programmers (myself included).  It's not at all the same skill as being
> able to *write* software.  I'd expect that software in general would be
> better, if CS programs forced students to *read* a large variety of
> *real* programs, instead of just writing one piece of crud after
> another.  Sort of like Programming Lit.

Amen.  I believe that Smalltalk encourages developers to browse before you write.  In fact, to follow in Kent Beck's style, the goal
is to read a lot of code and write damn little.

It seems that troubleshooting skills are also related to being able to read and understand code that is already written.  It's very
unusual for new developers in the work force to be placed into a project where the code has to be written fresh.  Usually there's a
huge amount of legacy code to wade though.  Deep places where sharks swim and sometimes you never come back.  :)

This is such an excellent idea (skill at reading code) that it would be good to use it next time I interview someone for a technical
developer's position.

>
>
> Second, you say that no companies spend time making their code
> *smaller*, but there are some rare exceptions.  I had a boss recently
> who loved to brag about his "negative lines of code" counts that he
> would turn in to his boss on a previous job.
>
> But why, as you observe, are such groups so rare?  The problem seems to
> be that we can't *quantify* the difference better-written code will
> make.  Sure, most people will try to write reasonable code up front.
> Probably even Netscape's programmers tried to do so :).  But when it
> comes time to add a *new* feature, how often do programmers take the
> time to integrate the feature nicely, and how often do they quickly hack
> it onto the side like a third arm (or fourth, or fifth...)?  Probably
> they do the latter a little too often.  And it's not because they are
> foolish; it's simply very hard to understand the benefits of coherent
> software, and it's very easy to understand the benefits of having a
> working demo for your boss.  :)

I have bumped into many developers that have called themselves OO, after working in C++ and Java, who take pride in their ability to
develop applications quickly.  I'm usually quietly thinking that a team that develops software quickly does not impress me much.
The team that then also produces "version 2" - with more features and capability, in a short time, does.

 - Steve

>
>
> Lex





More information about the Squeak-dev mailing list