;Istvan posted this on another page::Speaking of which, it dawns on me that you folks are probably an excellent source of advice (or at least opinions!) for someone who wants to become a junior programmer. There are quite a few excellent tools I could educate myself to use, either through a self-taught route, or through some formal courses. I've been thinking C++/Perl, but I'm right by a Sun Microsystems regional HQ, through which I could easily take (expensive) courses and get certified in Java. Any opinions on the relative value? I've also been looking at Python, which seems to have some intersting potential, though I don't believe employers are generally to that level of the bleeding edge, which inclines me to stick with Perl for a generally-useful interpreted scripting language. There's also PHP, for web delivery and I dunno what else, but I've not learned squat about it other than that it supposedly has C-like syntax, and that Gossip (Carlo Zottman - PlanetJumpgate) thinks it's gloriously wonderful. I'm figuring XML is worth the trip, the basic tutorials I've read are painless. A related problem for me is that my liberal arts degree and I will be competing for entry-level positions with CS majors fresh out of school. Besides facility with lanaguages and tools, what do development professionals think I should know in order to be viable? Rather than letting me hijack this page further, please feel free to shoot me email. Thanks for any opinions and advice offered!

JDH Of course all advice is inheretently worth less than what you paid for it - with that said here's my initial 2 cents worth:

First question - do you want to know the "most useful" things a developer should know? Or do you want to know how to get into a development job? The former is probably very contentious and highly dependent on who you ask - the latter might be easier to tackle. If I were you I think I'd decide what sort of area I wanted to get into (e.g. Microsoft desktop apps, server side programming, web development (that's not an oxymoron!), system administration, database admin etc.). I know you said "junior programmmer - but each of those disciplines includes coding in one form or another). You could make the decision based on where your interests lie or how many jobs are available. Next up I'd recommend that you go with a self study approach (you seem like a bright guy!) with the goal being to gain some form of industry accreditation. I don't know any of the names (except Microsoft Certified Engineer (MSCE)) - but I know there's accreditation by most of the major players. I think you're really going to need that sort of extra on your resume - because as you pointed out that liberal arts degree doesn't exactly scream "employ me". I also think that if you self study and lean on your friends (at SDx) for extra understanding you could probably gain accreditation for about $1000 (for MSCE I think you have to take 3 or 4 exams and I'm sure they're a couple of hundred a pop and I know you can buy bundles of books (with titles like "Everything you need to know for MSCE accreditation) for a couple of hundred) - maybe a bit more. If you go this route you'll want to research what accreditation is well recognized (for all their faults my understanding is that these certification schemes count quite highly).

