91–100 of 361 posts
"Experienced COBOL programmers can earn more than $100 an hour when they get called in to patch up glitches, rewrite coding manuals or make new systems work with old." Any contract-based engineer would charge that, or more, regardless of the language. Fortune 500 companies are happy to pay $300 / hour to a consulting company for engineering time.
Earlier quoted context omitted.
I'm curious what your experience in Australia has been for you to think that. In my experience that's not what I'd call a lot in Australia, most commonly your average basic IT contactor will charge $80-120/hr, let alone any sort of speciality.
I've always been in a startup or just a full-time employee - my point still stands though, if that's an average rate then why did the article point it out?
Been working on accounting systems in RPG and COBOL since ~1992. I also know C/X86ASM/Pascal/Delphi/VB/Fortran. Never bothered with C++ that much; played with Java a bit but Oracle irritates my bowels so moved away from that. As mentioned in the article it's good work; but it is also not easy work. You tend to go through cycles of being pushed out to brought back under extreme emergency at any costs to get stuff work…
Wow, like $800-900k?
Earlier quoted context omitted.
At my last employer, there were a few "mainframers" (we called them). I was curious so I would ask my mainframer coworker how things worked on his end. I always struggled to understand, because it seemed everything was different ... the terminology, the culture, the ideas. I couldn't use analogy to tie what he was describing back to what I knew.
You got that right. I had to deal with an interesting banking file format and I asked a question on Stack Overflow and got this gem of an answer. I politely accepted it as the right answer but boy oh boy does it feel like it's from an alien civilization. http://stackoverflow.com/questions/28640159/what-is-the-diff...
Been working on accounting systems in RPG and COBOL since ~1992. I also know C/X86ASM/Pascal/Delphi/VB/Fortran. Never bothered with C++ that much; played with Java a bit but Oracle irritates my bowels so moved away from that. As mentioned in the article it's good work; but it is also not easy work. You tend to go through cycles of being pushed out to brought back under extreme emergency at any costs to get stuff work…
> Companies never think of the old guys as the ones to implement the new system - that's a job for the "enterprise experts" Exactly this is why rewrites fail. The challenge of a rewrite is not in mapping the core architecture and core use case, it's mapping all the edge cases and covering all the end user needs. You need people intimately familiar with the old system to make sure the new system does all the weird stu…
$100/hr doesn't seem like a good rate for a true 'niche' when $185-$250/hr is going around for everything from Hadoop to Kubernetes.
I remember running into someone who worked at an insurance company in my home state and mentioned their whole system ran on COBOL. I asked her how she hired programmers and she explained they hired recent college grads with no technical background and trained them from scratch, since it was easier and cheaper than hiring experienced COBOL programmers. Looking back I'm surprised they had the institutional knowledge to…
Any of the new hires with talent quickly discover they can double their salary by doing pretty much anything else in IT and move on. IBM and their customers want to turn the whole thing into a McDonalds style business, but the burgers keep burning and they keep having to call people to come in and rewire the microwave and unplug the toilet.
Earlier quoted context omitted.
> Companies never think of the old guys as the ones to implement the new system - that's a job for the "enterprise experts" Exactly this is why rewrites fail. The challenge of a rewrite is not in mapping the core architecture and core use case, it's mapping all the edge cases and covering all the end user needs. You need people intimately familiar with the old system to make sure the new system does all the weird stu…
What about not doing a rewrite? What about instead refactoring, documenting etc the old system.
Also, too many of the talents are stuck in a blocked I/O mindset somehow.
Some are wizards though, writing assembly and making raspberry pi sized systems blazingly fast. OK a couple of raspberry pi:s
Earlier quoted context omitted.
You got that right. I had to deal with an interesting banking file format and I asked a question on Stack Overflow and got this gem of an answer. I politely accepted it as the right answer but boy oh boy does it feel like it's from an alien civilization. http://stackoverflow.com/questions/28640159/what-is-the-diff...
Am I missing something? That doesn't seem all that odd, but perhaps that's because I'm familiar with IP,TCP and UDP and I've written something to read PNG headers before. Interchange file formats often include variable length blocks, which a part of the header defining the block length. That first part of the record is just a very small header per item, which defines the type of item and the size. Look into the defla…
The interesting part is that the fixed and variable record formats are first class things on the mainframe.
So, something like DB2 on a mainframe can use system supplied functionality (VSAM) as their storage engine. As opposed to unix, where higher level databases like MySql, CockroachDB, etc either roll their own (InnoDB) or use some 3rd party offering like RocksDB, LevelDB, etc.
VSAM isn't just one thing either...it supports k/v indexing, or indexing via relative byte address, or indexing via record number, etc.
So, basically, when you talk with mainframe people about interchanging data, they don't tend to consider that you might actually have to write some code to parse what they are sending you. They tend to assume you already have utilties that understand these things. It's not an interchange format...it's the native format for them.
I suppose the answer seemed novel because it's speaking with very specific "official sounding" terminology about something that's usually ad-hoc negotiated by project in the unix world.