Re: [tlug] New programming revision site - by a TLUG'er

[Fredric Fredricson <Fredric.Fredricson@example.com>]

 On 08/11/2010 05:30 AM, 黒鉄章 wrote:
> Hi Fredric,
> thanks for the candid feedback.
I never meant that your site is useless or anywhere near so. I have it 
bookmarked.
>     a web site- www.plrev.org <http://www.plrev.org/> ....
>
>     With all this I would say that I would never bother to remember stuff
>     that can a) be easily found in the documentation (like function calls)
>
>     .... I almost [try not burden my] memory with too much details.
>
>
> Having discussed this many times I think that we all share this idea, 
> that it's not worth taxing your memory with minor details. That's what 
> I said. That's what all my friends and colleagues said.
>
> Then, I went to job interviews. And you know what, interviewers nearly 
> never think that. They really believe that if you can't remember the 
> trivial differences, e.g. SQL's substring function's start pos 
> parameter is 1-indexed rather 0-indexed, that you were clearly lying 
> about having built data warehouses.
>
> "No", you say, "it isn't so. Engineers are nice people." But it is so- 
> go to a new company and the existing staff try to measure your 
> technical skills only against the subset that they use. I once 
> answered a question about the general aspects of C# in part by 
> comparing it to other languages such as Java and C++ (more a contrast 
> to the latter, of course). The look on the face of the C# 'guru' just 
> told me straight away he thought that was idiotic as answering an 
> algebra question with an essay on 17th century music. He had his 
> Microsoft Press textbook and if I didn't answer the same way I 
> obviously wasn't capable of programming C#.
>
> "Well", you say", "leave the one-trick ponies alone, you didn't need 
> that job." But I _do_ need a job- I quit my last full-time job right 
> at Lehman-shock <sigh>. So, I hope it'll be very useful for getting 
> past these trivia-question hurdles.
I can't really speak for what it's like in Japan, since I never worked 
there but where I live (Sweden) I think these types of interviews, like 
where you have to remember the arguments for substring() in SQL, are 
very rare.
I have been a manager myself, a few years ago, and I have never asked 
this type of questions. If it turns out that you lied about your merits 
to get a job and it becomes obvious, you can, and will, be fired (that's 
the law, at least).
There was a manager at my company who actually made applicants write a 
program, and then judged them on how "good" it was. I knew all 
programmers there and there was no indication that his programmers where 
better than any others (almost the opposite, but that's another story).

> Since I began this, however, I've also began to notice how many times 
> I pull down my reference book. That's not healthy for my programming, 
> taking a minute in the middle of one line to recall the correct 
> function/directive/setting/etc. name. I could have finished the block 
> of code I was writing in that time and keep more important stuff in my 
> working memory.
I agree but when I switch from, say, javascript to php (a surprisingly 
difficult shift) I only need to go to the documentation a few times. If 
I try to remember all syntax details and library calls for C++, php, 
perl, javascript and plpgsql I would quickly become confused. But maybe 
that just me.
> Cheers,
> Akira
A bit OT:

I suppose we all agree that a good programmer is not characterized by 
his detailed knowledge about minute details in the programming language. 
"Good programmer" here is defined as "valuable for the company where she 
is hired".

I would submit the following list (with priority).
a) Decent knowledge about programming in general and the target environment
b) Decent knowledge about the application
c) Able to cooperate with other programmers and testers
d) Good to expert knowledge about the application
.
.
y) Climbed the Mont Everest
z) Expert knowledge about a computer language.

Experts are not useless, but in general you only need one.

Whenever I have had major problems with an employee not being productive 
it's b) above.
(At one single occasion a).)

In a place where I worked for many years we did not expect a new 
programmer to be productive for the first 3-6 months, because that's 
what it took to understand at least part of the application.

/Fredric

begin:vcard
fn:Fredric Fredricson
n:Fredricson;Fredric
org:Ln4 Solutions AB
email;internet:Fredric.Fredricson@example.com
title:CTO
tel;home:+46 8 91 64 39
tel;cell:+46 70 677 58 48
version:2.1
end:vcard