Brad Stiles wrote:

Does the way the web works not remind anyone else of CICS? Sure, it's not an exact match, but it's pretty darn close, in concept.

I thought of it the other way around (being one of those "damn kids" who used to think punch cards went away when they did away with, err, punch cards... who knew they were alive and well under the guise of "JCL") but yes... I have been noticing a lot of similarities between when I was writing web apps and the mainframe systems I've been doing integration work with. The scary thing is, I've found I quite like the way a lot of things are handled by CICS (especially since you don't have to worry about such web-related things as "images" and such)... pity the mainframe world has been pricing itself into oblivion. On-topic: "Web better, thick client BAD!" makes me wonder about the quality of system you're buying... while you can make some very good systems to administer something like your CMS on the web I'm not sure you'll get that from developers who take a sledgehammer to a differing opinion rather than provide a counterargument stating why they feel their web administration utilities will be better than a client utility. Make sure they do some good use-cases with whoever will have to administer the system...

Well, command-line guy is easy, just don't let him know about any of the UI tools for SVN and make *him* write the hook script to transform the actual code structure into his perverse collection of nested directories and back again. Tell him he's "allowed" to do that if he handles the branching and merging, if he still refuses after being told he can have most of his cake, find a window on the top floor that looks a little shaky. Build-breaker needs to start buying lunch, and someone suggested a script to build-on-commit, this is quite important as it can then broadcast an e-mail with the name, extension, cube location, and favorite tele-tubby of the offending submitter. If it is still a problem after a couple weeks, make sure they haven't fixed that window too well. I don't know what you are using for code editing but the VSS guy sounds like a Visual Studio user. You can try AnkhSVN (I don't like dev evnvironment integration all /that/ much but it is nice for renaming files, that's the one thing that's clunky with Tortoise in a Studio project) with him, if his complaint is that it doesn't lock files by default or something... make sure nobody's thought to put a safety net under that window. The "I'll take my ball" crowd should start being treated like off-site subs or outsourcers- they can do whatever they want and hand over working objects + source at their deadlines. If they lose something they get to have a fun night finding/rewriting it and it damn well better still work. (it sounds like you're in a kind of "build master" role where you take the code and create the deliverable output... you should check with your management to see how *they* would react if you started demanding things be corrected when someone breaks the build rather than fixing them yourself as it sounds is happening now. If management would rather you do the rest of the team's job for them, start looking... but if you can get your boss to agree that people are wasting time like crazy because they won't listen to a little common sense... that's a BIG lever to have when you sit everyone down and formalize the source control/build procedures. It is an even bigger club to have sitting nearby when you have to enforce them...)

One thing I've found from getting to dip my toes in the PM world (long enough to run and beg to just be a developer) was that the "management BS" type stuff seems to be easier in the morning (and I'm *not* a morning person). You have your list of stuff you need written up, reviewed, scoldings to be given, meetings to prep for, and nobody has had a chance to call and toss it all out the window for today's big fire yet. So, I'd imagine management types (who generally are the types interested in these studies, which are often perpetrated by HR types who have all of the above except the calls it seems...) are themselves most productive in the morning and magically their studies agree. Meanwhile I *can* get some decent code pushed out in the later morning (11-ish), but of course in the normal workday that is very quickly trumped by lunch. The afternoon is hit-or-miss, I've always been able to concentrate best in the evening (8-11) when left up to my own devices (so, a day of forcing myself on-task means I don't get bupkiss done at night, even the dishes are a pain), and of course there's the college-style "2-5 a.m. dash" when things are crunched but I hardly think that counts for "mornings are more productive. So, I disagree if you're talking about programmer-types, and trying to pin down when good design work gets done generally has more to do with how hot the shower water is, how relevant the day's meetings are, and the price of tea in china...

Ennis Ray Lynch, Jr. wrote:

I guess the moral is that sometimes, it is ok to not be in control.

True, but then you could also say that the moral is, if you don't want to be following a crummy set of standards, don't blow off putting them together. The nit-pick sessions are definitely useless wastes of time (enforcing the standard is good, but those pesky logic errors...), but consistent and good (and consistently good, for that matter) style and structure should make those logic errors easier to find and fix. Unfortunately, as you said, the "best and brightest" often don't want to be bothered either writing or following a standard unless it's a big one they can turn around and bash their favorite target for not following (be it MS, F/OSS, or just another team in the same office). Kind of makes you wonder just how best and bright they are, but... Standards, unfortunately, rarely just coalesce in a lot of the settings where they are most useful... so people really do need to take more interest in helping make them relevant and to stick with them. That way when it is time to do the review standards issues are quick and easy to clear up (because people are following directions in the first place) and you *can* just focus on logic (which will be easier because everyone will be familiar with where things are in the code).

Even using the GUI tools isn't as nice as it should be with RH... personally, I quite like working in *nix (it always seems easier for me to just get whatever little stuff I'm trying to do done than writing something against Windows, and big stuff is big stuff on any platform) but I absolutely loathe trying to set some tool up on an RH system... Apache is a nice example, what with the complete disconnect between the Apache documentation (and 90-ish % of the "how-to" articles people have written) on setting up some add-in and what files to modify to enable new mods, and the reality of the pre-installed instance RH set up and sprinkled around the file system with directory names that have *nothing* to do with what anyone else does. Some stuff works great, but there are too many people deciding they know best with some of the package tools... enough to make you go crazy and actually wish you could F3 your way through the registry manager to figure out where something's installed.

True for, but not always true of, especially in a Really Big Corp. of America setting... what I've noticed is that faking it has become a lot easier and organizations which don't pay enough attention to their departments during the hiring process are getting a lot more people who are not terribly good (and thus easily fooled themselves). A fatal flaw which should be corrected, but one which leads to the OP's complaint very quickly.

