Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



 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


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links