Interesting thread. The tread is interesting to me
because I'm a sole founder of a Web 2.0 startup with
some relatively technical internals (in the server
farm only), and have done all the work from the
beginning to the present. If the startup works,
then I will have to hire.
But, for what is in the OP and this thread, I have a
different view.
Below I discuss the differences in three parts,
software development environment, teams, and
qualifications and add some comments at the end.
Software Development Environment.
I've been around computing for a long time, but I
skipped over the big growth in Unix/Linux and C++.
Instead my more serious software development has
been on IBM mainframes and now on Windows with
Visual Basic .NET, ASP.NET, ADO.NET, SQL Server,
etc.
Why Visual Basic .NET? It seems like the nicest way
to exploit Windows, the Microsoft Common Language
Runtime (CLR), and the .NET Framework (that is, the
enormous collection of classes), and work with the
rest of the Microsoft software for TCP/IP, SQL
Server, IIS, etc. The syntax of C# is too close to
that of C/C++ and, thus, is deliberately
'idiosyncratic' and 'tricky' and, thus, an obstacle
and error prone; the Visual Basic .NET syntax is
much easier to take. The idea of 'immutable'
strings, each with maximum length 2 GB or some such,
along with the ideas in 'managed code' and memory
management seem terrific for my applications level
programming.
I've always typed code into just a text editor, one
that permits writing good macros, the most capable I
had access to, done operations with just command
line scripts, never used an 'integrated development
environment' (IDE), and rarely used any interactive
debugging. Instead, I just put some checks into the
code, have the code write a lot of tracing data, and
then look at it with a text editor. Always worked
so far!
For my Visual Basic .NET code for my site's Web
pages, I'm just typing into ASP.NET without any
explicit use of model–view–controller (MVC) or other
Web site 'framework', whatever such a 'framework'
is! Once I looked at MVC for a few minutes, and it
seemed that some of my code is similar!
I looked at Visual Studio, didn't like the
documentation or the many small 'panels' all in one
window (instead of the 10-20 windows I use), never
saw a description of what they meant by 'dockable',
and concluded that my favorite text editor and some
command line scripts were more productive.
I've been surprised and pleased by how well Visual
Basic .NET works for Web page development on
Microsoft's Internet Information Server (ISS) --
e.g., just have a Web browser ask for the page using
the loop-back IP address, and IIS kicks off the
Visual Basic compiler, apparently for anything and
everything on the site that needs compiling, does
any 'link editing' on the fly or some such, and at
the bottom of the Web page gives, based on options
in the Web page code, lots of details on the
compiling. Generally, if there are no error
messages, then the Web page displays. It's nice.
Microsoft should explain it someplace!
So, I begin to conclude that the main things a
programmer needs are good versions of a text editor,
scripting language, programming language, and
documentation on these and the libraries, APIs, etc.
Teams.
I've done some software development in teams and
supervised some software development. In both
cases, the work went well with no attention at all
to formal methodology, 'team tools', 'repositories',
etc. In one case, I was one of a team of three
researchers in artificial intelligence at IBM's
Watson lab at Yorktown Heights, and we did research,
published papers, designed and developed software,
and our work resulted in two, shipped, commercial
IBM Program Products, IBM's highest quality software
product category. For one of these two the code
that was shipped was essentially just what we wrote.
In the other case, we did all the work except the
actual code was typed in by an outside company in
Taiwan.
In addition to our three researchers, and we all
wrote code, we had several programmers. Really, it
was a team of seven people. For a project that
small, the lack of formality worked fine.
Once I was the Chair of a computing committee for an
academic institution and, thus, in part a supervisor
of a computing group that served the institution.
We had several programmers, former students, with no
formality at all, and the work was terrific.
I've never seen any formal approach to code
'building', testing, test 'buckets', 'quality
assurance', etc., yet we had no problems.
So, I begin to conclude that for groups as small as
seven, with a good leader and some good people, can
do well with no formality at all. None. Zip,
zilch, zero.
Programmer Qualifications.
The people I've worked with have nearly always been
plenty bright, knew a lot, learned quickly, worked
hard, etc. And these people were selected with none
of the interviewing ideas in this thread.
Mostly the people were college graduates, but not
all; some of the people had technical Ph.D. degrees;
some were graduate students in technical programs and
part time.
It appeared that generally quite sufficient (but
usually more than necessary) qualifications were a
Ph.D. in pure/applied math or
theoretical/experimental physics, some good computer
usage experience, and some scientific/engineering
programming in two or more languages would be fine.
Then such a person could pick up Knuth's TACP,
Ullman on database or compiling, Sedgewick on
algorithms, artificial intelligence, 'machine
learning', the elementary
Thomas H. Cormen, Charles E. Leiserson, Ronald L.
Rivest, and Clifford Stein, 'Introduction to
Algorithms, Second Edition', The MIT Press
Cambridge.
etc. and zip through like reading a novel. Gee,
Knuth's TACP has a nice list of binomial and
combinatorial formulas, good coverage of heap sort
and the Gleason bound, B-trees, AVL trees, and
random number generation, and more that is useful
..., well, maybe if I got out my copies I could find
some more! Yes, he has a very clever presentation
of the fast Fourier transform, but the more
specialized sources, especially for signal
processing, are better even if less clever.
Gee, guys, there are more tough technical ideas in
several cases of just 30 pages in W. Rudin's books
than in some stacks of computer science texts. For
real technical creativity, R. Bland's proof in
linear programming totally blows the doors off
anything I've seen in Bachelor's or Master's level
computer science or suspect is there or saw in
technical talks at Yorktown Heights.
Yes there are some other hiring criteria, but they
are mostly by 'exception'. E.g., if a person
clearly has a personality problem that keeps them
from working effectively alone or with others, then
can't have that person around.
I begin to conclude that software is still a
relatively simple subject, and for hiring the
sufficient conditions I gave are fine.
For more:
More.
If I hire someone with a lot of 'skills' in tools
and procedures for team developed software and those
skills seem to be worthwhile, then that person could
be helpful and welcome!
Compensation.
For salary, guys, look, the first thing to check is,
does the job pay well enough to let you buy a house
and support a family in nice conditions?
Large Software Projects.
Next, I confess: I've never tried to debug or
modify a 500 KLOC 'code base' developed over 10
years by 20 programmers none of who are still there
with no documentation except some sparse comments in
the code. My view is that such code is not a
programming problem but a management problem: To
fix the problem, need a lot of time, money, and
people. Sorry 'bout that!
Training.
I've never seen anything very useful in formal
training. Have to accept that major fractions of
programmer time go to working through bad
documentation, learning new material, migrating to
newer tools, writing little tools, etc. For a
'training budget', no: Just budget the time along
with everything else; for travel and fees for formal
training sessions, sure, but likely mostly the
training should be in-house without flying across
the country, business class, limo service, fancy
hotel, rental car, big per diem, big training fees,
etc.
Security.
In some organizations, have to take security very
seriously. Might have to hire some outside firms
with tools, procedures, tests, etc. Okay, then do
that.
JavaScript.
So far have yet to write a single line of
JavaScript. But so far Microsoft is writing about
300 KB of it for me, and I have to suspect that I
could cut that down by a lot and, thus, save on
bandwidth. So, if I have to write some JavaScript,
then I will. That is, get some materials and/or
'training', learn some JavaScript, and write some.
Do something really complicated with JavaScript? I
want to try never to do that!
And I would generalize that approach to JavaScript
to nearly everything else in computing, for me and
any people I hire.
Writing.
Once someone in my company has spent a lot of time
and, thus, company funds, learning or doing
something that has some importance, then I will want
them to document what they learned or did so that
the company can have the work as a continually
valuable 'asset'. So, net, one of the better
abilities I want is the ability to write good
technical material. Being able to give a good
technical talk would also help.
Net.
Many organizations want a lot of detailed 'skills'
that I get by without and, thus, won't require in
people I hire. I prefer JIT skills -- learn the
stuff as needed.