5 ms·

I appreciate that you posted this alternative opinion, but I found myself disagreeing with much of what you wrote. Why Visual Basic .NET? It seems like the nic

I appreciate that you posted this alternative opinion, but I found myself disagreeing with much of what you wrote. 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. I also work with the Microsoft stack, and I was surprised that you prefer VB over C#. I've used VB (briefly), and the syntax felt quite cumbersome compared to C# (which I use daily). What do you find "idiosyncratic" or "tricky" about C#? 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! Before I switched to .NET and C#, I used Django and Python, so I have some experience with the more barebones development environment you seem to like. There are things about Visual Studio that bother me, but I have to say that it's really pretty good overall. I think IntelliSense and ReSharper save me far more time than macros could. Also, interactive debugging feels significantly nicer than printing values to the console or messing with lower-level debuggers like gdb/pdb. What text editor and scripts do you use that you find to be better than Visual Studio? 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! How do you organize your code if you don't use MVC? It's a pretty well-regarded pattern; you may want to look at ASP.NET MVC or a similar framework. In both cases, the work went well with no attention at all to formal methodology, 'team tools', 'repositories', etc. ...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. You don't use version control, bug tracking, feature planning, nightly builds, continuous integration...any of those? I would think a project without those essentials would be quite disorganized. 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 [lots of computer science knowledge]. These requirements sound extremely high. Wouldn't someone with a recent B.S. in computer science or software engineering be significantly more prepared for the job (as well as less expensive to employ)? I begin to conclude that software is still a relatively simple subject.... I don't think this is the case at all. You can assemble a team of good developers, follow industry best practices, be blessed with a good product manager...and you still have to deal with bugs, tangled code, issues with libraries, changing requirements, architectural design problems, UX design failures, and so on. 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? Er, that doesn't sound all that good considering the level of demand there is for software developers. You need to at least match the average salary and benefits for the region and the skill level of the position. And you'll have to pay much more if you're serious about requiring Ph.Ds. 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. I don't think this is what is meant by "training". Learning new tools or libraries on the job is expected of most developers. Providing training means sending developers to conferences, buying them books on topics related to their work, allowing them to work with more experienced mentors, etc. Those things are really not that expensive considering the benefit you receive in improving your developers' skills. 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. This seems like a very bad approach to use if you value improving your skills, gaining domain knowledge, or keeping up with industry trends. JavaScript in particular has been an area of incredible innovation in the past decade or so. Is it really worth avoiding just because it has some quirks? So, net, one of the better abilities I want is the ability to write good technical material. I somewhat agree. Developers should be able to clearly document their code through a combination of good formatting, useful comments, thoughtful naming of types and variables, and blocks of technical documentation (docstrings/XML documentation) where appropriate. But they shouldn't be doing the jobs of technical writers. 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. This sounds good in theory, but I don't think it really works in practice. For most projects you need people to have certain skills or experience before they join the team...otherwise you'll spend most of your time reinventing wheels or teaching them the basics. For your web app startup, would you really hire someone who is intelligent and has credentials but has only a vague idea of how a web app works? Can you really expect them to just pick everything up as they go and still be a major contributor to the project?

