Job ad promises 'Meaningless Repetitive Work on the .NET Stack' A job ad has appeared offering one lucky worker the chance to perform “Meaningless Repetitive Work on the .NET Stack.” The ad is real – recruiter Joshua Wulf told The Register he wrote it after a conversation with a candidate “who told me what his job is really like.” Wulf then considered plenty of other job ads and decided …
“My phone has been ringing off the hook,” he says. “People are telling me they are strangely attracted to the job because other jobs don't sound real.”
I daresay that's the proof. It does sound more real than almost every job ad I've ever seen. No buzzwords like "fast-paced environment", "growth and goal oriented".. etc. No unicorns work there obviously.
Indeed. Even more important I think is that your boss will really understand that your job sucks, and how, which might make having a job that sucks easier to take. The job they are offering is not that different than what a lot of people do, but their bosses think they should be happy and fulfilled doing it.
Of course this was all a scam to get publicity - I think they said "we can't find anyone qualified who wants to take this job, the only ones interested are vastly unqualified...what can we do to stand out amongst the thousands offering similar jobs?" Obviously they let the team doing this work currently write the job description and told them to be brutally honest and highlight the worst parts of the job. They hoped it would get attention like this.
Pity it's in Brisbane. Was actually in the process of giving him a ring until I caught that (I scrolled down before I looked in the upper right corner).
I'm fortunate enough that I'm currently working in the absolute opposite - let's call it "Buzzwords Done Right". I therefore have no idea why I feel this strange attraction, yet I do.
Us nerds are weird...
The staggering thing to contemplate is that even "native"* COBOL already had all the real benefits of "managed" code. No memory management to worry about, highly abstracted framework for system level services etc etc. How much Win32 or even .NET code is going to simply recompile and run on the future-current stacks in 35 years time ? Heck, even 15 year old .NET code won't compile and run (unless you use 15 year old compilers).
In fact, the only real problem with it was that it is a truly fugly language (tho' not a fair accusation at the time of it's inception given the alternatives) that was so abstracted up the wazoo that it made understanding even the simplest code an exercise in recall, after having committed to memory every obscure detail of the underlying frameworks that made the abstractions possible.
* the distinction between "managed" and "native" COBOL is forced upon the vendors in order that their customers can discriminate between the .NET (managed) and Win32/*nix/etc (native) platforms.
In fact, C# really is the new COBOL (but without the stability or dependability). :)
Actually most languages from that time were, what Microsoft now calls "managed". It's simply because back in the day language developers looked at what programmers had difficulties with... and addressed those problems. One of the main problems programmers are still having was pointers. So it's just logical to remove or de-fang those. For systems programmers there still was assembler or C.
It's only in the 1980s that, with things like the emergence of C++, we look at languages and deliberately create more difficulties.
"It's only in the 1980s that, with things like the emergence of C++, we look at languages and deliberately create more difficulties."
Boo hoo, you have to specify your requirements explicitly. System programming in the large is much easier in C++, even procedural programming is easier in C++. C is still a little faster, and a little tighter on resources, but at quite large drop off in shared knowledge.
// common knowlege of lifetime, access levels, and interface.
const std::vector<std::string> &
VS
// knowlege of size and static type
const char **
How much Win32 or even .NET code is going to simply recompile and run on the future-current stacks in 35 years time ? Heck, even 15 year old .NET code won't compile and run (unless you use 15 year old compilers).
I have plenty of 15-year old Fortran code around, and a fair bit of 35-year old FORTRAN [*] code, which compiles and runs (correctly, and quite efficiently) using modern Fortran compilers. The 1980s-vintage FORTRAN-77 code does look a little weird to me now (even when it's my own code) - but as long as it was originally designed with a bit of thought invested into it, it is still perfectly maintainable and interoperates well with modern Fortran code.
The reason for this longevity is quite simple: maintaining compatibility with both the syntax and semantics of previous versions of the language has always been a key objective of all new Fortran standards. There is a downside, of course: some of the language will occationally feel awkwards and strange, especially if you do not know why a particular choice was made the way it was. As far as I am concerned, this is a small price for being able to reuse both my own and others' code from many years back.
[*] The name changed to Fortran with the Fortran-90 standard: the language was called FORTRAN before then.
You can't really have truly "native" COBOL unless the hardware has support for packed decimal arithmetic: the two are inextricably entwined.
This is utter nonsense. It's like claiming C is a "managed" language unless fdiv is implemented by hardware.
Native COBOL is compiled to, and runs as, native code. The compiler generates native op codes. The code uses native addresses (and COBOL does have a pointer type). The generated program uses the native ABI.
C# really is the new COBOL
Actually I reckon that Java is the new COBOL, as in "the language used by everyone for everything, even when it's obviously bloody insane to use it for that".
Java has actually managed to fill that "enterprise default language" niche previously occupied by COBOL despite being, if anything, even less suitable for the job than COBOL was.
Java has actually managed to fill that "enterprise default language" niche previously occupied by COBOL despite being, if anything, even less suitable for the job than COBOL was.
A little while ago, I was working for a Python shop.
One of our coders had something of a penchant for Java, and clearly didn't like having to work in Python. He actually committed a piece of code that loaded up a JVM[1] so that he could instantiate a hashmap.
I rewrote it with a Python dictionary[2]...
Vic.
[1] From a hard-coded path reference, no less. So it worked on his machine, but not on anyone else's.
[2] I realise that the classes aren't exactly identical - but the dictionary did everything he wanted from the hashmap.
As somone who trained as a COBOL programmer over 40 years ago, the main feature of the language was that you didn't have to know anything about computers to program in it.
As the name says, it is a business orientated language.
You write things describing simple real world actions like adding, subtracting, moving data - things that can map to paper based systems. So no computer science graduates required.
Then again, it ran on huge mainframes and anyone wanting to get down and dirty with low level languages tended to be re-educated with the clue stick.
I soon moved to more technical areas because COBOL programming quickly became deadly dull (also I don't seem to have the mind set to enjoy doing one thing for long periods, so I didn't stick to programming either).
My mind is still being boggled by the concept of "Managed COBOL as part of .Net". I am an unemployed COBOL programmer but this is by choice. Work is so last decade.
> Then again, it ran on huge mainframes and anyone wanting to get down and dirty with low level
>languages tended to be re-educated with the clue stick.
Oh - I dunno. I was an IBM mainframe (S/370) assembler programmer in my misspent youth.
Then I grew up and became bitter^w a support person.
Or legibility or maturity.
A computer language is just a tool. The job you do with it is partly predicated by your actual knowledge of how to use it and for which jobs it is intended, and lots more predicated by your preconceptions of what it can't do (which is just a way of saying "what I can't do with it 'cos I don't know how").
Now pass me the Stillson's so I can give this Rover slush-box valve a good thump and get the shift working again.
Every so often, you think things are shit, then something comes along like "Managed COBOL" and you realize how narrowly you missed a bullet.
Managed COBOL is a hell of a lot nicer than native COBOL, and managed OO COBOL with the new concise, portable syntax is a hell of a lot nicer than procedural COBOL. And sometimes there's a benefit to being able to compile the same sources for CLR and JVM.
Frankly, I'd far rather maintain a managed-COBOL codebase than a C++ one. There's a nice language hidden in C++, but almost no one has the discipline and knowledge to use it.
(Edit: I'm talking about the MF-brand managed COBOL. I don't have much experience with the Acu product line, and I've never used Fujitsu's managed COBOL.)
One of them recommended telling the horrible truth about a truly awful job excavating in a tropical swamp. By telling the horrible truth the only candidates would be people who loved ground breaking Mayan archaeology, exactly the sort required. The usual "dynamic ground breaking research " style would get a lot of shiny academics unable to cope with real mud and crocodiles.
Indeed, ad is interesting, despite not having .Net. Anyway Deltics is right. COBOL is very good at what it does. Very elegant coding possible. <OFFTOPIC> I have noted articles predicting the end of COBOL have faded away in current decades. Delightfully ironic.</OFFTOPIC>
Let's see...
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
It was C Northcote Parkinson who advocated writing a job description that balanced the good and bad points such that exactly one person would apply. That person could then be immediately given the job, with no need for CVs, selection panels, interviews, psychological assessments etc etc.
at COBOL.
But I do get why there is such a massive response. Technical people* are trained to work with facts. Everyone of us who works or has worked in large-ish organisations has experienced the 'management by self delusion' that kicks in when the upper echelons slip into the 'boss zone'. Also, let's face it, a lot of technical people have a personality* that can make it tricky to handle outright lies, even at the little-white-lies level of, say, compliments or smalltalk.
*I know one should only speak for oneself, so sorry for the generalisation; it's always uncomfortably close to cliche.
**There are reasons why I'm an engineer and not, say, a salesman, or a priest, or a social worker, or ...
Anybody working with .NET, ASP.NET, JavaScript, VBScript already does that. It's part of the job-description, and "designed" in, near as I can tell.
COBOL, on the other hand, is dead ... Long Live COBOL!
Seriously, there are more functional lines of COBOL and Fortran working in big business today than the average kid who never used a dial telephone could possibly imagine. I do not know of a single COBOL or Fortran programmer who is currently out of work. I can't say the same for Java(script), VisBas, C++, C#, and what-have-you. Not a month goes by when I don't get email from a former student, thanking me for suggesting COBOL or Fortran as another programming language to learn ... The two are pretty much ubiquitous in big business.
as a recruiter of (too) many years experience it's nice to see a job being advertised honestly. so many times I would have loved to have written a job ad like that but essentially I could kiss goodbye to that clients business if I did. some of the bollocks we have to try to sell to candidates when you know the reality is the polar opposite sometimes beggars belief. but as its my own biz I have been able to steer away from recruiting for truly crap companies where possible; yet there are others where I have been able to paint the downsides along with the upsides and as this company has found some are curiously interested when they have this info.
> so many times I would have loved to have written a job ad like that but essentially I could kiss goodbye to that clients business if I did.
He explains at the bottom:
Normally I only work with organisations that value professional software development and professional software developers - but this one just paid too much to say No.
His emphasis.
Upvote for the honesty! As a contractor of far too many years experience also, I can tell you that the old hands have mostly developed finely tuned bullshit filters after a few years and bad experiences.
I ring a recruiter having seen a ad by choice, and I can feel the filter's gears turning in my head as I hear them pitch :-)
Anon, because, I might need you in x months next time I get bored :-)
Well they did claim .NET was the answer to DLL hell.
Though I quickly discovered that, after writing a lot of useful stuff, that .NET 2 wiped the earlier version of .NET of the pc you installed it on so you had to re-write all the earlier stuff to get it working again. So I'd just say its Hell2.0
There is sometimes no getting around the fact that not all jobs are writing AI algorithms for Google self-driving cars, or designing the next iPhone. I've worked for a lot of organizations like that who maintain systems that simply need to _exist_ for critical things to continue working. It's boring, there's decades of legacy technology and software, and these jobs require people who can tune out the buzzwords and just keep the ship running.
I actually find this a refreshing change from ads that tout any or all of:
"fast paced" (80 hour weeks minimum)
"cutting edge" (developers dumping barely-working software to production, Framework Of the Month Club)
"collaborative environment" (anyone over 30 need not apply)
well, I'd MUCH rather do COBOL than ".Not" coding, that's for sure.
having to do BOTH - maybe they should hire a starving contractor in a 3rd world country... someone willing to actually SUFFER that much.
or they could hire ME, I'd hold my nose and get it done in a very short time, but for a unbelievably high price - my soul (and sanity) is worth a LOT these days...
[we've all had that "clean up this @#$% code" contract, haven't we?]
my worst case example of this was from my predecessor at a major computer hardware company, in the M.I.S. department. There was a COBOL to FORTRAN 'hook' needed by the ASK/MANMAN system (written in FORTRAN) to get sales tax from the VERTEX (written in COBOL) system, that had quarterly tape updates and everything [it was the 90's on a minicomputer]. The hook's source was lost. When I made some requested changes to the COBOL, an old bug re-surfaced. Seems that the FORTRAN side of the hook was having values passed by REFERENCE, and the DOOFUS programmer MODIFIED THEM before passing to the COBOL code (add 1 or something). What he SHOULD have done is made copies. His 'fix' was probably to subtract 1 again, or whatever. My fix was make copies into different variables, modify THOSE, pass THOSE to the COBOL program. And that programmer's name is permanently burnt into my 'never work with THAT guy unless I'm 1 day from absolute financial ruin' list.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