... ...... d(O.O)b Anyway, having had the luxury of .NET doing a lot of the obnoxious work for me (though, I have to say, actually implementing IEnumerable does have some advantages over a for loop when you're making your own classes) and the, erm, "experience" of untangling/deciphering/gutting a lot of horribly bad and inexplicably functional code... it really is a lot like driving on the highway compared to flying a plane. Pretty much anyone can get a driver's license, and every time someone comes up with something to make driving (or some other part of life... like keeping in touch with your #*&$@(*# Aunt Ethel) easier all it will do is give the numpties one more way to cause a big headache for everyone else. The thing is, it *does* make it nice that I can hop in the car and drive to the next town to do a little shopping instead of having to learn how to fly there and file my flight plan and all that junk, especially when the departments I work for want me to pick something up *yesterday*. Similarly, it is nice to be able to throw together a UI in about 5 minutes (ugly as sin, but still, it's there and usable and I can have semi-complex input like a data grid for little fuss) rather than having to handle all the fun things it can take to do "the old way." Especially when our client departments keep changing the calculations on their reports so often we don't have time to worry about rearranging the display because we're too busy re-writing our logic. So, I don't think it's a bad thing to save developers time, because it gives us a bigger percentage of our time to work on the stuff our customers care about (the calculations and data). The real problem that I see with "lowering the bar" is not that it makes it easier for people who shouldn't be coding to code, but that it means the people in charge of hiring coders have to learn how to figure out who knows what they're doing, and who googled up some examples, pasted them together in a monolithic source file, and called it their grand unified program for inventory management at their previous employer. The idiots have always been there, it is just getting so you can't spot them as easily.

How much work is he really having to do on the repositories? If he's going to argue that switching to Perforce will be more productive (I take it he has experience with Perforce?), then how much adjustment will that require for the developers to get used to the Perforce interface and quirks compared to whatever you all are using for SVN? Also, if you use the scripting hooks at all, can that be easily recreated? All in all, I'd be a bit skeptical about any argument that is claiming to save admin time on account of a GUI for backups... I don't know your admin, but all the admins I do know generally complain when they *have* to use a GUI for that sort of thing, not when they can't. Does he perhaps have some other reason for preferring Perforce (is he suggesting that specifically, or a commercial product in general)? One admin's preference should not overrule the operating comfort of a room full of developers... if your team(s) prefer SVN, that should be argument enough.

While I have seen plenty of this in my much less considerable experience (and am currently listening to a conversation attempting to justify not learning something "new" even as I type...), I've also found that 'ordinary' businesses (as the article and a couple of other posts suggest) tend not to give two hoots about their developers' coding choices and learning. They (company upper management) want people who will churn out the results they're asked for and if you already know one way to do that, you won't be getting a chance to learn a new way anytime soon without getting together with lower/middle management and instigating some subterfuge. Not to refute that there are many many 'lame and lazy' running around, just a follow-on observation as to how so many once-promising developers can end up being bored into that bin along side folks who started there.

If localization is an issue the colon just becomes another thing to add to the list of locale-specific values... For me, the decision is usually based on the sort of form/page/etc. I am writing. If it is an extraneous screen element (i.e. not going to be found in any container called "main_content" or some such) it very likely won't get a colon because it won't be terribly important that the user want to fill it in RIGHT NOW. A good example would be the "Search" box at the top of this reply form: the current display's main purpose is to capture my reply, so the label for the search box is there to announce its presence and let me know that particular cluster of controls is how I find something. On the other hand, the controls for actually filling out my reply all have labels followed by colons, because they are part of the main purpose of the page and instructing my on what information I need to provide where, similar to forms throughout the ages. You could always use the "other" major format for labeling form fields and stick everything in a heavily-bordered table with weird superscript labels as on a US tax form and then ask which is better...

While I somewhat agree with the "jump in and drive" notion, programming is going to range from "Mechanic" to "Engineer working on NewPanaceaEngine #45," whereas driving gets you into your editor. If you have a good understanding of either Java or C# (especially in terms of how they manage memory for you, which will be important once you're working on algorithm implementation... probably sooner than one might think) they can be good learner-languages because they provide a VERY easy starting point, both can transition to a GUI quickly, both are applicable almost everywhere (too clunky for ad-hoc scripts, for example, but that's hardly something to worry about when you're trying to get started), and both have a nice $0 price tag complete with some nice development helpers. It's really just a matter of "pick your poison" as far as if you want to be locked into MS for a while, or locked into Sun for a while. Personally I'd go with C/C++ though- all the power you need if he really dives into things and wants to learn all that lower-level stuff the runtime languages have decided to shield you from, but easy to pare down to a simple subset for getting one's feet wet without being overwhelmed. Graphics might be a bit of a stumbling block (but really, anything more complex than a form is tricky no matter what you're writing in), but the ability to do almost any "type" of programming (OO, functional, assembler...) without changing your "base" language is a big plus IMO.

Step 1: Project members tell project lead they need someone who knows TechX Step 2: Project lead tells Project Manager they need a mid-senior (whatever they're calling us that day) who knows TechX (forgetting to mention what constitutes mid-senior for said TechX). Lead wants someone who's been around a while and hopes this will cut down on green applicants. Step 3: Project Manager gives HR job descriptions for a mid-level and senior-level position including TechX. He wants someone who's been in the trenches (like the Lead) and decided he'll figure out how well they know TechX in the interviews. Step 4: HR takes company standard level-to-years correlation and adds it to the description, usually *after* the word "including." They then toss this out to the world without checking to see if the request still makes sense. Step 5: Entertaining posts on sites like this. All sorts of fun comes once HR gets involved...