[Q, OT] Evaluating Software Engineer
chunsj at embian.com
Sat Jun 16 02:15:08 UTC 2007
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
> Thank you. Even though I'm not evaluating programmers for new
> - 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:
>>>> I've used a derivative of those guidelines (or something
> that looked
>>>> like it before reading the article) a few places.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v220.127.116.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Squeak-dev