graycat 14y ago
I mentioned my use of a favorite editor and command line scripts; so, I should add some detail on those two: My favorite editor is KEdit (Mansfield Software), a PC version of the IBM VM/CMS editor XEDIT. The macro language of XEDIT is Cowlishaw's Rexx, and KEdit uses their similar Kexx. My scripting language is ObjectRexx, an extension of Cowlishaw's Rexx. Rexx is elegant. Nearly all my typing for everything goes into KEdit -- one means of input to rule them all. My spell checker is Aspell from some TeX distributions; it's a darned well written program, can support several languages, and lets me maintain just one addendum dictionary! VB: I programmed in C for a while and got used to it. If I used C# daily, then I'd likely get used to it. As I recall, K&R confessed that the C syntax is idiosyncratic, which I agree with. E.g., can write i = j++ + ++k Too tricky for me. When I read Lippman on C++, it seemed trickier. What I've seen of C#, say, from reading Microsoft's Web pages at their MSDN, it looks like it's borrowed such 'sparse' syntax from C++. So far it appears that Visual Basic .NET (VB) and C# differ essentially in the flavors of 'syntactic sugar' and could be translated one to the other, almost statement by statement. So, I prefer VB mostly due to a flavor of syntactic sugar. What I like in the VB syntax is essentially the "cumbersome" part -- somewhat redundant, easy to read, puzzle problem free. I type the code in quickly and let the VB compiler tell me when I've omitted little things. But there's enough redundancy in the syntax so that the VB messages usually still recognize what I intended. Good -- I don't want some tiny typing errors to convert what I want into a still legal statement I don't want. VS: First, I don't like the one window with lots of small panes. Second, when I look at VS, I can't make any sense out of it. E.g., I have no idea what the little icons or the various panes are for. Then, I've never seen any very good documentation. I could figure it out, but my objective is my business. The times I tried VS; it created a 'project' where Hello World started off as 50 MB of 'stuff' I didn't understand. Then I fear that if, really when, something goes wrong I will have to dig into that 50 MB, with no documentation. For more, I don't want to type into VS if only because I don't see any hope for the kinds of functionality I get with KEdit and macros that I highly value. Instead of VS, here's an outline of what I do: In the morning when I start programming on my Web 2.0 project, I run some little ObjectRexx scripts that open about 25 windows, mostly KEdit and Firefox, in a particular Z-order and arrange the UL corners of the windows equally spaced on a line on my screen from LL to UR while preserving the Z-order. I close the windows I won't be using that day and end up with 10-20 windows. When the windows get to be a mess, one click on an icon drives an ObjectRexx script to arrange the windows again preserving both the Z-order and the order of the left sides. Net, I get in effect much more screen area for my work than I get from the one VS window with its small panels. The windows are mostly for files and directories where I am working or with relevant documentation. In addition, one of the scripts starts in a console window the session state store I wrote (some TCP/IP and a collection class). I have 4000+ Web pages of documentation and a little system for abstracting the pages and finding the pages I need. In addition, for more relevant pages, I put in my source code page titles and corresponding tree names on my computer; then one keystroke in KEdit has Firefox display the Web page from which I can continue to traverse the MSDN tree back at MSDN. That's my substitute for Intellisense. KEdit is terrific as an easily automated chef's knife and cutting board for slicing and dicing files of text, working with collections of files, starting programs, dialing phone numbers, etc. I don't want to type into VS instead of KEdit. For debugging, the main challenge for me is finding the cause of the software going "poof" after running for some interval. So, with interactive debugging, there is too much stopping at break points and starting again. Instead, I just have my code write values of relevant variables to a file or, for the code for a Web page, the Web site log. After "poof" I look at the output, maybe 10 MB, go the bottom where the "poof" happened, and move backwards, using the KEdit 'select' tools to show me what I want. It's always worked so far! Sure, later I could have the writing go over TCP/IP to a program that keeps, say, the 10,000 most recent lines. > You don't use version control, bug tracking, feature planning, nightly builds, continuous integration...any of those? I would think a project without those essentials would be quite disorganized. Sure, some of those I do now. But I just don't yet have or need formal procedures and tools. One thing I do nightly is an incremental backup! Since I'm just one guy, some simple techniques are sufficient for being organized. And at Yorktown Heights, I found that for our team of seven, still we could use just simple techniques. > These requirements sound extremely high. Wouldn't someone with a recent B.S. in computer science or software engineering be significantly more prepared for the job (as well as less expensive to employ)? I just said "sufficient"; I didn't say necessary or "requirements"! One reason for my interests in this thread is that I don't yet know just how I will hire; I don't intend to hire all Ph.D.s. My company needs for the code to be a solid company 'asset'. So, the code has to be well written and not just some gibberish. For what I'm doing, I believe I could teach good people quickly. On my "I begin to conclude that software is still a relatively simple subject" So, have (n)log(n) in-place sorting, balanced binary trees, TCP/IP, if-then-else, do-while, call-return, etc. Simple. We are in agreement. Most of the sauces in Escoffier are fairly simple, but running a three star Michelin restaurant is not. Having a big chunk of production software in good shape and working and moving along nicely is not so easy and takes some good people. On salary we may not be communicating: What I hear about programmer salaries, e.g., people happy to get $100 K a year, sounds a bit short of the standard I mentioned. E.g., $100 K a year won't go very far where houses are $400 K, taxes are high, and want to support a wife and three kids. Early in my career, in one two week period I went on seven interviews and got five offers. Then I was getting paid about six times what a new Camaro cost. Today that would work out as $240-300 K per year. Right, houses at $400 K are too expensive for anyone to afford. Yet, people keep buying them. We largely agree on training. Some conferences are just for entertainment, but some are important for training. And could at times use some in-house lectures or short courses, given by people from inside or outside. > This seems like a very bad approach to use if you value improving your skills, gaining domain knowledge, or keeping up with industry trends. I'm not interested in JavaScript because I don't have anything important in mind I need to do with it beyond the JavaScript Microsoft writes for me. I believe that the goals of both the company and the employees are closer to the bottom line, that is, the real business needs, than what you mentioned. And I believe that there is relevant knowledge to be gained much more valuable than what you listed. To me "industry trends" are too much like a fashion show, not that I've ever been to one. We're not communicating well on the role of good technical writing. E.g., suppose someone in my server farm looks into system management platforms from, say, CA, EMC, HP, IBM, and Microsoft, goes to some conferences, tours some sites, gets some sales pitches, talks to some consultants, etc. Then I will want them to write up a report on what they learned and give a presentation to likely the whole server farm staff, myself, and maybe others. I could list another dozen such. For a significant new software development project, there should be at least a first cut design document. For technical writing, I believe that should be done by people who understand the material really well. For 'technical writers', they may help such a person with organization, grammar, punctuation, building an index, etc. Your remarks critical of "JIT skills" have some value. But I anticipate people bright enough and growth slow enough that what I outlined should work. If they want to know how the Web works, say, from the ISP connection into the LAN switch to the servers, etc., fine: I'll outline it quickly. Then I'll have the first person write up notes available to teach others, get some books, etc. Current computing can be super complicated, but my plans for my company are to keep nearly all the computing relatively simple. If the computing gets to be a big, complicated thing, then I've done something wrong in my business planning and server farm and software architecture.

