On Fri, Jun 21, 2013 at 01:11:44PM -0700, Walter Bright wrote:
> On 6/21/2013 12:49 PM, John Colvin wrote:
> >If you want a normal programming job, you need to show more real world experience than a PhD, but just throwing out people who have proved their originality and in depth understanding of a topic through a PhD is nothing short of absurd.
> 
> You need a mix of people - young and old, newbies and old hands, academics and mechanics, detail guys and big picture guys, to have a healthy dev organization.

This reminds me of a HR seminar I attended once, where an example was given of a particular (real) company who only ever hired top-notch programmers.  They set their standards very high, and have a review system that would basically fire anyone whose skills are sub-par. The guys in charge thought this was going to skyrocket the company into success.

But what actually happened was, nobody wanted to work on mundane projects -- maintaining existing systems, keeping the servers running, doing routine chores necessary for everyday operations, etc.. There was a lot of infighting on who gets to work on the fun stuff, and the people who didn't get it began to quit one by one. Eventually, none of the mundane things were adequately taken care of, and most of the employees left 'cos they didn't get to do what they wanted, and the company collapsed.


T

-- 
Many open minds should be closed for repairs. -- K5 user

On 6/21/2013 1:34 PM, H. S. Teoh wrote:
> But what actually happened was, nobody wanted to work on mundane
> projects -- maintaining existing systems, keeping the servers running,
> doing routine chores necessary for everyday operations, etc.. There was
> a lot of infighting on who gets to work on the fun stuff, and the people
> who didn't get it began to quit one by one. Eventually, none of the
> mundane things were adequately taken care of, and most of the employees
> left 'cos they didn't get to do what they wanted, and the company
> collapsed.

Yup.

Similar things happen if you only hire people fresh out of college. Things are find for a while, and then everyone wants to move up into management at the same time.

On Fri, Jun 21, 2013 at 12:11:51PM -0700, Walter Bright wrote:
> On 6/21/2013 3:04 AM, Jacob Carlborg wrote:
> >But I do some researcher about TDD and similar techniques, use my common sense, pick some pieces from here and there and use what I think works.
> 
> I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem.
> 
> In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror.

+1, words of wisdom.

>From "high-level language" to "structured programming" to "OO" to
"aspect-oriented programming" to X-oriented Y-driven whatever that is the next bandwagon, it's all the same story repeated over and over. It's supposed to be the panacea that will make you able to ship a product just by pressing a single magic button, solve all your programming problems, and cure world hunger. Then you actually get into it, and discover that you still have to (gasp!) use your brain to get your program working. And life goes on as before.


> But there is one technique that stands head and shoulders above the others in improving code quality, sometimes dramatically so. That's unit testing coupled with a coverage analyzer.
> 
> I can't even count the number of times I thought "this is so simple, I couldn't have gotten it wrong, I doan need no steeenkin unit tests." But I write a couple anyway, and you can guess the rest.

Yeah, I used to be firmly in the camp of "this code is so trivial, so *blatantly* correct, that it constitutes its own proof of correctness." Until D came along and shamed me into writing unittests for said "trivial" code, and suddenly I found myself sinking in the flood of bugs, failing corner cases, and (gasp!) typos, that I hadn't imagined were there all along.


> Whether you write the unit tests before, during, or after the module is written is irrelevant.

Yeah, sometimes I start with one or two tests before, usually a whole bunch in the middle, and a couple after (followed by a lot more later when bugs are inevitably found and fixed). The best part about D's built-in unittests (and I keep harping on about this) is that they're so dang convenient you'd be foolish for not writing them. They can be integrated into the very process of coding -- which has singlehandedly improved the quality of my code by leaps and bounds.


T

-- 
IBM = I'll Buy Microsoft!

On Fri, 21 Jun 2013 17:48:25 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2013-06-21 16:56, H. S. Teoh wrote:
> 
> > +1, me too! I can say that 85-90% of what I do at work today, I learned from my personal coding projects, not from the CS courses I took in university. (That's why I like to joke about CS grads knowing more about uncomputable problems than computable ones...)
> 
> It feels like there's something wrong with the world here :)
> 

There definitely is. I spent a total of somewhere around 6 years in college, but somewhere around the middle of that I made the deliberate decision to *not* get a degree of any sort. That was because I wanted no part in helping to perpetuate the incredibly widespread myths/lies about academic achievement. I've never regretted that decision. (The one decision I *did* regret was not leaving college entirely after the first year.)

On Friday, 21 June 2013 at 20:25:28 UTC, H. S. Teoh wrote:
> On Fri, Jun 21, 2013 at 09:49:21PM +0200, John Colvin wrote:
>> On Friday, 21 June 2013 at 19:14:18 UTC, Walter Bright wrote:
>> >On 6/20/2013 8:50 PM, H. S. Teoh wrote:
>> >>One of my previous supervisors told me that when he gets resumés, as
>> >>soon as he sees "Ph.D" he chucks it straight into the trash.
>> >
>> >He'd have missed out on Andrei, then.
>> 
>> And a lot of other people who are driven towards new ideas.
>> 
>> There's a fair amount of inverted snobbery about academia here.
>> 
>> Ultimately, a PhD shows the ability to conduct original research and
>> present it. It doesn't make you a great programmer, but then again
>> *it never purports to*. Nor does a computer science degree.
>
> According to my ex-supervisor (and I'm not saying I agree with him), it
> indicates that one is opinionated enough to originate ideas, and
> stubborn enough to successfully defend said ideas, which can be
> detrimental in a team setting if the idea wasn't a good one.  (And since
> a PhD doesn't purport to make you a great programmer, and he was looking
> for great programmers rather than researchers, that could be a reason
> for his views on the matter.)
>
>
>> If you want a normal programming job, you need to show more real
>> world experience than a PhD, but just throwing out people who have
>> proved their originality and in depth understanding of a topic
>> through a PhD is nothing short of absurd.
>
> Well, my ex-supervisor *did* have a reputation of having many
> "interesting" (i.e. extreme) ideas about many things. :) I can't say I
> subscribe to his views on this matter, but what I was trying to get at
> was the prevalent fallacious fixation on academic achievement (i.e.
> equating "he has good grades / a degree / a PhD" with "he is a good
> programmer").  Too many potential employers can't see beyond that, or
> are not willing / don't have the time and energy to do so, thus
> resulting in the situation where people are being hired because of their
> academic achievement, but are expected to have skills not necessarily
> implied by said achievement. Then when such hires consistently produce
> sub-par work, some people get provoked to equate "PhD" with "poor
> programming skills".
>
> This situation wouldn't have developed if employers evaluated candidates
> based on their *skills* rather than by the credentials on paper.  But in
> this day and age where time is never enough, it's all too convenient to
> dismiss a candidate because he has no academic credentials rather than
> to spend the time / energy to review unlikely candidates on the
> off-chance that perhaps they might turn out to be hidden programming
> prodigies. Or to blindly hire a candidate *with* said credentials
> because someone of high academic standing is likely to be skillful
> enough to do the job, rather than to spend to time / energy to check if
> this is actually the case. (Not to mention that all too often, the ones
> with hiring powers may not necessarily have the ability to discern real
> skills from a smooth talker.)
>
>
> T

Agreed on all points.

As an aside: what defines a "good programmer"  is of course dependant on the task. Many academics do write effective code, quite quickly, and get a lot of quite convoluted work done by coding.

E.g. I would (entirely hypothetically) happily hire a physics PhD to write high-level data-analysis routines in python, but i'd be wary of getting them to work on a high security web-app. On the flip side, I would be wary of hiring an enthusiastic college dropout to write an accurate fluid simulation, but they might easily fit the definition of "good programmer" for extending a web framework.

On 6/21/13 5:59 AM, Jacob Carlborg wrote:
> On 2013-06-21 07:57, H. S. Teoh wrote:
>
>> we got to ask HR to first
>> administer a technical test before any interviews are arranged; test
>> results are reviewed before deciding to interview the candidate
>
> I done tests like that, they all suck. This is how it usually works:
>
> You get a problem to solve. They say: "solve it anyway you want, using
> any language you want". You solve it farily quickly and straight
> forward. Then they say, "you are not allowed to use that function".
> Basically they're saying it's cheating. Then you remove that function
> and change the implementation accordingly. Then they say, "you are not
> allowed to use that other function". You change the code accordingly and
> this dance continues. Then you're thinking to yourself, "Am I supposed
> to reimplement the standard library?".
>
> I would say, most times, it's almost irresponsible to _not_ use the
> standard library. A bunch of people, a lot smarter than I, have had a
> good 20 years or so to perfect and fine tune the standard library. Not a
> chance in hell that I'm going to beat that, on an interview, with code
> written on a whiteboard.
>
> A side note. You're of curse not allowed to look at any documentation at
> all and you're not allowed to use a text editor. You write the code on a
> whiteboard, yes a _whiteboard_.
>
> That's just so stupid. That's not how programming works in the real
> world. Why the hell do they think IDE's have built in, easy to
> read/find, documentation.

If there's any need to reach for documentation, the interviewer has failed. When interviewing we (at Facebook) ask problems that are likely to appear in a normal day's work, but for which the typical libraries don't help. (E.g. many libraries don't can't help with implementing unstable remove (see std.algorithm).)

Also it's fair to ask about implementing a stdlib function itself if the interview concerns some systems-level work; e.g. brute-force strstr() is fair game and I think any engineer should be able to lift it off the ground quickly (to my dismay, only a fraction can). Paradoxically use of stdlib functions may actually hurt; I've seen people who e.g. call strlen() in a loop in order to implement strstr()!


Andrei

On Friday, 21 June 2013 at 21:33:43 UTC, Andrei Alexandrescu wrote:
> brute-force strstr() is fair game and I think any engineer should be able to lift it off the ground quickly (to my dismay, only a fraction can).

But, should the return value be const or not? :P


I think I'd write in D just cuz of inout().

On Fri, Jun 21, 2013 at 05:33:45PM -0400, Andrei Alexandrescu wrote: [...]
> Also it's fair to ask about implementing a stdlib function itself if the interview concerns some systems-level work; e.g. brute-force strstr() is fair game and I think any engineer should be able to lift it off the ground quickly (to my dismay, only a fraction can).

Yeah, I was rather dismayed at how many people lacked basic understanding of the programming language they purport to be skilled in. Like not understanding variable shadowing in C, or simple closures in Javascript (not the evilly-nested convolution I tested for in a different test question :-P).


> Paradoxically use of stdlib functions may actually hurt; I've seen
> people who e.g. call strlen() in a loop in order to implement
> strstr()!
[...]

My favorite example of poor strlen() usage is writing "strlen()==0" in a
loop condition.

More typical causes of disqualification, though, are what one of my university professors affectionately called "squirrelly code": code that *probably* does what it's supposed to, but does so by roundabout, non-obvious ways, running around here and there doing little things that don't really relate directly to the problem at hand (like squirrels running around hunting for their forgotten stash of nuts). Code like this typically demonstrate a lack of understanding of programming in general, or lack of understanding of the problem at hand, or inability to identify and address the salient points of said problem. Typical symptoms include declaring and using useless variables, calling printf inside a function that shouldn't be doing I/O, doing unnecessary type conversions to perform trivial computations (converting int to string and attempting to do arithmetic on the digits in the string), odd usage of loops and conditionals in unexpected places, using comments to urge the computer to do what one wishes, etc..

The software analogue of Rube Goldberg machines, if you will. :-P


T

-- 
Век живи - век учись. А дураком помрёшь.

On Fri, 21 Jun 2013 09:47:46 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> universities that actually *teach* real programming are more interested in finding solutions to uncomputable problems than teaching students how to solve computable ones
> 

That doesn't match my experience (also in the US here). Granted, all my info is from ten years ago, but what I saw was mainly a bunch of what The "Joel on Software" guy called "Java Schools" <http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html>.

The following includes what I've seen at BGSU and OSU (party schools, not that I personally attended OSU, but I did have a friend that went through OSU's "RESOLVE/C++" stuff) and also JCU (a private univ that, at least around Cleveland, is highly-regarded by everyone except me).

