Is Necessary for all rails employee know computer knowledge?

[Michel Thapa]

Hi all Is Necessary for all rails employee know computer knowledge?
Because for last 2 week i am visiting rails department, there i show
some employee dos not know how to open the system, my way of saying is
necessary for all employee should know it.

 

[Pascal J. Bourguignon]

Hi all Is Necessary for all rails employee know computer knowledge?
Because for last 2 week i am visiting rails department, there i show
some employee dos not know how to open the system, my way of saying is
necessary for all employee should know it.

It's not necessarily necessary for every rails programmer to know
anything about computers, or computer science.

Read:

http://www.google.com/gwt/n?u=http:...ver&source=pagecreator&gsessionid=UAjfJNzLRMc

 

[Robert Klemme]

Hi all Is Necessary for all rails employee know computer knowledge?
Because for last 2 week i am visiting rails department, there i show
some employee dos not know how to open the system, my way of saying is
necessary for all employee should know it.

I am not sure what you mean by "how to open the system". Maybe it is
more important to improve knowledge of English or Japanese so your
colleagues can read the documentation.

Kind regards

robert

 

[Eleanor McHugh]

It's not necessarily necessary for every rails programmer to know
anything about computers, or computer science.

Read:

http://www.google.com/gwt/n?u=http:...ver&source=pagecreator&gsessionid=UAjfJNzLRMc

It's a fascinating article, not least because I can see where both the
author and the interviewee are coming from. Once you know a decent
amount of computer science it's often difficult to take developers
seriously who lack that background, but by doing so we miss the
benefits that knowledge from other disciplines can offer in solving
complex problems.

I started out in physics and I've spent a fair amount of my
professional career arguing with very capable CS experts over all
kinds of problems which are elementary with my background but have
them scuttling back to graph theory, and conversely I meet a lot of
web developers who've come from a non-academic and despite being very
good at their specialism have a complete lack of confidence about
their abilities. So no, in my opinion a rails programmer doesn't have
to be a whizz at computer science or even necessarily with computers -
although what kind of masochist works all day with tools that they
neither like or understand?

On the other hand there are certain key abilities that any developer
does need, and which I've found surprisingly lacking in many that I've
worked with: a grasp of basic logic; ability to sequence and classify;
a cool head when things aren't going well; intense curiosity.
Unfortunately all of these are as likely to get you into trouble as
they are to get your projects out the door...

I must admit though that if I was dealing with a Rails team I would
expect anyone who was a developer to know how to run up the
application at least locally as that's a five minute google and falls
under the 'intense curiosity' category


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Todd Benson]

On Tue, May 20, 2008 at 10:05 AM, Eleanor McHugh

It's a fascinating article, not least because I can see where both the
author and the interviewee are coming from. Once you know a decent amount of
computer science it's often difficult to take developers seriously who lack
that background, but by doing so we miss the benefits that knowledge from
other disciplines can offer in solving complex problems.

I started out in physics and I've spent a fair amount of my professional
career arguing with very capable CS experts over all kinds of problems which
are elementary with my background but have them scuttling back to graph
theory, and conversely I meet a lot of web developers who've come from a
non-academic and despite being very good at their specialism have a complete
lack of confidence about their abilities. So no, in my opinion a rails
programmer doesn't have to be a whizz at computer science or even
necessarily with computers - although what kind of masochist works all day
with tools that they neither like or understand?

On the other hand there are certain key abilities that any developer does
need, and which I've found surprisingly lacking in many that I've worked
with: a grasp of basic logic; ability to sequence and classify; a cool head
when things aren't going well; intense curiosity. Unfortunately all of these
are as likely to get you into trouble as they are to get your projects out
the door...

I must admit though that if I was dealing with a Rails team I would expect
anyone who was a developer to know how to run up the application at least
locally as that's a five minute google and falls under the 'intense
curiosity' category


Ellie

You left out philosophical differences, which is where the rubber
meets the road at times. Everything you said makes sense, though.
I've been waiting to do a monologue about that, but realized that I'm
not eloquent enough, and also chickened out a bit

Here's hiring criteria for me:

I throw a framework (or, language) at the person, let them play, and
let them show me something in a day or two (length of time depends on
frame/lang); bonus points for seeing something that I haven't.

Credentials mean almost nothing to me. If you can write a book,
great, but don't try to tell me at the same time you know how to solve
problems. The two things are "almost" orthogonal.

Todd

 