graycat 14y ago

I mentioned my use of a favorite editor and command line scripts; so, I should add some detail on those two: My favorite editor is KEdit (Mansfield Software), a PC version of the IBM VM/CMS editor XEDIT. The macro language of XEDIT is Cowlishaw's Rexx, and KEdit uses their similar Kexx. My scripting language is ObjectRexx, an extension of Cowlishaw's Rexx. Rexx is elegant. Nearly all my typing for everything goes into KEdit -- one means of input to rule them all. My spell checker is Aspell from some TeX distributions; it's a darned well written program, can support several languages, and lets me maintain just one addendum dictionary! VB: I programmed in C for a while and got used to it. If I used C# daily, then I'd likely get used to it. As I recall, K&R confessed that the C syntax is idiosyncratic, which I agree with. E.g., can write i = j++ + ++k Too tricky for me. When I read Lippman on C++, it seemed trickier. What I've seen of C#, say, from reading Microsoft's Web pages at their MSDN, it looks like it's borrowed such 'sparse' syntax from C++. So far it appears that Visual Basic .NET (VB) and C# differ essentially in the flavors of 'syntactic sugar' and could be translated one to the other, almost statement by statement. So, I prefer VB mostly due to a flavor of syntactic sugar. What I like in the VB syntax is essentially the "cumbersome" part -- somewhat redundant, easy to read, puzzle problem free. I type the code in quickly and let the VB compiler tell me when I've omitted little things. But there's enough redundancy in the syntax so that the VB messages usually still recognize what I intended. Good -- I don't want some tiny typing errors to convert what I want into a still legal statement I don't want. VS: First, I don't like the one window with lots of small panes. Second, when I look at VS, I can't make any sense out of it. E.g., I have no idea what the little icons or the various panes are for. Then, I've never seen any very good documentation. I could figure it out, but my objective is my business. The times I tried VS; it created a 'project' where Hello World started off as 50 MB of 'stuff' I didn't understand. Then I fear that if, really when, something goes wrong I will have to dig into that 50 MB, with no documentation. For more, I don't want to type into VS if only because I don't see any hope for the kinds of functionality I get with KEdit and macros that I highly value. Instead of VS, here's an outline of what I do: In the morning when I start programming on my Web 2.0 project, I run some little ObjectRexx scripts that open about 25 windows, mostly KEdit and Firefox, in a particular Z-order and arrange the UL corners of the windows equally spaced on a line on my screen from LL to UR while preserving the Z-order. I close the windows I won't be using that day and end up with 10-20 windows. When the windows get to be a mess, one click on an icon drives an ObjectRexx script to arrange the windows again preserving both the Z-order and the order of the left sides. Net, I get in effect much more screen area for my work than I get from the one VS window with its small panels. The windows are mostly for files and directories where I am working or with relevant documentation. In addition, one of the scripts starts in a console window the session state store I wrote (some TCP/IP and a collection class). I have 4000+ Web pages of documentation and a little system for abstracting the pages and finding the pages I need. In addition, for more relevant pages, I put in my source code page titles and corresponding tree names on my computer; then one keystroke in KEdit has Firefox display the Web page from which I can continue to traverse the MSDN tree back at MSDN. That's my substitute for Intellisense. KEdit is terrific as an easily automated chef's knife and cutting board for slicing and dicing files of text, working with collections of files, starting programs, dialing phone numbers, etc. I don't want to type into VS instead of KEdit. For debugging, the main challenge for me is finding the cause of the software going "poof" after running for some interval. So, with interactive debugging, there is too much stopping at break points and starting again. Instead, I just have my code write values of relevant variables to a file or, for the code for a Web page, the Web site log. After "poof" I look at the output, maybe 10 MB, go the bottom where the "poof" happened, and move backwards, using the KEdit 'select' tools to show me what I want. It's always worked so far! Sure, later I could have the writing go over TCP/IP to a program that keeps, say, the 10,000 most recent lines. > You don't use version control, bug tracking, feature planning, nightly builds, continuous integration...any of those? I would think a project without those essentials would be quite disorganized. Sure, some of those I do now. But I just don't yet have or need formal procedures and tools. One thing I do nightly is an incremental backup! Since I'm just one guy, some simple techniques are sufficient for being organized. And at Yorktown Heights, I found that for our team of seven, still we could use just simple techniques. > These requirements sound extremely high. Wouldn't someone with a recent B.S. in computer science or software engineering be significantly more prepared for the job (as well as less expensive to employ)? I just said "sufficient"; I didn't say necessary or "requirements"! One reason for my interests in this thread is that I don't yet know just how I will hire; I don't intend to hire all Ph.D.s. My company needs for the code to be a solid company 'asset'. So, the code has to be well written and not just some gibberish. For what I'm doing, I believe I could teach good people quickly. On my "I begin to conclude that software is still a relatively simple subject" So, have (n)log(n) in-place sorting, balanced binary trees, TCP/IP, if-then-else, do-while, call-return, etc. Simple. We are in agreement. Most of the sauces in Escoffier are fairly simple, but running a three star Michelin restaurant is not. Having a big chunk of production software in good shape and working and moving along nicely is not so easy and takes some good people. On salary we may not be communicating: What I hear about programmer salaries, e.g., people happy to get $100 K a year, sounds a bit short of the standard I mentioned. E.g., $100 K a year won't go very far where houses are $400 K, taxes are high, and want to support a wife and three kids. Early in my career, in one two week period I went on seven interviews and got five offers. Then I was getting paid about six times what a new Camaro cost. Today that would work out as $240-300 K per year. Right, houses at $400 K are too expensive for anyone to afford. Yet, people keep buying them. We largely agree on training. Some conferences are just for entertainment, but some are important for training. And could at times use some in-house lectures or short courses, given by people from inside or outside. > This seems like a very bad approach to use if you value improving your skills, gaining domain knowledge, or keeping up with industry trends. I'm not interested in JavaScript because I don't have anything important in mind I need to do with it beyond the JavaScript Microsoft writes for me. I believe that the goals of both the company and the employees are closer to the bottom line, that is, the real business needs, than what you mentioned. And I believe that there is relevant knowledge to be gained much more valuable than what you listed. To me "industry trends" are too much like a fashion show, not that I've ever been to one. We're not communicating well on the role of good technical writing. E.g., suppose someone in my server farm looks into system management platforms from, say, CA, EMC, HP, IBM, and Microsoft, goes to some conferences, tours some sites, gets some sales pitches, talks to some consultants, etc. Then I will want them to write up a report on what they learned and give a presentation to likely the whole server farm staff, myself, and maybe others. I could list another dozen such. For a significant new software development project, there should be at least a first cut design document. For technical writing, I believe that should be done by people who understand the material really well. For 'technical writers', they may help such a person with organization, grammar, punctuation, building an index, etc. Your remarks critical of "JIT skills" have some value. But I anticipate people bright enough and growth slow enough that what I outlined should work. If they want to know how the Web works, say, from the ISP connection into the LAN switch to the servers, etc., fine: I'll outline it quickly. Then I'll have the first person write up notes available to teach others, get some books, etc. Current computing can be super complicated, but my plans for my company are to keep nearly all the computing relatively simple. If the computing gets to be a big, complicated thing, then I've done something wrong in my business planning and server farm and software architecture.