[Q, OT] Evaluating Software Engineer

> 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
>
>

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] 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
>
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> >
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGcegTQqspS1+XJHgRAkY4AJ4qpPGDqeMv9gPZJmMx47nwS1tygACeJPi3
> 62g2BicFqnF2nAVVjnJLBRE=
> =ed8l
> -----END PGP SIGNATURE-----
>

> 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: [hidden email]
>> [mailto:[hidden email]] 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
>>>>
>>>>
>>

> Sungjin Chun,
>
>> 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.
>>
>
> I agree with Sebastian that abstraction skills are essential.  I've
> seen a lack of ability to create abstractions become the downfall of
> many potential developers.
>
> Here is an article and a couple of books I found useful for the
> improvement of developers:
> Teach Yourself Programming in 10 years
> http://www.norvig.com/21-days.html
>
> "Software Craftsmanship: The New Imperative" by Pete McBreen
> http://www.mcbreen.ab.ca/SoftwareCraftsmanship/
>
> "The Pragmatic Programmer: From Journeyman to Master" by Andrew Hunt
> and David Thomas
> http://www.pragmaticprogrammer.com/ppbook/index.shtml
>
> --Robert
>
>