Is this the sort of information you were after? (I'm sure we could also start quite a debate on the question of particular technologies)

DWM Whee-ha, this topic is sure to engender a flood -- at least from me! (I wrote this prior to seeing John's response...)

Allow me to ramble first for a bit...

Computer science has become a very diffuse discipline since it started. When I started at UConn in the eighties, it was exclusively an engineering discipline, and part of the electrical engineering department, although business majors were required to take an introductory course on programming. By the time I left, I believe that liberal arts CompSci degrees of some sort were available. Soon after graduating, a few months of night school could have you programming database front-end apps for a bank -- in fact, a close friend of mine, Cathy, ended up doing this wierd migration: horticulture degree -> bank teller -> loan officer -> financial database programmer. I think most of my non-technical friends ended up working in primarily computer-related fields. Wow.

If Cathy were still working (she's a full-time mom now), I'm sure she'd be designing web pages. :-)

One of my brothers went from general slacker to a degree in chemical engineering to teaching to online instructional material design. He now implements online courses for the Weather Service.

BTW, some of the best programmers (although perhaps not the best designers) that I've met have been people with a background in math or physics.

The range of stuff you can do within the software field is amazing, as is the range of tools and skills that can be brought to bear. With your background and history, as told in your bio, I'm sure you can pick up any tool you want to learn. It really depends on how much you want to tailor your skills to a marketplace, vs. what you think is fun to work on. As you probably already know, the more programming languages you learn, the easier it is to learn new ones -- however, mastery of any of the larger languages takes time. Also, if you cross the boundaries between languages built on fundamentally different paradigms, you will feel very challenged. An example is moving from imperative languages (the most common kind -- e.g. Pascal, C++, Perl, VB) to the functional languages (e.g. Oz, Haskel -- of these I've only spent signficant time with Oz). (I love learning new programming languages, in case it wasn't evident.) The imperative languages are by far the most widely used in industry, the others being more of academic interest.

Something like Perl, Python, or Ruby is a must-have, as a general tool for gluing together build processes and writing small utilities (sometime keepers, sometimes throwaways). Perl is by far most widely used, I think, and has the added advantage of being common and well-supported for CGI script writing. Python is also quite popular, as far as I can tell. Ruby is aesthetically much more pleasing than either of these, being fully object-oriented by design and having very nice syntax and semantics, but it is nowhere near as popular as the other two. (Rumor has it that Ruby rivals Perl in Japan, though.)

If you want to get into Web programming, I think it's hard to choose, and the others may have more useful suggestions. Personally, what little I've done with Web stuff has been raw HTML and Perl CGI. Those two, of course, are pretty fundamental and can't hurt. The others that you mention are, I think, all popular. Personally, I would not want my main focus to be on Web page development -- I think it would be boring.

Visual Basic is heavily used. (I hear groans from the peanut gallery.) It is looked down upon by 'real' programmers, but my understanding is that there is a lot of internal corporate development that uses it.

Java is of course wildly popular right now, but don't let anyone fool you into thinking that it's being used much as a general-purpose programming language. I wouldn't believe it. It's for Web apps (OK, here we go let the debates begin - /Java isn't just for Web apps), and most attempts I've heard of to apply it more widely have failed.

The general-purpose languages are the ones that will really open up a lot of doors, though, and increase your options. Most widely used are, of course, C and C++. I'm a C++ bigot. The language has a lot of warts -- some inherited from C, some due to unfortunately baroque syntax choices in newer features -- but its power is not rivalled by any other language I've studied. As compilers slowly catch up to the standard, the things you can do with the language get more amazing. To really be comfortable with the whole language is a challenge. To understand its C-rooted concepts well, you must understand at least the basics of how common computer hardware works - bits, bytes, addresses, and even sometimes CPU registers. To get into the object-oriented end of the language requires a shift to higher-order thinking about programs and what they do. And to understand really effectively utilize the template features requires yet another shift in thinking -- and at the moment, nobody knows where the limits are here, because there has been a steady trickle of papers and books that have amazed the entire C++ community by showing ever more sophisticated uses of templates to enable the writing of compact and high-performance code.

The other major general-purpose languages are still in use, of course, but far less widely -- Pascal, Eiffel, Modula-2 come to mind. I was offered a job working with Objective C three years ago, which really caught me off guard!

Languages are not all there is to computer science, of course. Other topics that are worthy of study:

• Relational database theory -- I discovered how ubiquitous databases are only late in my career, and am amazed at how few people really understand the fundamentally simple precepts of good database design.
• Project management basics -- Good project managers are very hard to come by. If you can learn this skill, then hone and prove it on a few projects, you'd be eminently employable, I think. I've done it, moderately well, but I don't enjoy it. OTOH, I think every developer should have some knowledge of the basics, to help manage their part of a project and to help their manager do his job.
• Hand Tools -- You will greatly enhance your productivity and esteem if you are at ease with all the little tools that are available and often necessary to the programming process. Source control, scripting tools as mentioned earlier, knowing at least one editor really well, build systems (like the traditional and widely used make), etc.

Anyway, I could drone on ... and on ... and on. But I'll end with one book suggestion: The Pragmatic Programmer. (Anyone have the ISBN handy? ISBN: 020161622X) An excellent book on the 'little things' that can make someone an effective and productive programmer.

Addendum after reading Johns' stuff:

I agree on the self-study approach. A lot of schools these days are cranking out people that are really apprentice craftsmen rather than engineers, because that's what industry wants (badly, and quickly). With your background, self-study will take you quite a ways, but you'll have to be patient.

What John suggests seems sound. I suspect that most certifications will open doors on things like system administration jobs, which will only require a little programming, mostly of the scripting kind. The more elaborate certifications, night school/associates degree would get you into simple programming jobs -- perhaps simple Web page work or db front-ends. A real undergraduate degree would get you pretty quickly to more interesting full-time programming jobs. If that's your ultimate goal, it might even be quicker to go the college degree route, albeit likely harder.

Lots of choices!

BTW, re XML: It's just a data exchange format, and buzzword du jour. Forget about it until a need arises for it.

Istvan - First question - do you want to know the "most useful" things a developer should know? Or do you want to know how to get into a development job? - JDH More like, what, besides how to code in a useful language, does someone generally need to know to be taken seriously as a junior developer? I figure I can pick up language syntax easily, and I have a text or two on design philosophies (but those are still a bit abstract for me to grok - need to work on some projects to see the value of what's being said in those books). I'm looking for things, which possibly you guys take for granted, that might be fundamentally necessary and fill day-to-day common-practice gaps. Here's a thought - what about familiarity with some of these comprehensive development environments? I'm accustomed to whacking out code in some simple text editor and either running it through a compiler (C++) or just being done, if I'm using Perl (interpreted). Environments have all sorts of features that I expect are quite valuable to someone - but at my meager level the interface is usually in the way. Dan made mention of source control s/w in his list of "Hand Tools" - I assume that working on a good-sized team project is the only way to get familiar with such a tool. Catch-22.

DWM Not true. Set up a home computer with either Linux or an NT-class MS OS (Win2k or XP, not those Win9x toys), then install CVS. Learn to use it for all your personal files. Personally, I'm not facile with CVS, but it's very widely used and a competent source control system. You'll learn the concepts, basic operations, and habits of source control, even though a lot of details will vary when you work at a job that uses a different one.

I'm scrutinizing a C++ "programming certificate" program through the U. of Colorado, trying to figure out if it will do the trick of making me credible (while also giving me excuses to write basic code). At the fastest rate, it will still likely take 2-3 semesters, beginning this summer, to get through the program. Self-teaching is how I got where I am in HTML and Perl (both reasonably competent), but I have no illusions that I could get a real job doing either - I have no documentation to convince a prospective employer that I am to be taken seriously, even assuming that my peculiar skillset really is a proper match for anything (it really isn't, yet).

DWM Yes, that's where the certification or degree is handy. One approach is to get the minimum certification/degree that will get you in the door, then rely on your own aggressive self-study to expand your skills and prove yourself on-the-job. Honestly, most people are too lazy to learn stuff on their own, preferring to be spoon-fed in lectures and such. If you're an eager autodidact and you're creative about applying what you learn to your job in a way that visibly makes a difference, you'll build a good reputation and resume in a few years.

JDH I agree with Dan - try and get in the door and then continue to improve. Two reasons for this (a) more economically viable & (b) more effective (some of this stuff is indeed better learnt through doing). I still recommend the certification approach - but I'd go for a certificate from a vendor - it might not actually be as technically good as what you'd get from a U. but it might actually convince an employer. I actually don't think a C++ "programming certificate" from a university would get you very far. But I think MSCE or MSCD would.

JDH I agree with Dan's laundry list of things to learn - but I suggest you stick to the main stream technologies (there ain't many jobs in Oz!) and I also suggest you target the "easier" languages first. Don't get put off by the bad press that Java and VB or Delphi get - you can still do a lot of good work with them and learn a lot about good coding techniques and software engineering practices. C++ is one of the most powerful languages out there but it also has a fairly steep learning curve. The one thing I'd like developers to realize is that there is no "one size fits all" programming language (maybe C++ comes closest but that comes at a cost of complexity) - so why not start out with a higher level language that comes with a rich set of functionality and is easier to learn? Later on you can move into C++ (and if you want to hurt your head Oz as well). If you want to take a little bit of a gamble and get ahead of the curve you might want to consider C# (I can hear my fellow SDxers groaning as I write this - but C# is better than VB.Net and with the power of big Bill behind it it will probably take off - but then again it might not). In terms of a general toolkit Perl is great - you're one up on me there - I'm still a Perl newbie. I find Perl's syntax unnecessarily and infuratingly obscure. I much prefer Ruby and that's the scripting language I turn to for my general purpose stuff. But Dan is right - stick with Perl - there's many more people using it. That's all for now.

DJH I third the sentiments above. Not terribly suprising, given the fact that the three of us have worked rather well on our product for over three years.

• Baptism by fire. It works. Use it or lose it. Also true. Meaning that you can study a lot of things, in this case development languages or environments, but unless you actually do something with it you won't reain more than a peripheral understanding of it.
• Sadly, perl is a standard. I much prefer Ruby. Perl is owned by a fellow whose background (Larry Wall, I think) is in spoken languages, and perl has the same problem as most languages: arbitrary or non-intuitive rules, plus unnecessarily arcane structures. Many people find pleasure in writing incomprehensible perl code. There are contests were people are challenged to do that, which is fine, but doing so as a daily practice is terribly inconsiderate to the other programmers they work with. In part, it's a matter of ego, impressing people with their knowledge and expertise (which can be considerable), but there's a cost.
• CVS and other tools can be used in isolation, though doing so requires discipline. In a production environment it is trivial to justify using tools that help manage or secure the development process, but when developing something that will never be seen outside your basement (or wherever), it's hard to justify that sort of thing. After all, the pupose for creating something when you're teaching yourself is to learn a specific task, and you want to do that in the most expedient manner with few distractions. However, at some point it is incredibly important to become one with source code control.
• If you can get a basic understanding of C++, you can learn any of the mainstream technologies. Not because it's harder, but because (as alluded to by Dan) it closely replicates what's really happening in the computer, and at the same time allows you to go beyond that to abstract concepts that are specifically designed to distance developers from the need to think about what the computer is doing. Ja, Ich bin auch ein C++ Frömmler. Ich bin auch someone who can't speak German worth a damn.