[Phillip Gawlowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eleanor McHugh wrote:

|
| It's a fascinating article, not least because I can see where both the
| author and the interviewee are coming from. Once you know a decent
| amount of computer science it's often difficult to take developers
| seriously who lack that background, but by doing so we miss the benefits
| that knowledge from other disciplines can offer in solving complex
| problems.

The largest benefit is derived from attacking the same problem from
different angles, which gives more options and a better understanding of
the problem space.

Discounting someone because they don't know the Big-O notation by heart
can be as dangerous as hiring somebody who knows only algorithms.

| I started out in physics and I've spent a fair amount of my professional
| career arguing with very capable CS experts over all kinds of problems
| which are elementary with my background but have them scuttling back to
| graph theory, and conversely I meet a lot of web developers who've come
| from a non-academic and despite being very good at their specialism have
| a complete lack of confidence about their abilities.

Well, if next to all advice is 'you have to know Big-O notation, and
half the *-tree algorithms so that I would even consider reading your
resume', a lack of confidence does emerge.

I know, I am there, and finding the courage to apply for a job, or going
independent is an exercise in itself.

| So no, in my
| opinion a rails programmer doesn't have to be a whizz at computer
| science or even necessarily with computers - although what kind of
| masochist works all day with tools that they neither like or understand?

Programmers, as opposed to developers. A programmer sees software
development as a means to a paycheck end. Developers see software as a
means in itself, with the paycheck being a bonus.

I am, of course, painting with a broad brush here..

| On the other hand there are certain key abilities that any developer
| does need, and which I've found surprisingly lacking in many that I've
| worked with: a grasp of basic logic; ability to sequence and classify; a
| cool head when things aren't going well; intense curiosity.

Well, what is basic logic? The boolean logic found in computer
languages? Abstract logic? Aristotelian logic?

I guess you mean both boolean as well as abstract logic, as those go
hand in hand (pretty much). And yes, both are quite important areas of
knowledge.

Since computers are only good at distinguishing 0's and 1's, knowing how
logic works helps in understanding program flow, and programming in it self.

It also enables to look at systems programming, and even peek into chip
design (with AND, OR, XOR, NAND gates....).

Which all helps in staying sharp (and learning that, in the end, the
language matters less than the ability to think one's way out of a paper
bag ).

Interestingly, the 'intense curiosity' is something that is seen as a
key element by a lot of high profile developers, which I noticed while
reading Ed Burn's 'Secrets of the Rock Star Programmers: Riding the IT
Crest'[0]. From James Gosling, to Dave Thomas (not the Programming Ruby
one ), to Andy Hunt, to the Java Posse, curiosity is seen as pretty
much elementary.


| I must admit though that if I was dealing with a Rails team I would
| expect anyone who was a developer to know how to run up the application
| at least locally as that's a five minute google and falls under the
| 'intense curiosity' category

Well, I'd like to see knowledge about deployment options, too. Not just
'mod_rails', or 'apache reverse proxy with mongrel pack'.

Though, similar should be expected by non-Rails developers: Available
options, and their pros and cons in situations (at least in a
superficial way that enables deeper research).

[0]
<http://www.amazon.com/Secrets-Rock-Star-Programmers-Riding/dp/0071490833/>


- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com

~ "That's the problem with science. You've got a bunch of empiricists
trying
to describe things of unimaginable wonder." -Calvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgy9MEACgkQbtAgaoJTgL/BCQCeKxFZig02+3RI7wqmdK2IpABT
TIkAnjtOuZm2kOfjt1WowJIlr+7fZyB8
=WkqA
-----END PGP SIGNATURE-----

 

[Eleanor McHugh]

Eleanor McHugh wrote:
| I started out in physics and I've spent a fair amount of my
professional
| career arguing with very capable CS experts over all kinds of
problems
| which are elementary with my background but have them scuttling
back to
| graph theory, and conversely I meet a lot of web developers who've
come
| from a non-academic and despite being very good at their
specialism have
| a complete lack of confidence about their abilities.

Well, if next to all advice is 'you have to know Big-O notation, and
half the *-tree algorithms so that I would even consider reading your
resume', a lack of confidence does emerge.

I know, I am there, and finding the courage to apply for a job, or
going
independent is an exercise in itself.

You're not alone. I've ranted several times on my livejournal about
the frustrations of job hunting and I'm effectively unemployable right
now thanks to my left-field outlook. Mind you business here in the UK
has always had an ambivalent attitude to creative thinking: they all
claim to want it, but they none of them like dealing with it in the
raw lol

