Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:
You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.
Seeking to maximise personal revenue, while minimising effort should not be detrimental to one's clients and doesn't break 'Rule 1'. One won't maximise revenue over the long term by doing poor quality work; similarly, minimising effort equates to delivering in the most efficient manner. It's transactional.
At business school we're taught that the objective of the firm is to maximise profit (shareholder value). For a firm, workers are a means to that end. It's therefore, I suggest, rational for workers to consider the firm (client) as a means to an end. To my mind this is not indicative of a detrimental attitude.
I'm sure we've all seen capable workers who were naively loyal to a firm getting ditched when the firm no longer needs them. This is particularly the case for people who become middle-managers and lose marketable skills along the way. I do think that some (smaller) firms are still benevolent to their workers, but I've noticed a general decline in this over the decades. I simply see working for a living as a transaction, not a relationship.
Nicely put, I was just going to tell him to **** off! lol..
Finding the error in 1000s of lines of code is par for the course with the old 2GL languages, not just COBOL. You have to learn to read the core dumps. But properly written (a lot of which wasn't, naturally) it can be pretty much self-documenting.
COBEL still in use?
VB6/VB.Net died a long, long time ago.
Introduction to Programming back in the day (early 90s) at Uni.
1st semester: Turbo Pascal, nice to learn, there's an error on this line and it's probably because of this...
2nd semester: COBOL There's an error in these 1000s of lines. F**ked if I'm telling you where the error is or what it is.
So I was not a fan of COBOLLOX.
qh
Finding the error in 1000s of lines of code is par for the course with the old 2GL languages, not just COBOL. You have to learn to read the core dumps. But properly written (a lot of which wasn't, naturally) it can be pretty much self-documenting.
Not to be a Boyscout, but I find this behaviour very disheartening.
Rule 1: Always act in the best interest of the final client. Good things will then happen to you (and the parasites between you) naturally.
Contractors with the attitude espoused by Protagoras and Oliveson working with me tend not to find themselves in that situation for long.
Seeking to maximise personal revenue, while minimising effort should not be detrimental to one's clients and doesn't break 'Rule 1'. One won't maximise revenue over the long term by doing poor quality work; similarly, minimising effort equates to delivering in the most efficient manner. It's transactional.
At business school we're taught that the objective of the firm is to maximise profit (shareholder value). For a firm, workers are a means to that end. It's therefore, I suggest, rational for workers to consider the firm (client) as a means to an end. To my mind this is not indicative of a detrimental attitude.
I'm sure we've all seen capable workers who were naively loyal to a firm getting ditched when the firm no longer needs them. This is particularly the case for people who become middle-managers and lose marketable skills along the way. I do think that some (smaller) firms are still benevolent to their workers, but I've noticed a general decline in this over the decades. I simply see working for a living as a transaction, not a relationship.
Quite. I think we leave it here, but the solution (in COBOL...) is to store the input year as a 4 byte word, described as a 32 bit binary number. If the right hand pair end with 00 then it is divisible by 4, and it's a leap year if the left hand pair also ends with 00. Most of the work (again in COBOL at least) is done with the data descriptors. The actual code is two nested conditional statements.
I feel your pain. Good luck going forward...
I saw it coming, but went ahead anyway.
An elegant solution. I'd have to test it, though.
Now where's my EBCDIC-based COBOL compiler...
/* REXX _____________________________________________
| If 2 days between 3/1 and 2/28, it is a leap year. |
|_________________________________________________ _*/
Do I = 1990 to 2010
If 2 = date('B',I'0301','S') - date('B',I'0228','S') then,
say I 'is leap year'
Else say I 'is not a leap year'
End
What I see happening here is that 'we' are reduced to in-fighting, be it about technical skills, nationality or whatever. It's not nice and it's not helpful.
There are probably only two camps; those with the skills to survive and those with the funds to opt-out. Certainly there's no point holding out for better days; they're behind us.
Now, I'm a nerd but even this is boring the living out of me!!
I dread to think what the BA's are thinking!
Quite. I think we leave it here, but the solution (in COBOL...) is to store the input year as a 4 byte word, described as a 32 bit binary number. If the right hand pair end with 00 then it is divisible by 4, and it's a leap year if the left hand pair also ends with 00. Most of the work (again in COBOL at least) is done with the data descriptors. The actual code is two nested conditional statements.
But on the subject of the market, yesterday I had a zoom call with an agent regarding a piece of work. Quite topical to recent conversations on here on Indian consultancies, but this is one where the work is coming back to the UK / Europe. Turns out the savings just aren't there these days to justify the often 'poor' quality of work and there's a massive technical debit issue that needs addressing. Think they're looking for double figures in contractors. However, the interview process is one of those horrible in-depth leetcode / pair programming tests. I kicked those into touch after doing them exhaustively in my London banking decade. The search goes on.
In that case, I would probably use assembler language, not COBOL.
To avoid division (D is available in IBM 360 assembler, but not effiicient) I might:
a) Subtract 4 from the number repeatedly until either 0 or -ve
b) Subtract 100 from the number repeatedly until either 0 or -ve
c) Subtract 400 from the number repeatedly until either 0 or -ve
if a is 0
..if b is 0
....if c is 0
......return Y
....else
......return N
....endif
..else
....return Y
..endif
else
..return N
endif
.. and of course for efficiency you could delay calculations b and c by placing them within the nested if statements.
So only execute b if the first if statement passes, etc.
Now, I'm a nerd but even this is boring the living out of me!!
I dread to think what the BA's are thinking!
But on the subject of the market, yesterday I had a zoom call with an agent regarding a piece of work. Quite topical to recent conversations on here on Indian consultancies, but this is one where the work is coming back to the UK / Europe. Turns out the savings just aren't there these days to justify the often 'poor' quality of work and there's a massive technical debit issue that needs addressing. Think they're looking for double figures in contractors. However, the interview process is one of those horrible in-depth leetcode / pair programming tests. I kicked those into touch after doing them exhaustively in my London banking decade. The search goes on.
Leave a comment: