5 ms·

Part I In all my career in computing and related work, I've participated in interviewing for hiring and evaluating the candidates, and I hope to be hiring next

Part I In all my career in computing and related work, I've participated in interviewing for hiring and evaluating the candidates, and I hope to be hiring next year. So, would I take that 'matrix' seriously in hiring? Not really! Looking back, some of my thoughts on hiring were wrong! I suspect that using that matrix would also prove to be not very good! Some of the stuff in the matrix is okay to know but, really, next to trivial to learn: E.g., early in my career I skimmed through all three of Knuth's three volumes of 'The Art of Computer Programming' and studied fairly carefully his volume 'Sorting and Searching' and there sorting and trees. I programmed a lot of that material -- heap sort, quick sort, Shell sort, merge sort, binary search, minimum spanning trees, etc. -- for my career. Eventually I got a lecture from S. Kosaraju, and he covered all those high spots in a one hour lecture. I already knew the material, but it was nice to see that it could all be covered in an hour. So, really, for the 'computer science' material, mostly all that a person might be missing is one or a few lectures of an hour each. Not a biggie. Curiously the matrix mentions dynamic programming. Okay. It's a nice idea, with various versions and applications. E.g., it is the core of one of the more important network shortest path algorithms. One of the nicest parts of dynamic programming is that it is the core of 'stochastic optimal control', that is, best decision making over time under uncertainty, and, thus, one of the most general approaches to 'real time control'. To make this 'approach' solid mathematically, really need to address the subject as Markov decision processes since the Markov assumption is really what makes the crucial 'decomposition' into 'stages' justified. So, for much more on the Markov connection, there is E. B. Dynkin and A. A. Yushkevich, 'Controlled Markov Processes', ISBN 0-387-90387-9, Springer-Verlag, Berlin. Once I had a practical problem that could use these ideas, got a 90 second lecture on the subject from George L. Nemhauser as in 'Dynamic Programming', ISBN 0-471-63150-7, John Wiley and Sons, New York. had to run to catch a plane, and by the time the plane landed basically saw how that worked. It's nice. After an advanced course, I worked harder on the math (e.g., the tricky subject of 'measurable selection'), the 'computational complexity' (commonly a problem), and some applications and wrote my Ph.D. dissertation in the field. So, George 'directed' my Ph.D. dissertation in 90 seconds before I started grad school! Thanks George. Actually he liked what I wrote and chided me for not publishing it. I didn't want to publish it; I wanted to sell it! Dynamic programming is a nice subject, but in hiring I wouldn't vote anyone down for not knowing it. I would vote someone down for thinking that dynamic programming is a biggie. If you don't know the basic idea of dynamic programming, then study the topic for an hour or so and you will get the idea. If want to get deeper into the subject, work through, say, Stuart E. Dreyfus and Averill M. Law, 'The Art and Theory of Dynamic Programming', ISBN 0-12-221860-4, Academic Press. and notice the 'deterministic equivalence' for the case of 'linear plant' (the system being 'controlled'), quadratic objective function (say, reduce cost or risk), and Gaussian exogenous effects (the 'stochastic' part trying to 'control' against) -- called the LQG case. So, there 'deterministic equivalence' can save "a pant load" of computer time. For more look at the papers of R. Rockafellar at U. Washington. So, just above I totally 'blow away' the mention of 'dynamic programming' in the matrix. But, again, the subject is just not very important for hiring. Somewhere in that matrix is mention of 'system monitoring'. Yes, there is some importance here. Once I worked in a high end project applying 'artificial intelligence' to 'system monitoring', did some 'architectural' work, wrote some tricky code that helped the project a lot (won an award), and then took a very different direction, did some original research, and published a paper in a peer-reviewed journal. At one point the work needed a multi-dimensional 'nearest neighbors' search algorithm, so I did something like binary search on each of the several dimensions. Later I discovered that I had reinvented k-D trees -- k-dimensional binary search trees. So, there is a tree, and do a depth first traversal. But then have to do a 'depth-first backtrack traversal' of a containing 'subtree' with some 'cutting planes' to be sure have found the actual 'nearest neighbor' or, if desired, the 'k nearest neighbors' for some positive integer k (not the same k as in k-D!). In the end the work became, from all I can tell, the first, and quite general, approach to multi-dimensional, distribution-free statistical hypothesis testing (which 'system monitoring' has to be close to). Okay. So, here 'blow away' the matrix on 'system monitoring'. But I wouldn't hire based on such work. The matrix is big on 'integrated development environments' (IDEs), but so far I've seen no good reason in MY work to use them and some big reasons not to: I do my programming depending heavily on (1) the hierarchical file system to support an implicit 'taxonomic hierarchy' of 'nested' work, now, finally, being appreciated by Microsoft in how 'XCOPY deployment' and IIS use subdirectories (and they can do still more with good use of file system 'access control lists'), (2) a scripting language for command line scripts (easy enough to type at a command line and then really easy to drive from more scripts!), and (3) the one, same programmable text editor I use for as much as possible of everything I type and read. So, with the file system, scripts, and an editor, I get to do essentially all my programming using just a few good tools I know well and can use for much more, e.g., writing papers in TeX, doing projects, keeping notes, writing e-mail and this post, etc. So here are a few tools easy to use that, for MY work, work great. Have about as much chance of getting me to give up my favorite programmable text editor as getting a violinist to give up a Strad; moreover, the violinist does essentially all his music with his Strad, and I do essentially all my typing with my text editor. Sorry 'bout that IDE developers!

HilbertSpace 16y ago
Part II In more detail, I had to pick an operating system I would use as the main one for my work -- I picked Windows. Then I had to pick a compiled language -- I picked Visual Basic .NET (VB). Then to develop VB code I discovered that actually the VB compiler is in file VBC.EXE. Then if install .NET Framework 2.0, 3.0, 3.5, 4.0, etc., in each of them is just one file, VBC.EXE, and it IS the VB compiler. To run it, just RUN it by having a simple script give the full tree name on a 'command line'. The options needed are minimal. The compiler seems to be fast and to generate small EXE files. I find the error messages to be good. So far I've found no bugs at all. It's easy to suppress many sources of problems with just the source code statements Option Strict On Option Explicit On Works fine. For MY work, I don't see that an IDE could be much better. For interactive debugging? So far I've not needed it and have not looked at what is available. Why VB? Because it has very little 'idiosyncratic syntax' and more generally is easy to read on the page, and it offers essentially full access to .NET and its ASP.NET for Web site development and ADO.NET for relational data base access. Its 'object model' based heavily on 'interfaces' is SIMPLE but powerful enough. Its 'managed memory' can be a big help. The complier is fast. The complied code is plenty efficient. Good enough. Decision done. For an IDE, I've seen several of them. Each is a complicated new tool to learn with a lot of time and effort for the learning. Generally the documentation just SUCKS: E.g., I never could find any clear statement of what Microsoft meant by a 'dockable' window or why I should care, and I very much did NOT want to figure it out. Then there is the issue of how to write macros for the IDE and/or how to script the work, and I've so far never seen how to do that or any reasonably clear documentation for how. Then there's the issue of what the heck is the IDE doing for (to!) me -- I don't know, and won't know. And when what it does for me no longer works, guess who gets to diagnose and fix the problem? So I would be depending on something complicated I don't understand and, then, have to fix it, when I don't understand it. Then in the first few trials I saw that just for a program "Hello World" the IDE created a big subdirectory tree with maybe 50 MB of who knows what the heck; when things didn't work, I'd have to work with all that glop, gorp, and goop -- NO THANKS. Uh, long ago I discovered that the key to 'ease of use' is not some tool doing a lot for (to) me but just a tool that is reliable, well documented, easy to 'script', and easy to understand. Thus, I don't want an IDE! Uh, in my kitchen, I REALLY like my 10" classic French chef's knife and various cutting boards, and I want no Rube Goldberg contraption just for cutting onions, another just for slicing carrots, another just for shredding cabbage. Similarly for software tools. The matrix omitted some of what I do consider crucial in programming: First, in the work, what is most important is the significant 'meaning'. There is, so far on this planet, exactly one way to record and communicate meaning -- a natural language, and of these, now, the most important is also my native language, English. So, I want the important 'meaning' to be recorded and communicated in English. Math? Actually, when done well, e.g., by P. Halmos, it is written in complete sentences. Same for mathematical physics. The symbols? They don't mean anything until carefully described in the natural language and, then, remain essentially as just abbreviations for the natural language definitions, descriptions, explanations, and examples. To be more clear, the symbols and the source code, without the English, mean NOTHING, mean zip, zilch, zero. Don't fool yourself into thinking otherwise. I don't say this because I like English literature (I HATE it) or hate math (my field is really applied math, and I do like it); I say this because it is what I have concluded is true. Knuth's old idea of 'literate programming' may be close. So, some of the best examples of how to communicate 'meaning', ESPECIALLY about technical material, in English are in good college texts in, say, math or mathematical physics. That's where we have to start on 'meaning'. Second the work of software is to create 'systems' that have useful 'meaning'. So, this meaning needs to be recorded and communicated, for both developers and users, in English. There is NO substitute: Here are software techniques that are sometimes helpful -- long, mnemonic symbol names; pretty printing of source code; software 'objects'; IDE GUI 'panels'; software 'functions' and/or 'functional programming'; 'declarative' programming; desktop GUI UI 'icons' and 'windows' -- but none of these has meaning or is a substitute for English for recording and communicating meaning. Sorry 'bout that. In particular, to me source code should read much like a good college text in math or mathematical physics. So, the English is in the source code 'comments'. On first reading the source code file, read just the comments. The code itself has no meaning. Even 'object oriented' code with long, mnemonic symbol names has no meaning. The meaning depends heavily on the English in the comments. In well written software, between the code and the comments, far and away the comments are the more important. Commonly well written technical material has references that provide support for smaller details. Good. So source code should have such references, and mine does: My code is awash in file system tree names of files of documentation, mine or otherwise usually an HTM file of a Web page. For my source code in my favorite programmable editor, one keystroke displays a reference. All the crucial issues, e.g., checking the inputs, the 'edge cases', issues of 'memory leaks' and threads, should be discussed in English in the comments with explanations of how the issues have been handled. Yes, more important than code with English comments can be 'external' documentation all in English with no code at all! Then, of course, in appropriate places the code comments will reference the external documentation. Net, by far the most important typing in software is the English documentation, NOT the 'code'. For 'source code control systems', I can believe that in some projects, although maybe ones a bit too large to be effective, such tools could be useful. However I've been on significant software projects with eight or so people, and we did well with no such tools at all. For my work now, everything particular to some one 'version' of the software is in a file system directory subtree. Then for a new version of that software, I start by just making a copy of that subtree; then I document, right, in English, the purpose of the copy and go to work on the copy. Works well. Next, to me the most important lesson in work that needs software is to be clear on what the work is and what contribution the software is to make to the work. Next, for the software, the most important need is to describe what, in terms of the real work, the software is to do. Next, within the software, the most important step is to use 'divide and conquer': At one point in Rome in the Middle Ages, there was a big project to move a large, stone monolith some dozens of feet in a plaza. Big project. Complicated. Expensive. Famous. But, before getting too impressed, how the heck did that rock get there in the first place? Over 1000 years earlier, Caligula's slaves cut the rock as one piece somewhere in the headwaters of the Nile, floated it down the Nile, across the Mediterranean, and to Rome and put it in place. How'd they do that? They used 'divide and conquer', that is, broke the whole project into pieces, broken into pieces, etc., until each of the pieces was doable. What else? Summon spirits from the vastly deep? Same for software: Break the work into doable pieces. Hopefully each piece is easy to understand, document, code, test, and modify and likely changes in what the software is to do need affect only a few pieces. That's it. Next, for getting people productive in programming, my experience is that someone, maybe the project leader, needs to have cut through the millions of acres of swamp of glop, gorp, and goop and gotten the work and the tools all simple, clear, and easy to understand. Then can take a bright, well motivated person with no background in programming at all and in a few hours of instruction get them quite productive. The person needs to know how to read with understanding, learn, analyze, and create meaning by writing English. So, in interviewing, I want such a person. 'Dynamic programming' and Knuth's 'Sorting and Searching' or 'functional programming'? I don't care. How 'bout that!