| On the other hand there are certain key abilities that any developer
| does need, and which I've found surprisingly lacking in many that
I've
| worked with: a grasp of basic logic; ability to sequence and
classify; a
| cool head when things aren't going well; intense curiosity.

Well, what is basic logic? The boolean logic found in computer
languages? Abstract logic? Aristotelian logic?

I guess you mean both boolean as well as abstract logic, as those go
hand in hand (pretty much). And yes, both are quite important areas of
knowledge.

Even Aristotelian logic would be a step forward on some of the code
I've read over the years!
I've probably posted this link before (http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf
) which is a paper demonstrating one of the unspoken problems of the
development world - that a noticeable minority of graduates with CS
degrees are fundamentally incapable of programming. I could speculate
that these will mostly go into the management side of the industry,
but I'll leave that to Dilbert strips.

Since computers are only good at distinguishing 0's and 1's, knowing
how
logic works helps in understanding program flow, and programming in
it self.

It also enables to look at systems programming, and even peek into
chip
design (with AND, OR, XOR, NAND gates....).

Which all helps in staying sharp (and learning that, in the end, the
language matters less than the ability to think one's way out of a
paper
bag ).

Even when I was coding for the bare metal I always preferred to solve
problems in my head first and then worry about assembly language and
bit-strings later. I never came up with a solution that couldn't be
coded, but I often came up with code that I would never have devised
if I'd put implementation concerns foremost.

Interestingly, the 'intense curiosity' is something that is seen as a
key element by a lot of high profile developers, which I noticed while
reading Ed Burn's 'Secrets of the Rock Star Programmers: Riding the IT
Crest'[0]. From James Gosling, to Dave Thomas (not the Programming
Ruby
one ), to Andy Hunt, to the Java Posse, curiosity is seen as pretty
much elementary.

Alas it's the main thing that formal education tries to knock out of
us at an early age, but I don't know any hacker worth their salt who
doesn't possess it.

Curiosity is what teaches us new tricks without there being an
immediate pay-off, and its from exploring problem spaces in that
lurching haphazard manner that we learn general principles which can
be applied to cast a new light on otherwise intractable or ignored
problems. It's the essence of hacking in all senses of the term (both
good and bad) and the quickest path to grokking stuff. It's also a
brilliant justification for procrastination.

| I must admit though that if I was dealing with a Rails team I would
| expect anyone who was a developer to know how to run up the
application
| at least locally as that's a five minute google and falls under the
| 'intense curiosity' category

Well, I'd like to see knowledge about deployment options, too. Not
just
'mod_rails', or 'apache reverse proxy with mongrel pack'.

Though, similar should be expected by non-Rails developers: Available
options, and their pros and cons in situations (at least in a
superficial way that enables deeper research).

I couldn't agree more. When I meet a new team I want them to be as
deeply shallow as possible: not experts in what I'm doing, but clearly
willing and able to become experts as the project progresses without
any pressure from me. Hopefully they'll even end up know more than I
do, then I can steal knowledge from them


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Eleanor McHugh]

You left out philosophical differences, which is where the rubber
meets the road at times. Everything you said makes sense, though.
I've been waiting to do a monologue about that, but realized that I'm
not eloquent enough, and also chickened out a bit

I normally wait until I'm particularly ticked off and then rant on
LiveJournal, where nobody's likely to be reading.

Here's hiring criteria for me:

I throw a framework (or, language) at the person, let them play, and
let them show me something in a day or two (length of time depends on
frame/lang); bonus points for seeing something that I haven't.

I get them to explain their three worst projects and how their
contributions screwed them up. It's surprisingly informative. For one
thing I've never met a hacker who didn't take pride in their follies
so that instantly weeds out those in development for what I consider
the wrong reasons (i.e. just for the paycheque). I also apply the
boffin test, which is whether or not the person is engaging enough to
want to discuss tech over beer on one of those slow afternoons when
there's no work to be done.

Credentials mean almost nothing to me. If you can write a book,
great, but don't try to tell me at the same time you know how to solve
problems. The two things are "almost" orthogonal.

I'd make allowances if the author wrote all the code in the book, and
it solved some interesting and non-trivial problem: Andrew Tanenbaum
for example would definitely get to the top of any shortlist for
Minix. But that's not what most programming books are about.
Especially not the Java books ;p


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Bill Kelly]

