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

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.