-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you for your help. I'll try your suggestion.

Sebastian Sastre wrote:
> 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
> interest.
> 
> 	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
> authors.
> 
> 	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
>>
> 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
>>>>
>>>>
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGc0erQqspS1+XJHgRAmkLAJwPyi1j+NXJ0R/Nu98LrxVR4Bpm1gCfcnls
3hbtlKUAUEnd1SlfSp/2wdI=
=0TA8
-----END PGP SIGNATURE-----