[Q, OT] Evaluating Software Engineer

Sebastian Sastre ssastre at seaswork.com
Fri Jun 15 14:29:53 UTC 2007

Hi Sungjin,

	depending the case there are times in which is not computational
skills that should be evaluated and that help more in the software
development process.

	First of all, abstraction skills is essential, so whoever that has
skills to "see" the things behind the first impression that things usually
gives will have more chances to capture the correct escence of whatever has
to be modeled. Objects are "concept capsules" so it is essential because
objects are the bricks here. So perspicacy should be evaluated. To see
things behind the things. Original interpretation of reality.

	In a second phase you will notice that those bricks are a lot more
like atoms or molecules than  real briks because they can be as static as
you want but software will be a lot more interesting when they starts to
behave dynamically: the so called interactivity. So when you realize of the
importance of this, the messages become the real celebrity objects because
they make interactivity between machines possible. From that interactivity
usually you should manage to extract (valuable) experiences that only
computers can give.

	Again, whoever that has skills to *see* patters of behavior (this
time dynamic, so N times more complex) will have more chances to capture
succesfully and assertively with the dynamic behavior of the model of

	But all that skills isolated is philosophy and build software is
pragmatic. So it is a constant fight for materialization of those
philosophically born concepts that seems to be up there in the sky by
converting them into  rock-solid machines (smalltalk
objects/frameworks/applications). Because of that is that other fields of
knowledge than computer sciences should matter for software authors
(specially smalltalkers) and that varies a lot depending on specializations,
tastes, profiles, objetives. But in general Polymathy is valuable and kind
of inevitable path.

	I'll put you a naif example to illustrate this: a "computer young
guy" computer expert and good in abstraction but with poor vocabulary and
culture that for instance don't knows (to the point needed) what a juridic
person is and what it implies barely could make for you the right model
because it laks of vocabulary, experience (maybe interest) in knowing what
that is or having any resistance to go read civil code a little to undertand
correctly what it implies, so he/she miss the "big picture" and that almost
guarantees that a wrong static model will be built letting extremely low
chances of success to the dynamic model. Is a software problem? No, is an
authoring problem. I give you this example to you to see that other domains
has a lot of relevance. Domains that are or are not dominated by software

	Paradoxically at this point (and only reached this point), you will
find that conservative interpretations of reality are also valuable. This
will leave you far away of what I like to call the "useless creativity"
(like creating a Client class instead of a N times more complete and
powrfull and loyal to reality JuridicPerson class). So to have the discern
for switching when you should keep yourself conservative and when you should
switch to be creative is critical. As principle that works for me,
(conceptual) creativity should not be used by default but when you find a
lack of concepts for something you found use creativity freeing your mind at
your very best (absolutely unconditioned). I consider a quick example of
that modeling Continuations. They made tangible the intangible.

	So.. the good news is that with Smalltalk you have a virtual
environment that makes feasible for you to keep yourself near the conceptual
and more permanent domain and, if you are careful enough, far from technical
and more ephemeral domain (sadly a usually maniac technologic mess tied to
poorly architected hardware).

	That, maybe, is one of the reasons of why smalltalk is theoretically
and pragmatically irrefutable from the 70's. It has a lot of things that are
there from a long ago materialized with conceptual completeness while other
technologies has to reinvent itselves all the time full of basic conceptual
holes. Machines are reflections of it's authors.

	All the best,

Sebastian Sastre

> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Sungjin Chun
> Enviado el: Jueves, 14 de Junio de 2007 22:15
> Para: The general-purpose Squeak developers list
> Asunto: Re: [Q, OT] Evaluating Software Engineer
> Hash: SHA1
> Thank you. Even though I'm not evaluating programmers for new 
> employment
> - - I'm trying to prepare evaluation of our programmers for 
> suggesting what/where/which direction should they make more 
> effort to improve.
> Thanks again.
> Robert Stehwien wrote:
> > Sungjin Chun,
> > 
> >> As my subject says, I want to know whether there is 
> general sheet or 
> >> something equivalent for software developer evaluation. I know the 
> >> area of programming is more important but I believe that 
> there should 
> >> be common requirements for software developer or programmer.
> >>
> >> Any kind of doc/url or else will be helpful :-)
> >>
> > 
> > Here are a few useful articles on the topic that might give 
> you a start:
> > 
> > http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
> > http://www.joelonsoftware.com/articles/ThePhoneScreen.html
> > 
> > I've used a derivative of those guidelines (or something 
> that looked 
> > like it before reading the article) a few places.
> > 
> > --Robert
> > 
> > 
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iD8DBQFGcegTQqspS1+XJHgRAkY4AJ4qpPGDqeMv9gPZJmMx47nwS1tygACeJPi3
> 62g2BicFqnF2nAVVjnJLBRE=
> =ed8l

More information about the Squeak-dev mailing list