HilbertSpace 16y ago

Part II In more detail, I had to pick an operating system I would use as the main one for my work -- I picked Windows. Then I had to pick a compiled language -- I picked Visual Basic .NET (VB). Then to develop VB code I discovered that actually the VB compiler is in file VBC.EXE. Then if install .NET Framework 2.0, 3.0, 3.5, 4.0, etc., in each of them is just one file, VBC.EXE, and it IS the VB compiler. To run it, just RUN it by having a simple script give the full tree name on a 'command line'. The options needed are minimal. The compiler seems to be fast and to generate small EXE files. I find the error messages to be good. So far I've found no bugs at all. It's easy to suppress many sources of problems with just the source code statements Option Strict On Option Explicit On Works fine. For MY work, I don't see that an IDE could be much better. For interactive debugging? So far I've not needed it and have not looked at what is available. Why VB? Because it has very little 'idiosyncratic syntax' and more generally is easy to read on the page, and it offers essentially full access to .NET and its ASP.NET for Web site development and ADO.NET for relational data base access. Its 'object model' based heavily on 'interfaces' is SIMPLE but powerful enough. Its 'managed memory' can be a big help. The complier is fast. The complied code is plenty efficient. Good enough. Decision done. For an IDE, I've seen several of them. Each is a complicated new tool to learn with a lot of time and effort for the learning. Generally the documentation just SUCKS: E.g., I never could find any clear statement of what Microsoft meant by a 'dockable' window or why I should care, and I very much did NOT want to figure it out. Then there is the issue of how to write macros for the IDE and/or how to script the work, and I've so far never seen how to do that or any reasonably clear documentation for how. Then there's the issue of what the heck is the IDE doing for (to!) me -- I don't know, and won't know. And when what it does for me no longer works, guess who gets to diagnose and fix the problem? So I would be depending on something complicated I don't understand and, then, have to fix it, when I don't understand it. Then in the first few trials I saw that just for a program "Hello World" the IDE created a big subdirectory tree with maybe 50 MB of who knows what the heck; when things didn't work, I'd have to work with all that glop, gorp, and goop -- NO THANKS. Uh, long ago I discovered that the key to 'ease of use' is not some tool doing a lot for (to) me but just a tool that is reliable, well documented, easy to 'script', and easy to understand. Thus, I don't want an IDE! Uh, in my kitchen, I REALLY like my 10" classic French chef's knife and various cutting boards, and I want no Rube Goldberg contraption just for cutting onions, another just for slicing carrots, another just for shredding cabbage. Similarly for software tools. The matrix omitted some of what I do consider crucial in programming: First, in the work, what is most important is the significant 'meaning'. There is, so far on this planet, exactly one way to record and communicate meaning -- a natural language, and of these, now, the most important is also my native language, English. So, I want the important 'meaning' to be recorded and communicated in English. Math? Actually, when done well, e.g., by P. Halmos, it is written in complete sentences. Same for mathematical physics. The symbols? They don't mean anything until carefully described in the natural language and, then, remain essentially as just abbreviations for the natural language definitions, descriptions, explanations, and examples. To be more clear, the symbols and the source code, without the English, mean NOTHING, mean zip, zilch, zero. Don't fool yourself into thinking otherwise. I don't say this because I like English literature (I HATE it) or hate math (my field is really applied math, and I do like it); I say this because it is what I have concluded is true. Knuth's old idea of 'literate programming' may be close. So, some of the best examples of how to communicate 'meaning', ESPECIALLY about technical material, in English are in good college texts in, say, math or mathematical physics. That's where we have to start on 'meaning'. Second the work of software is to create 'systems' that have useful 'meaning'. So, this meaning needs to be recorded and communicated, for both developers and users, in English. There is NO substitute: Here are software techniques that are sometimes helpful -- long, mnemonic symbol names; pretty printing of source code; software 'objects'; IDE GUI 'panels'; software 'functions' and/or 'functional programming'; 'declarative' programming; desktop GUI UI 'icons' and 'windows' -- but none of these has meaning or is a substitute for English for recording and communicating meaning. Sorry 'bout that. In particular, to me source code should read much like a good college text in math or mathematical physics. So, the English is in the source code 'comments'. On first reading the source code file, read just the comments. The code itself has no meaning. Even 'object oriented' code with long, mnemonic symbol names has no meaning. The meaning depends heavily on the English in the comments. In well written software, between the code and the comments, far and away the comments are the more important. Commonly well written technical material has references that provide support for smaller details. Good. So source code should have such references, and mine does: My code is awash in file system tree names of files of documentation, mine or otherwise usually an HTM file of a Web page. For my source code in my favorite programmable editor, one keystroke displays a reference. All the crucial issues, e.g., checking the inputs, the 'edge cases', issues of 'memory leaks' and threads, should be discussed in English in the comments with explanations of how the issues have been handled. Yes, more important than code with English comments can be 'external' documentation all in English with no code at all! Then, of course, in appropriate places the code comments will reference the external documentation. Net, by far the most important typing in software is the English documentation, NOT the 'code'. For 'source code control systems', I can believe that in some projects, although maybe ones a bit too large to be effective, such tools could be useful. However I've been on significant software projects with eight or so people, and we did well with no such tools at all. For my work now, everything particular to some one 'version' of the software is in a file system directory subtree. Then for a new version of that software, I start by just making a copy of that subtree; then I document, right, in English, the purpose of the copy and go to work on the copy. Works well. Next, to me the most important lesson in work that needs software is to be clear on what the work is and what contribution the software is to make to the work. Next, for the software, the most important need is to describe what, in terms of the real work, the software is to do. Next, within the software, the most important step is to use 'divide and conquer': At one point in Rome in the Middle Ages, there was a big project to move a large, stone monolith some dozens of feet in a plaza. Big project. Complicated. Expensive. Famous. But, before getting too impressed, how the heck did that rock get there in the first place? Over 1000 years earlier, Caligula's slaves cut the rock as one piece somewhere in the headwaters of the Nile, floated it down the Nile, across the Mediterranean, and to Rome and put it in place. How'd they do that? They used 'divide and conquer', that is, broke the whole project into pieces, broken into pieces, etc., until each of the pieces was doable. What else? Summon spirits from the vastly deep? Same for software: Break the work into doable pieces. Hopefully each piece is easy to understand, document, code, test, and modify and likely changes in what the software is to do need affect only a few pieces. That's it. Next, for getting people productive in programming, my experience is that someone, maybe the project leader, needs to have cut through the millions of acres of swamp of glop, gorp, and goop and gotten the work and the tools all simple, clear, and easy to understand. Then can take a bright, well motivated person with no background in programming at all and in a few hours of instruction get them quite productive. The person needs to know how to read with understanding, learn, analyze, and create meaning by writing English. So, in interviewing, I want such a person. 'Dynamic programming' and Knuth's 'Sorting and Searching' or 'functional programming'? I don't care. How 'bout that!