What I've seen at these places, and apparently many others from what I understand, is that while they *do* recognize the importance of creating programmers, the problems are:

- The theory is minimal to make sure they get all those high-paying
  students through the revolving door.

- Tests and exams do *not* teach people. An yet, that's where the
  emphasis is, instead of on instruction.

- The really *big* issue: You just simply CANNOT expect people to go
  from beginner to competent programmer when they spend *at most*
  one-third of their credits, and about 3 hours a week, over a mere 4
  years on actual programming material instead of irrelevant liberal
  arts garbage that *belongs* in high school, not a college so-called
  "major".

- The nasty little details like pointer/memory problems, linker errors,
  etc that real people have to deal with are neatly glossed over and
  sidestepped.

- There was one CS101 teacher (I had to tutor her unfortunate students)
  who constantly bragged about being from a real-world software
  company...but she was a Java-addict (circa v1.2-v1.4) who kept trying
  to teach OO *before* basic flow-of-execution. Consequently, none of
  her unfortunate students had the slightest clue what was going on.

- Many of the professors are terrible programmers themselves. For
  example, I had one who openly admitted the only language he knew was
  C, and yet at one point it became painfully obvious that he had
  almost no comprehension of null-terminated strings.

- Many of the teachers don't even teach, they just collect the
  thousands of dollars in tuition and give you a book recommendation
  (really more of a "demand" than a recommendation). Now, I'm a strong
  believer in being self-taught and learning from books, but all I need
  for that is a library card, not a $100k debt and four years of elitist
  attitudes from people who clearly don't know what they're doing
  anyway.

Just for laughs I just slapped together a strstr and it made me realize a little thing I do in D that I never did in C:

assert()

I use it all over the place in D, pretty much any time I make an assumption, I slap it down in an assert.

But I don't I ever, not once, used any kind of assertion in C or C++. I think this is a fairly significant gain that can be attributed to it being built in to D. It is just silly not to do it when it is there.