I get them to explain their three worst projects and how their
contributions screwed them up.

Awesome


I learned some powerful lessons on one of those 10 years ago...
unfortunately, too late for the project.



Regards,

Bill

 

[Phillip Gawlowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eleanor McHugh wrote:

|
| You're not alone. I've ranted several times on my livejournal about the
| frustrations of job hunting and I'm effectively unemployable right now
| thanks to my left-field outlook. Mind you business here in the UK has
| always had an ambivalent attitude to creative thinking: they all claim
| to want it, but they none of them like dealing with it in the raw lol

Worst thing: I'm utterly self-taught, too. Everything I learned, I
wanted to learn.

~From Ruby, to Rails, to CSS, to GTK, to good practices in UI design.
Though, this shows me how little I actually know, and how much more I
have to learn.

Another difficulty is, to find worthwhile sources of information and
knowledge. I've come to abhor search engines, as they are filled with
cruft. Especially Google. But in the hunt fro bragging rights over the
biggest index of websites, the usefulness of indexing knowledge gets
handed to machines, and not editors.

Wikipedia is plagued by the opposite: Too many people, creating content
that is mediocre to down right bad, in addition to power games, rather
than collecting actual knowledge (delete for something no being notable?
WTF? Disk space is cheap nowadays!).

Any way, the uphill battle I am facing is that I can't make my resume
pass the buzzword bingo by machines. But I'm working on that.


|
| Even Aristotelian logic would be a step forward on some of the code I've
| read over the years!
| I've probably posted this link before
| (http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf) which is a
| paper demonstrating one of the unspoken problems of the development
| world - that a noticeable minority of graduates with CS degrees are
| fundamentally incapable of programming. I could speculate that these
| will mostly go into the management side of the industry, but I'll leave
| that to Dilbert strips.

Considering that I, at best an amateur, at worst a clueless newbie, have
already read more technical books than the industry average..

(And I'm living off of the goodwill of those who find my Amazon Wishlist
and me books from there, too. Otherwise it'd be more!)

| Even when I was coding for the bare metal I always preferred to solve
| problems in my head first and then worry about assembly language and
| bit-strings later. I never came up with a solution that couldn't be
| coded, but I often came up with code that I would never have devised if
| I'd put implementation concerns foremost.

Yes, it is similar for me. While I am (for the moment) stuck in rather
high-level languages like Java, .NET, or Ruby, I think through a
problem, and come up with solutions. The emphasis being on 'solutions'.
I weigh pro and cons of what I come up with, after some investigation
and/or prototyping in the problem space, and after that, I can actually
make decisions as to which solution to use *in this situation*.

| Alas it's the main thing that formal education tries to knock out of us
| at an early age, but I don't know any hacker worth their salt who
| doesn't possess it.

Full agreement on both counts.

| Curiosity is what teaches us new tricks without there being an immediate
| pay-off, and its from exploring problem spaces in that lurching
| haphazard manner that we learn general principles which can be applied
| to cast a new light on otherwise intractable or ignored problems. It's
| the essence of hacking in all senses of the term (both good and bad) and
| the quickest path to grokking stuff. It's also a brilliant justification
| for procrastination.

Well, curiosity brought me back to coding. It drives me to read up on
networking (the social as well as the computer way ), algorithms
(Understanding what Big O notation was quite the 'Eureka!' moment for
me), or GUI toolkits.

Though, I am a practical learner, so for best effects I need to tinker
with something for best effect.

That allows me to build a tolerance towards frustration, too.

| I couldn't agree more. When I meet a new team I want them to be as
| deeply shallow as possible: not experts in what I'm doing, but clearly
| willing and able to become experts as the project progresses without any
| pressure from me. Hopefully they'll even end up know more than I do,
| then I can steal knowledge from them

Indeed. I try to learn something new with everything I do, and I'm not
shy of sharing that knowledge (for example, a short series on RubyCAS
and Ruby-OpenID on my blog).

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com

~ - You know you've been hacking too long when...
...you think "grep keys /dev/pockets" or "grep homework /dev/backpack"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgzG1YACgkQbtAgaoJTgL8FvACgphH908d6BSbOJmlU4QgBJh71
BbkAn26GDkPrvHsUsOt6y61CgQlzXtsu
=mkBm
-----END PGP SIGNATURE-----

 

[Eleanor McHugh]

Awesome


I learned some powerful lessons on one of those 10 years ago...
unfortunately, too late for the project.

That's always the way


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Albert Schlef]

[...]
I started out in physics and I've spent a fair amount of my
professional career arguing with very capable CS experts over all
kinds of problems which are elementary with my background but have
them scuttling back to graph theory

Could you elaborte here? It sounds interesting.

http://[...]age-racecar-driver

It's a fascinating article [...]

Indeed. Usually I tuck away interesting articles in an "interesting, to
read someday" folder, but this time I couldn't stop reading...

 

[Eleanor McHugh]

[...]
I started out in physics and I've spent a fair amount of my
professional career arguing with very capable CS experts over all
kinds of problems which are elementary with my background but have
them scuttling back to graph theory

Could you elaborte here? It sounds interesting.

Not easily without getting sued for breaching various NDAs

Generally though there's a deep-seated belief in CS that because
computers deal in defined states formal abstractions such as graph
theory are the best way to tackle a number of often-intractable
optimisation problems. For simple systems that's true, but as your
state-space explodes you end up with solutions which are easily
expressed elegantly in Lisp or whatever but which in practice are
completely useless due to their processing requirements.

Anyone who comes from a science or engineering background will
recognise this as a granularity issue: a state-space has a level of
granularity beneath which additional precision in differentiating data
points becomes completely irrelevant in determining real-world
behaviour. The classic example is the disconnect between classical and
quantum mechanics, but it occurs in all experimental fields.

Unfortunately many very good CS people still have a mathematician's
bias towards a perfect answer rather than a working approximation and
look to maths for their abstractions rather than seeking them in the
real world and instead getting the granularity of their systems right.
In my personal experience this then leads to long and involved
discussions which go round and round in circles for months on end
until projects get cancelled because the perfect answer is too costly
to deploy, and the working approximation isn't provable for all cases.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Todd Benson]

[...]
I started out in physics and I've spent a fair amount of my
professional career arguing with very capable CS experts over all
kinds of problems which are elementary with my background but have
them scuttling back to graph theory

Could you elaborte here? It sounds interesting.

Not easily without getting sued for breaching various NDAs

Generally though there's a deep-seated belief in CS that because computers
deal in defined states formal abstractions such as graph theory are the best
way to tackle a number of often-intractable optimisation problems. For
simple systems that's true, but as your state-space explodes you end up with
solutions which are easily expressed elegantly in Lisp or whatever but which
in practice are completely useless due to their processing requirements.

Anyone who comes from a science or engineering background will recognise
this as a granularity issue: a state-space has a level of granularity
beneath which additional precision in differentiating data points becomes
completely irrelevant in determining real-world behaviour. The classic
example is the disconnect between classical and quantum mechanics, but it
occurs in all experimental fields.

Unfortunately many very good CS people still have a mathematician's bias
towards a perfect answer rather than a working approximation and look to
maths for their abstractions rather than seeking them in the real world and
instead getting the granularity of their systems right. In my personal
experience this then leads to long and involved discussions which go round
and round in circles for months on end until projects get cancelled because
the perfect answer is too costly to deploy, and the working approximation
isn't provable for all cases.


Ellie

Albert, a good example of what Ellie is saying would be -- in the ME
world -- like approximating a complex vibration with small
oscillations of a spring (doesn't have to be a spring; i.e., it could
be a very large 3-d pendulum with small movements). Once you do that,
the real-world problem becomes incredibly easier than factoring in
many parameters not required. In effect, you solve the problem
ideologically before you brute-force attack it with a turing machine.
Granularity.

Todd

 

[Phillip Gawlowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Todd Benson wrote:

| Albert, a good example of what Ellie is saying would be -- in the ME
| world -- like approximating a complex vibration with small
| oscillations of a spring (doesn't have to be a spring; i.e., it could
| be a very large 3-d pendulum with small movements). Once you do that,
| the real-world problem becomes incredibly easier than factoring in
| many parameters not required. In effect, you solve the problem
| ideologically before you brute-force attack it with a turing machine.
| Granularity.

'If you all you have is a scalpel, every problem looks like neurosurgery'?

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com

"Need" now means wanting someone else's money.
"Greed" means wanting to keep your own.
"Compassion" is when a politician arranges the transfer.
- - Joseph Sobran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkg0cGIACgkQbtAgaoJTgL+GnQCfbsqqT/d+dDTIr5RUCpVyulLG
7DsAnj4j6FBbmHO+5Edq+rZpCNxsJdv6
=wXMW
-----END PGP SIGNATURE-----