Dev loudly complained about older colleague, who retired not long after It's hard to confront the start of a working week, but each Monday morning, The Register tries to keep the weekend fun going for another few minutes by delivering a fresh edition of Who, Me? It's the column in which we take your tales of your most ticklish moments at work and share them for the amusement and/or education of your …
I was working in Asia, and helping a customer team with one product. I did a couple of presentation on the platform, and some on life skills, such as "if you do not like your job - it's your fault - you should change jobs".
I had several people come and see me "for a career chat", and also to ask me basic questions about DB/2. The senior person in charge of the DB/2 team was never there, he was always out "with customers" and executives, so the more junior people had no one to go and ask technical questions. I knew a little about DB/2 so could answer some of their questions.
I mentioned the lack of visibility of the DB/2 team leader to some of the senior managers I was working with, but did not seem to get very far. The culture was not to criticise your elders or peers, so they were not used to the feedback I gave.
A month or so later the DB2 team leader got a job in Marketing, and was apparently very good at it.
I had some feedback from one of the senior managers saying "thank you for your feedback, but you did not handle the situation well". The fact I had raised the issue meant that the management team were not doing their job very well, and so caused "loss of face". I went back a few months later, and the DB/2 team were much happier. So overall a success.
There is never a perfect way to address failure of responsibility by senior managers when they have personal ulterior motives.
One usually goes hand in hand with the other. Good to hear you suffered no real retribution. I, on the other hand, keep stepping on the landmines, but when I'm set up for failure, I will always do my best to take those responsible, down with me.
Incompetence knows no age and if not addressed, will destroy any organization of any size.
"The culture was not to criticise your elders or peers, so they were not used to the feedback I gave."
There's a specific way to do it. If you emphasized that the person's duties meant they needed to spend the bulk of their time with customers and management to further the fortunes of the company and that meant their extensive knowledge wasn't available in the office to mentor their juniors that somebody else needed to take care of that less important task.
Of course, you can just call that person a moron and that their approach is retarded and see how that is taken.
The mundane, boring things like actual work are not their area of expertise.
Management is a really odd job when you think about it.
It's a job that is most definatly needed, but it's very hard to actually train people to do it. Most of the people that end up doing it are simply there because of 'promotions', and who ever turns down a promotion and more money?
I have one manager I've worked with who stands out still as the best one I've ever worked with (this was 10-15 years ago now), I only realised how good he was when he left as that's when all the stuff he'd just been handling on 3 of our largest projects started to unravell.
The thing about it, is if you have someone who can do the job well then the reality is you'll never notice, as your job will just flow much smoother. (A good manager is a 'shit umberella' as much as anything).
However, as engineers we really do have to not fall in to the trap of assuming we can do it all and management is just this annoying barrier that gets in our way. Most engineers I know would be terrible if left unmanaged, as they'd do what they found interesting, which, despite what we think, is often not in the best interest of the project.
I currently work with a couple of people like this who have worked on one of our projects for many many years. They have this concrete view of where the product should go, and changes that are needed. However they're not the project owners, and they've not actually worked in the area our product serves; sometimes it can be a real battle to get them to see that what they want to do is not what they should be doing, as, at the end of the day they're paid to do a job and the product is bigger than just those 2 people, and also, it's the companies product and it's up to them where it goes, not the devs.
For me, the classic example of this in our industry is the Commodore C128. 3 machines in one, one of which was too slow to be usable, and the other lacked software (why would you write C128 specific stuff when there's a few million more C64s out there). So you have this wonderfully clever machine that no-one really wanted, and should've never ever been taken any further than the initial idea stage.
But in those day Commodore management had checked out and the engineers were just doing what they felt like... great fun, but not long term sustainable.
Assuming it was the case (and it was the time when IBM was a force to be reckoned with) the situation described in TMMM sounds ideal. Management and engineering had parallel ladders. Someone could be promoted into management but if it turned out it wasn't for them they could move back into engineering without it being a demotion because there was an equivalent engineering grade. The problem arises when management is et above all the the other areas so is the only way to promote someone. It makes as much sense promoting someone from, say accounts, to be a manager as promoting them to be a chemist.
"Someone could be promoted into management but if it turned out it wasn't for them they could move back into engineering without it being a demotion because there was an equivalent engineering grade."
Many government jobs have a maximum "pay grade" so anybody doing what they like and are good at that hits the limit will have to go someplace else to make any more money. It's a perfect way to lose your best people as some other company might be happy to take them with a nice pay rise.
Why would you write C128 specific stuff when there's a few million more C64s out there
That's like asking, "Why would you write Enhanced Graphics Adapter-specific stuff for PCs when there are [some large number] more Monochrome Display Adapter-equipped PCs out there?"
Except that your customer can buy an EGA card without having to buy an entirely new PC (unlike buying a C128 and still having the C64 in good working order).
Oh, and having an MDA (or, better, a Hercules card) AND your shiny new EGA card plugged in together meant you could now run two monitors on one machine (not quite as seamlessly as with today's GUIndesktops).
The two situations - buying a C128 or an EGA card - were nothing alike, so the questions of writing s/w for one or the other (in terms lof whether there could be a market for that s/w) wasn't alike either. Even before you raise the question of what types of use each machine was going to get (business or pleasure) and what that did to how much you could charge for the (possible) versions of the s/w. And so on and so forth.
That is true.
But you had to decide to take the plunge at the initial purchase, and there wasn't much C128-specific s/w available, so you - unless there was already something you wanted to run - it was a leap of faith that the programs would appear. There was a bit of a self-reinforcing loop between buyers and authors, neither wanting to take a gamble on the other.
As opposed to starting with just the MDA board in a PC, knowing that you could upgrade as/when the EGA software arrived: you're not having to take any leap on day one, if you don't wish to.
"and there wasn't much C128-specific s/w available,"
It ran CP/M, so could have been thought as a good justification to get a "games computer" for the kids while still having something capable of running business oriented s/w for the parents, which the C64 really wasn't good at. It didn't work, but it wasn't a bad idea. Maybe it was just the market at the time, more specifically the US market? Amstrad managed to be a huge seller in the UK and Europe with the CP/M based PCW range, so it can't just be that CP/M was "dead" by then.
It ran CP/M - badly. If you're going to compare it to the PCW the 128 by itself initially looks OK, however :
It's slow, due to the 128's flawed architecture the Z80 is running at an effective 2MHz
By the time a full package of a 128 is added up, including monitor, disk drive, and printer you'll be paying as much or more than a PCW, and it still won't come with Locoscript
Most CP/M software doesn't support colour by default, so the 128's more flexible graphics aren't as much as advantage as you'd think
The base model PCW8256 had twice the memory
If you're looking primarily for a CP/M machine, you'd choose a PCW. If you want something that could also run games and do colour, you'd probably go for a CPC6128.
Although CP/M was a huge advantage for the PCW its main advantage was that out of the box it could do affordable word processing.
Okay, I perhaps should've said 'Why would you write C128 specific games when there's a few million more C64s out there.", but I'd argue the lack of a large volume of C128 specific software is fairly well documented??
This list seems to have less than 200 titles (excluding utilities, but including C128 specific games). Whereas there's much more C64 software out there.
IMHO there's 2 approached to management.
If the job is relatively unskilled or predictable you can have a command-and-control model where the boss is in charge and treats the subordinates as resources.
However if the term members are highly skilled knowledge workers (which should be the case in most IT teams) then the management should be more of an administrative function who's responsibility is to ensure the self-organising team has a clear understanding of the priorities and removes impediments to them working at their most efficient.
I'm one of those people they always assign the "problem children" to, most of whom have the required skillset but don't deliver. (That's before I became a GM.) It's always their manager's fault, IMO, for not communicating clearly & respectfully with concrete examples of where things are not working. For example, it's not uncommon for someone to acquire a reputation for never finishing anything because they get 90% of the job done and then lose steam, their interest goes elsewhere, or they get jerked away to deal with some emergency de jour but don't go back to finish the assignment. Their own perception is "look at all of this work I've done". Everyone else's perception is "they never finish anything". 99% of the time it just takes a respectful conversation where you walk through a complete example so they can see that not finishing that last bit nullifies all that work they did from a performance/reputation standpoint. And set a firm deadline and the manager follow through with the employee. Similar when the situation is like the one in the "Who Me", where the person takes way too long to complete the task due to not maintaining focus. When one of my manager's makes a habit of publicly rebuking people, that manager's days are numbered. Even in the very rare situation where communicating intense displeasure with the employee is warranted, it should always be in private. Bad managers, especially ones that show a lack of respect towards others (& especially their reports), cause more problems than the occasional underperformer. Those are the managers that end up causing law suits too.
Bad managers, especially ones that show a lack of respect towards others (& especially their reports), cause more problems than the occasional underperformer
These (allegedly) fly on the wall documentaries from America often have a shouty boss: It sets a bad example of how to behave as a boss.
In my experience, it is because managers of developers are often not developers themselves.
Writing code is quite difficult to "measure," because by its definition it is always breaking new ground, and you can only measure in comparison to what you know. Unless you already intimately know the code in the wider context, determining whether a developer is performing well or not is difficult. If you don't know how to do the development job itself, you can only go on the person's ability to "talk the talk".
Even when a manager does come from a development background, if they have sought that job out, they are likely to be the sort of person who is more interested in telling others what to do than doing it themselves.
Other developers are often in the much better position to determine which of their peers is not pulling their weight. However, nobody really wants to put their head above the parapet. Snitches get stitches.
One of the issues can be documenting evidence in case the person being sacked takes it before a tribunal. That can take time. It's difficult to prove a case of somebody not being liked very well or is too chatty at the office. Remember that employee interaction has been one of the excuses to force people back into the office. Not getting work done in a timely manner IS something that is a good reason, but it has to be shown that the reason the person isn't getting things done is due to not knuckling down as opposed to being assigned the most difficult problems.
In any organization, there's often somebody that few, if any, get along with.
One guy was moved between so many teams and eventually ended up with us as the "American" side of things
One weekend he managed to fuck up royally on something that not only cost him a lot of his work, but some external consultants we had, who then had to redo all their work (not easy in the tool).
Then found out at some stage he was involved with some backup/VM's and not quite sure of the ins and outs, but we know there were some problems on that side of the pond for a few weeks - because of him.
Why still there ? Seems there were family connections with the CTO, so just moved. Seems we were the last chance saloon.
Another, was so useless that most of us did that persons work, but was so chummy with management, they could do no wrong and always got good pay rises and bonus (we all didn't). Being TUPEd and a few mis mailings and we could see just how beneficial "chummy" could be
And at another company, one person who we all knew was shit, stayed on because of their KPI's - being the best in the teams. The reason was a really bad print server and their ability to grab all the tickets as quick as possible and reboot the server. Became clear once the print servers were consolidated and therefore much more reliable and no longer crashing
The problem, as described, has several empty spaces. Where's the file, what format is the value, do we need validation, what protocol is used for reporting, what format does the reporting expect, how big is the value, how frequently must it be reported, should you report the value if unchanged, are there firewalls and are they configured correctly, what to do on error. A few more.
A significant chunk of the two hours would involve filling in those empty spaces. Depending on what they turn out to be, two hours could be plenty of time, or nowhere near enough.
Your solution is assuming the easiest possible answers for all of those questions. Local file, string, assume valid, email, no format changes, sufficiently short that performance is not an issue, very low reporting frequency, don't care about repetition, all other systems already correctly configured, ignore errors... In reality, we are lucky if we get the easiest answer on a few of those.
I remember a similar situation there was a C header file with 1000 entries like
#define AReasoncode1 0x1122001
#define AReasoncode2 0x1122002 etc.
Problem.. given the reason code 0x1122001 what was the label statement?
One guy started withh
if (rc == 0x1122001 ) preason = "AReasoncode1";
else if ( rc = 0x1122002) preason = "Areasoncode2";
etc
After a week it wasn't done.
I took the file changed the file to be
mymac (AReasoncode2 , 0x1122002 );
and mymac generated the case statement - case (AReasoncode2) : pReason = "AReasoncode2";
it took me half an hour.
I've had the issue where some wonk in management wants activity reports in 15 minute increments. One of the issues I had at a job like that was the tasks for just about everybody were hard to nail to one particular project as they all had common components. I did keep a daily work journal that outlined what I had worked on each day and an approximation of the time. A 15 minute increment would just be 00:00-Worked on taking over the world, and each row down would be "see above" for the whole day or week.
our management wanted to know what skills people had and so commissioned an expensive survey of people's skills. There was a question like "rate your TCP/IP skills from 0 to 10 - where 0 is no skill and 10 is an expert" one of my junior colleagues put himself down as an 8 (he knew all he needed to know to do his job <ping>). I put myself down as a 3 because there was so much I didn't know.
When the results were analysed the results were upside down. The manager responsible called some of the senior people in to discuss the results, and we decided the results were meaningless.
We quickly wrote a new one page survey. "Who would you go and see about a TCP/IP performance problem" ... or TCP/IP coding problem... or debugging TCP/IP problems".
This showed the real experts in the area. Some quiet people where flagged as "experts" and so got management recognition for this.
Sounds about right. My self-evaluation was that I was a metaphysical genius at about age 18. That was when I was at the peak of Mount Stupid. Everything went downhill after that.
On a related note, I have worked alongside experts in many fields and it has always been the case that the more eminent they were, the more clearly they could explain aspects of their field to a lay person.
Anyone who claims expertise but cannot explain simply and clearly is therefore, I conclude, bluffing.
And if you ever want a yardstick about how much you do actually know about a subject, just try teaching it to someone else and gauge how my information they actually gain on the subject.
From personal experience of watching others attempting this test, the quickest indicator is whether the "expert" welcomes the questions and challenges from the trainees, or they loathe them.
I figured this one out while I was at school.
Do you remember how struggling teachers with a class full of people failing to understand a word they are saying would typically pick on a "random kid" who was clearly not paying attention and bark something along the lines of "If you think you understand it, why don't you come up here and explain it?"
I assume you're not meant to do what the teacher asks in such situations? But something something autism and being a good boy and helping out the teacher etc... not once did they thank me for showing them the correct way to explain it.
No, they don't. I'd been in a 4th grade class for super bored kids that taught us how to read hieroglyphics, how lasers worked and pre-calculus. Fantastic program.
5th grade math class, proto-algebra stuff. I was doodling in a notebook.
Teacher: You! If you're drawing, you must already know this, huh?
Me: Yes.
Teacher: So you can finish this solution? You think you can do this?
Me: I know the answer is 14, but you won't get 14 because you failed to cancel terms correctly on step 2, so you're going to get 21.
Teacher was very mad, told the principal I somehow cheated or something-something. I handed the math book to the principal and said pick a math problem, any chapter. He grabbed something from the back, I factored it and found all the intercepts..
Principal and teacher have a noisy discussion while I wait outside.
I wound up doing the last chapter's assignments in the office over two weeks, then was a library aid that period the rest of the semester,
My GCSE maths teacher was stupid enough to directly accuse me of cheating on homework in front of the entire class, because I never show my working and therefore must be copying the answers from someone else. He then set the class to work in silence and called me up to his desk to assign me extra homework questions that I won't be able to copy from someone else.
I made a point of loudly saying the answer as soon as he wrote the = symbol. The third question he embarrassed himself by checking with a calculator before telling me to sit down...
Of course this was probably less surprising to the students in the class, who were aware that I was literally the only person who didn't attend their group homework sessions.
Great, except for the whole point of maths homework is to see that you can do the working correctly, so the teacher knows that you can answer any similar question rather than just the given ones. If you didn't show your working you've not done what's asked. Anyone with a calculator can find the answer, that's really not impressive.
"Principal and teacher have a noisy discussion while I wait outside."
Moral - don't pick a fight where you might wind up getting your ass handed to you. The teacher thought they were superior due to being the teacher, but the smart-ass kids spotted a mistake. A better tactic would be for the teacher to say they made the mistake on purpose to see who was paying attention. Face saved.
Until recently, I was in a flat-share with someone who works in sales support for a fairly large IT services house. For a year - all the time I knew them - they worked from home three days a week. On most of these days someone from the office called them shortly after 9am to make sure they were awake and ready for work. On several occasions I heard their phone ring and ring because they obviously slept through this 'alarm call'.
I suspect they were some kind of product or client specialist and this skill obviously made them so very useful to the business that their work ethic was accepted but it must have been thoroughly demoralising for the rest of their team.
Anonymous for an obvious reason
Used to be a worker drone on a contracted production line. Kinda specialist work but hated every minute of it (medical device cleanroom manufacture for a separate client).
Generally the team of 20 I was in tended to cover for each other as our line mangler - let's call him Mike - was useless to the levels of not knowing production quantities.
Mike "What are those others doing setting up a batch too?"
Worker Drone #7 "Mike, we do three batches a week."
Mike "Since when?"
Worker Drone #7 "Oh for about six months now"
The majority of the guys and girls I worked with were fine, but one guy - same age as me so definitely old enough to know better - used to spend his work day trying to get in the pants of the three women we had working there, and expected everyone else to cover for his work. This started within his first week...It turned out that the boss had recruited him, and was clearly ignoring all these issues as we had a £1,000 bounty if someone stayed for six months!
Evidently said mangler was happy to piss everyone else off just for personal gain of a grand. Saving grace was that our director hated his guts, and he got made redundant along with the rest of us when the client ran out of money.
shame he couldnt get a competent person to earn him the 1k
Depends if the 1k is for finding someone with the rare skills and attitude needed , or as i suspect in this case the 1k is a reward for finding someone prepared to be treated like an overworked cog in machine.
I guess if the latter the bounty is a sign the job is to be avoided.
There's the opposite of this. We had some young lady briefly attached to our team. She was some sort of high-flier being rotated from team to team. Pleasant enough person for a high flier but with no skills relevant to us. I had to invent some sort of task for her. Fortunately she moved on after a few weeks to fly higher elsewhere - I think possibly because her husband relocated elsewhere but frankly I never found out why she was even employed in the business for the few months she was there.
Related to someone higher up and they were trying to find somewhere she might eventually fit in? One place I worked at, the owners son ended up in various roles, rarely for more than a few months at a time. I think he ended up as a stores assistant eventually since he didn't really "fit" anywhere and that was probably the least dangerous place for him :-)
My previous line manager was an idle sod who made massive mistakes not because he wasn't competent but because he was too lazy to do the job properly. I was given a poison chalice project (think has to be done within a set timeframe and is production critical) where - let's call him "M" handed me details of the project plus a cost spreadsheet. (as you might guess from my name I'm a chemical engineer by training) with the words "I've done all the work for you, all you have to do is get it built".
Sitting down with my oppo mechanical and electrical engineers we went through the design and it became obvious that it wasn't going to work. Not only was it not going to work but the cost spreadsheet was out by 20% of the total project cost just for electrical and instruments (missed out the requirements for additional PLC I/O cards, new rack, new electrical panels etc.)
I was called in by the Works Director to explain what had gone wrong and was greeted by "don't worry, I know whose fault this is, just tell me how M cocked it up this badly".
M was later caught asleep at his desk by the same Works Director and ended up as the only manager reporting to another manager (an effective demotion).
I later came across him working as a contract engineer at another company.
Round about 1986, right after lunch on a Monday, HR deposited a freshly-scrubbed college graduate into my lap. It came complete with suit and tie, and the cleanest, shiniest shoes I've ever seen. Immaculately turned out. Not a hair out of place, and perfect fingernails. Looked like an advert for the suit manufacturer. The body was expected, the "shiny" wasn't. I was hoping for someone with experience.
However, beggars can't be choosers, so I set him to work pulling out Token Ring and replacing it with Ethernet in the stockroom and shipping/receiving. Both cables and cards. Under floors, over ceilings, wherever necessary. (Many of y'all have been there, you know the drill ...).
He came in with the suit bright and early the next day, still an advert, but the shoes were a trifle worse for the wear. As were the fingernails. That afternoon he managed to get his tie caught in a power supply fan ...
Day three, he was in Levis, a T-shirt and sneakers like the rest of us. We didn't mention the change of costume, but he mentioned it during his first review ... He thought I had been hazing him with the cabling work. Never did convince him that no, really, that was the next thing on our agenda ... I also never told him he'd have been transferred (or let go, if HR couldn't find a place to shunt him to) if he didn't wise up in a hurry. My group was there to get things done, not to sit around and look pretty.
well y'know nine out of ten times turning up in jeans and t shirt would get you sacked
You could have explained the no suit policy on day1 . Most people would be delighted.
I've had to work in places where the dirty cabling under desks and in ceilings drill has to be done in shirt and tie
In a past job, my nominal task was to set print layout for bulk printing using a custom "programming language" (I use quotes there, because this "language" had conditional statements that couldn't handle more than two or three chained conditions, such as "if this AND that OR the other", and other such very poor design decisions). However, a significant part of the actual work involved having to walk down the other end of the corridor from our nice clean office to the print room to run off proofs. This meant operating a continuous reel-fed printer that runs at 440 feet of paper per minute. In a shirt and tie. Management's advice? "Tuck your tie in". I'm still astounded that there were no nasty accidents at that place.
And carry a spare or two for when the inevitable happens.
For similar although far less dangerous reasons, it's why when we switched from clip on ID badges to lanyards, I complained about the likely hazards. I was told the lanyards decision was from on high and may not be questioned, and anyway, the clips are designed to come apart if they get caught in things. So I just carried on with my clip on badge, the new card fitted nicely. Then one day someone's badge did get caught up. The lanyard wearer was fine, but the £10000 machine was down for a day while it was fixed and cleaned of the badge and lanyard fragments. I didn't say a word!
Had a contract to set up S/W on my client's client site. My client specified suit. It was the middle of a heat wave (yes, in England; it happens). So there I am on the client's client site in a suit getting baggier by the second talking to client's client's manager overdressed in T-shirt, shorts & sandals. Just as well most of my time I could get into the machine room. It would have been a happier gig if my client's team had been able to provide better written S/W.
I turned down a job offer in '92 because they expected me to wear sport jacket and tie, though I was assured you could take off the jacket and leave it on your chair back when you got into the office, and then put it back on when you left for the day.
The real reason I didn't accept it was that I was going to install the OS on new HP-UX systems. Not unbox, not install the application. Not rack them. Just. Install. The. OS.
Which sounded like hell to me because it came on tape to be installed once you booted the base installer from CDROM or BIOS? Can't bother to remember how the described it. But it sounded like hell on earth. I got into IT because I could get my hands into all kinds of interesting nooks and crannies.
The jacket/tie was just the icing on the cake of 'nope!'
One job I had as a tech consultant was to visit customers with a salesman, sometimes for a presentation, other times just to ensure my colleague didn't say anything we couldn't deliver. I was quickly told off by the sales guys for wearing business outfits. Don't go as so far as shorts and sandals, but look like a technical person, not like us idiots wearing suits.
Was like that when I worked for a Stockbrokers in the late 90s, early noughties. It was expected that we would wear suit, shirt and tie in the office. After wearing the knees out of 2-3 pairs of suit trousers, I asked the boss why we, as IT, had to wear business shirts and ties ( where the shirts would end up with toner on them and the ties ran the risk of being caught in fans) when we were never in the public eye.
He being the awesome boss he was, went to management and explained that IT from now on would be wearing polo shirts with the company logo. From that day on, we were the trendsetters in the office when it came to men's clothing.
"well y'know nine out of ten times turning up in jeans and t shirt would get you sacked
You could have explained the no suit policy on day1 . Most people would be delighted."
I would take note of how others in a department were dressed when interviewing. If I wasn't taken round to where I might be working, I'd think that there would be a further interview or I had flunked out at the first one. The last thing I wanted to have was a job where a shirt, tie and slacks were expected and entirely inappropriate for the work being done. Pretty clothes often don't wear well and are expensive. The sort of things I've done have been business casual at the most and often jeans/t-shirt. Very occasionally, if we were attending an event, it would be suit/tie or button-down shirt w/sport jacket. It wouldn't do to be meeting the director of NASA in the garb we'd wear on the test range and sporting a mohawk.
Our team were short staffed, and were lent someone who's dad was high up. He had an expensive car - and a mobile phone the size of a suitcase (it never rang) . He was competent, but relaxed. He was told "install this system". At lunch time the boss came in to the open plan area and asked how things were going. Our visitor said "we'll I've drawn up a plan, and I'm thinking of starting on the install tomorrow". The boss said .. we were expecting it all to be finished today. To his credit the guy stayed late and completed it. By the end of the week, the guy was firing on all cylinders. He said he had never worked so hard - but wow, he had learned so much! He had been in an area which was tightly controlled, and you needed special permissions to do things. With us, it was get it installed, there is a new version next week. He said he learned more in two weeks with us - than 2 years in his previous job.
""What's your day-to-day dress code" is one of the questions I ask at job interviews."
I've heard it said, but it should be emphasized that an interview is a bidirectional thing. You need to be interviewing them at the same time to make sure YOU want to work there, or just be forewarned of what to expect if you need to take any job offered to keep living indoors.
Incompetency exists within any demographic, so I’m not sure what the relevance of “greybeard” was here.
This is a recruitment and management problem.
IT recruitment in big organisations is terminally broken, due to the ongoing insistence on using the kind of “testing” that is easily gamed by the unscrupulous, rather than the simple interviewing techniques that are still used very successfully in other domains.
It’s a management problem because far too many managers are focused on both politics and motion rather than delivery. A proper team lead can pick up on a lack of productivity fairly quickly, with no need for another team member to report it.
Should be a bit careful here as great engineers rarely make good managers. Seems likely the rest of the story was the older fellow was probably going to get rif-ed anyway... And this a way to do that.
The OP will eventually be on the chopping block one day too. And he'll get the axe too.
IT recruitment in big organisations is terminally broken ...
Indeed ...
But not only IT recruitment.
I have seen quite a bit of that in my field of work which is not in any way IT related.
But just wait till this nouveau AI crap takes over all recruitment, not just CV sifting.
.
This post has been deleted by its author
I worked for a short while in a very old fashioned corporate bureaucracy type place where this sort of attitude was common - there was a mix of young developers with up to date skills and lazy middle aged timeservers who'd been there 20 years or more and had learnt how to get away with doing nothing but fill up their days by turning every miniscule problem into a "major crisis" necessitating endless meetings. On top was a layer of even older timeserving management who everyone knew did even less work, which meant they were never going to tackle the culture as they'd be the first out of the door if they did.
The solution in this case was me deciding to leave, as the company was an obvious basket case, coasting on an ancient business model which brought in a regular income that let everybody there grow lazy and comfortable. The dotcom boom arrived shortly after, putting them rapidly out of business (and me very much in demand).
Used to work with a lazy older American guy who wasn't interested in learning how the next generation version of our software worked. He also had a habit of over sharing, and copying external parties in on emails inappropriately (he'd have fit in perfectly in the current US administration).
Guy was a massive pain in the ass but somehow got away with phoning it in because he knew how the older version of software worked and someone decided it was easier to keep him around dealing with issues on the legacy version while we were getting people upgraded onto the next-gen version.
Towards the end of the migration, a 3rd party was having an issue with integration with the next-gen version, and needed logs sending over to them to help troubleshoot. The old guy (who had been trained on all this stuff) turned on trace logging on production on that customer's instance, then dumped all the logs for an hour or so and sent them in an unencrypted zip file to an email audience of about 20 or so, including the 3rd party, a couple of customers, another third party, and a government agency representative. This is very much not what he'd been trained to do.
The logs contained personal data including dates of birth, names, and passport numbers for hundreds of people that the system had processed while the trace logs were on. The third party with the integration issue had no need for any of that data, nor did anyone else on the mail trail.
Earlier that week we'd all had to do an updated internal training module covering data classification and GDPR.
I asked the guy's boss if he'd completed that training module - and he had. So I forwarded his email (with the zip file removed, naturally, with a note that they could come and look at the original in my inbox) to both compliance and HR's inbox.
He was fired the same day. Incompetent lazy moron finally got what was coming to him. If he'd not screwed up in such an obvious manner, he'd probably have got a redundancy payout within the next few months, but he couldn't even manage that.
I felt zero guilt - the guy had been massively overpaid for doing squat for years, while other team members were putting real hard shifts in and getting scant reward for it. He was already drawing a pension from an earlier job too, and owned a load of property outright, so it wasn't like we dumped him on the breadline.
Stop me if I've told this one before ;-)
I was working in a team of Perl developers and was asked to review the first change made by a new contractor. It didn't work. At all. Somehow the guy had managed to write Perl code which not only didn't do the right thing, but didn't even compile! And he confidently submitted it for review without mentioning that he'd had any trouble with it. Two days later he was gone.
Perl source is compiled into an internal structure which is then optimised before being run (see here for more details). This happens every time rather than doing it once to produce a separate executable, which makes it look like an interpreted language. Producing a standalone executable is difficult at least in part because of the presence of the eval function.
Most interpreted languages are hybrids that compile to a bytecode and then interpret that. Thus, it can be completely accurate to say that Perl or Python or various other languages didn't compile. It couldn't make it to the part where the first expression is actually executed. If it did start executing, but then failed out, that would be a different level of problem, and possibly more acceptable, although if that was expression number 3, probably not much better.
Any object-oriented language is "interpreted" by some definition. It's why "exceptions" come with "object oriented". There is a meta-process which handles dynamic code redirection for objects, and a meta-process that handles dynamic code redirection for exceptions.
Not unless you're being very broad by your definition. Object orientation does not require exceptions. They do often come together, but there is no requirement to do it. Nor do either objects or exceptions require interpretation the way it's generally used; a different process which must be present in order to execute the program.
What you appear to be going for, assuming I understand you, is the runtime which directs program flow when an exception occurs, considering that an interpreter. It isn't what most people call an interpreter. I don't think it counts at all; it's completely static and can be implemented as a very basic stack climber. On that basis, something with functions that maintain a call stack is interpreted, since that is also implemented by the runtime and is about as complex.
Most people regard Java as OO, exceptions are key to that (indeed methods must define any exceptions they throw - which may seem a pain but focuses the mind on where abouts particular exceptions should be handled within the method & where they should be "rippled up" higher. Also means no nasty surprises as you know if a method should throw an exception (unlike e.g. OO C# where you do not have to define if (or what exceptions) are thrown from a given method so often a PITA with C# to know precisely where try - catch may be needed (if not rippling up exception)
“Here, write a routine to report a value stored in a data file.”
There’s enough vagueness there to drive an 18-wheel tractor trailer through!
You could probably solve it in 5 minutes flat, but then they start describing the constraints your routine needs to work within. So you accommodate those, then they add another heap of constraints.
Sure, as a manager I can give somebody the run around so hard, I can easily squander a full week of effort while ensuring zero accomplishment. What does that prove, other than hostile management?
Actually that describes my last job. They wanted a little robot device to crawl up a rope and accomplish a particular task. The issue was the junior team developed a hydraulic solution that “should work,” but the farther out it got the heavier its deployed tether became, until it got so heavy the hydraulic drive motor literally stalled. The solution made it out 75% the distance needed.
My task: “invent a better machine that actually works, and also works 2x as fast, but you have to use only the parts already bought, and it can’t cost anything because the entire $50,000 budget is already gone.”
Even despite the onerous constraints there still exist possibilities for creative solutions, but on the other hand, management no longer wants a solution: just a scapegoat. You can never get anywhere if management thwarts your every move. As it so happened, the firing decision came 4 days past the 90 day probationary period, and I took my wrongful dismissal complaint directly to small claims court. I know for a fact that their tardiness cost them a good $25,000 more, both for my settlement plus their expensive legal representation who convinced them that fighting was futile.
The little line crawler bot? Never got delivered. So I’m pretty sure the original fee got refunded in shame…
Indeed, if there is a fixed format of file and filename and that isn't likely to ever change, and it is possible to isolate the value within the file easily because it is where you expect it and in the format is fixed.
But try and create something that can cope with ambiguity and change in the input then it becomes a more interesting task.
The version from the article is indeed vague, but if we assume the storyteller wasn't just making it up, the problem with its constraints was solvable in two hours. We can assume hostile management only as easily as we can assume anything else that the story does not require, such as the older colleague being unable to complete the project because their computer was shutting down every three minutes but they didn't report it. I think the vagueness probably comes from it being boring to try to include enough details in the article; we don't want to read about the structure of the file and whether they already had reader code for it and exactly how the value retrieved had to be reported.
I've also dealt with the moving goalposts problem in completing a task, either because the people who created the task couldn't be bothered to write down all the information they had or didn't know something important when they wrote it. It's caused most of the worst preventable problems I've dealt with.
I've also dealt with the moving goalposts problem in completing a task
Are there any other kind? I don't think I've ever encountered them on anything more complicated than a 25 line applet.
I've done many file parsers and I would hope in the case described there was a selection of sample files provided, without those you are pretty much screwed.
was really useless, everything we gave to him would be a horrible screw-up, to the point any time our manager would give something to him, at one point, we'd go to the mgr and tell him "no, that's ok, we're gonna do this ourselves". Because of the horror of some night/week-end breaking horrible time when his screw-ups would break.
After some years, we came to the conclusion the behaviour was actually deliberate, to slow down the flow of work for him.
It worked very well, until we got rid of him in "favor" of a bigger organization.
I suppose I've retired twice on account of manglement.
The first was one of those occasional [de]motivations courses to which corporates fall prey but on steroids. AFAICS it was essentially run to motivate two very senior manglers by spending their days having their egos stroked by pontificating from a large platform to a large hall of underlings, the whole being MCed by a TV presenter who had the grace to appear slightly embarrassed by his part in the proceedings. I'm afraid I doubly failed, first to suspend disbelief and secondly to conceal disgust and it was the latter that didn't get unnoticed. I was offered a good retirement package and went on to spend another decade freelancing.
The second was on my last, quite long-running freelance gig. They offered me the permie job of development manage or some such title, probably not realising how close I was to their mandatory retirement age, not that I was interested anyway. Eventually they recruited someone chronically unable to make a decision. The last straw came for me when he spent the day before he was going to go on holiday vacillating about allocating tasks. By the end of the afternoon he'd finally come to a set of decisions - until a message in the evening that he'd changed his mind again and reallocated stuff. I decided that this was something up with which I could no longer put. I phoned in next day off sick with stress and announced that once my work on the main project was finished I'd be retiring and closing my business. As so often seems to be the case in these stories, I believe he left not long after and the business itself went a while after that.
Like it or not IT is one of those industries where "older = more experienced" doesn't always add up and frankly a bad solution is a bad solution no matter who comes up with it. We shouldn't ever think that we work in a place where we start off being apprenticed and at the end of that we get given the rank of master and that's it - we're all (or we flipping well should be) on the path to learning for life - there's always something new to learn and there's always more than one way to process the feline. If a young 'un is telling you there's a better way to do things maybe there is, maybe there isn't but it's worth having a look just to be sure.
Stay curious.
I worked with a guy on a C# project. When I was pairing with him on an issue, I noticed he was copy/pasting the | character for the or statements. When I queried, he turned out he didn't know where | was on the keyboard. He'd been working in C# for several years at that point. I was genuinely left speechless. I think he lasted 3 days past that point.
um... I'm familiar with US English, UK English, French, Latin American Spanish, and German keyboard layouts. It's usually perfectly clear where the | key hangs out. (Okay, so it might take a bit of searching to find it on some German and Latin American Spanish keyboards, made by, of course, Dell. Kill it with fire and get a real keyboard. I hate Dell, and Dell keyboards aren't even a major reason.) What language was that keyboard? And how long had m'man been using the keyboard?
Err... the tilde has been option-n on Mac keyboards since 1984. Most Mac keyboards also have it up on the upper left, but not all by any means. All of them show the tilde as option-n. The tilde, various accents, the umlaut, and others are burned into my muscle memory by over 40 years of hitting option-something. And there's a keyboard viewer available on the menubar to show you exactly which keys are used for what. It's the last remaining item from the original Mac Control Panels.
That's the dumbest reason for firing I've seen, if any, if this guy's performance was otherwise good.
If at my previous jobs we'd have had to fire all the little ladies that still used Caps Lock to enter an uppercase character when they typed their password, instead of using Shift, we'd have had to refresh half the company.
This guy could have been incompetent just as much as he could have been superstitious, or preferring some weird keyboard layout that would have made switching to a different one to get to it just as long, or could be he just was genuinely refusing to admit that anyone would put a " | " character look like a " : " on steroids on the keyboard. I know I am.
If he was using the extra three seconds it takes to copy/paste for thinking on the problem, he was just as efficient as anybody else.
Not a coder, but if I was I'd avoid any place where this would be a fireable offence.
The tabs vs spaces Silicon Valley episode was at least funny. This here is not.
Soon after I finished my post-grad training and working for real with proper customers on solving Technical problems with our machinery, we were 'given' an older guy who had worked away from the factory for years and needed somewhere to eke out his time before retiring. At first I resented having an extra person in the department where I was junior but had far more technical knowledge than the new/old guy.
He was just brilliant. Without a single complaint, he undertook all the mundane tasks, took calls and made understandable notes, and was very good with those 'irritable' customers. When he did retire after a few months, he was sorely missed.
Cheers Peter --->
I'll go against current here, and submit that I know neither Aidan nor the elderly dev, so I don't see how I can join the bandwagon on applauding for some guy being pushed out.
The elderly dev was obviously unqualified for that specific job, but there's little background on what his main strengths were, and what he was doing for the company prior. Zero input on how he got there.
I am not questioning Aidan's position that said guy was unqualified for the job at hand, but I know little of how the company evolved to get to that project in the first place, what that guy was doing previously, and how much he contributed to the company getting where it was.
Could be he was God's perfect idiot, or that he was a tired horse that had to be shot, and management knew to send him to the one area where bullets were flying.
I have been in a similar situation, and while I genuinely wasn't qualified for the things that were requested from me when company directions changed, I also genuinely saw little assistance from the guys in my team, who were neighbors and pals since first grade, following each other at different companies, completing each other's sentences and genuinely functioning as one (very smart and very competent) two-brained worker. Great guys one way or the other, but my career path took a nice bat hit.
Not everyone has the brains or graciousness to admit lack of knowledge in a professional environment, so - too bad for that guy publicly confronting Aidan and digging himself deeper, but the simple fact that he got tangentially centrifuged the next day is indication that he was set for that from the very beginning.
Don't pay attention, could be this type of story doesn't click well with the visions of 19 years-old college dropouts screaming and yelling at career public servants and firing them by the thousands I've been seeing these last months. Carry on.
I think I recognise this story.... I was there
The old guy was a senior grade and had a reputation for doing little work, spending most of his time chatting.
He thought he was an expert designer and coder, and expected people to look up to him for his wisdom. Because of head count limitations the manager could not hire an additional person.
The manager set him right on all of the above which was rather a shock to the employee, but the evidence was irrefutable.
I'm guessing the manager said "deliver at your grade" or else, and the employee took the easy route.
really comfortable with this sort of thing.
Its not really the job of of <insert domain expert here> to critic and point out the deficiences of fellow employees, because once you get a reputation of doing that, your fellows will look at you with an air of distrust and suspicion.
Ok the guy was older and being a bit of dunderhead, but surely you could of helped point him in the right direction.
After all, my PFY sometimes says "why dont we do it this way?" to me, with a resulting argument about who's in charge, and a final response of "f you old git I'm doing it this way anyway"
I've taught her well
Icon... because that who I am now
It shouldn't be the job of team members to identify when a colleague is holding everyone back. That should be the manager's job. If the manager is not doing that and the team is being held back, then maybe you take on that job anyway. And if it turns out that one person is repeatedly trying to do that to others, the suspicion from their colleagues and management will be real and justified. It generally isn't the job of an average programmer to coach their colleagues either, but we do it when needed because it makes the team run better.
From the sound of the story, the colleague who wasn't completing the task wouldn't have accepted being pointed in a different direction, even assuming that their problem was lack of knowledge rather than not caring or choosing to do something different. Of course, this is if we accept the facts alleged in the article, but if we don't, we could make up many different scenarios and point blame at almost anyone involved.
"We quickly learned he had been passed to us because he wasn't very good,"
I left a job after my contract wasn't renewed and the programmer who replaced me was incompetent. It turned out his former manager just wanted to get rid of him. I quickly got a new contract just down the hill. About once a week for a few months afterwards, my old manager would call and ask me to fix things. During my lunch hour, I would run up, make the changes then run back down. The sysadmin kept having fits as I wasn't supposed to be in the building let alone on their computer system but there was nothing he could do.
I worked "with" someone many yours ago who purpotedly did the same job I did. I knew he did nothing all day, but the IT director thought he was the dogs bollix because he'd come out with these suggestions during meetings, which he had gleaned from his web browsing and which did not suit our environment, or would actually cost a lot to implement and would not add any substantive benefits but sounded cool.
My coworker was oin holidays once when I bumped into the director who said that I must be really busy at the moment. My reply was an immediate "No, why would I be?". Not vindictively, you understand, it was just an automatic reaction to somebody who was working by themselves maintaining the admin aspects of a medium sized data center by themselves. It was the only time I saw the director look at me with unasked questions because he knew it was a normal reaction to his question and I had no ulterior motive for reacting the way I did.
Despite some colleagues trying to get the director to see what was in front of his eyes, nothing changed, so I left, whereupon they realized that my job was not one that they could reasonably expect one person to do by themselves, (they eventually had to hire four people to replace me).
And my browsing coworker? Apparently about 2 months after I left, the IT director, still thinking he was brilliant, asked him to handle a specific project, a.k.a. work, on a subject the director knew well. And after 2 months of absolutely no progress, only excuses and suggestions on how to do it better, which the director knew was BS, the director finally realised he knew absolutely nothing, and he was promptly fired.
The interesting thing was that the director was an extremely intelligent person yet, not only could he not see the waste of space in front of him, he actually thought he was fantastic.
I think arguably this counts two ways, or not: "Aidan" designs a simple task which Graybeard is expected to turn into a minor disaster, and then Graybeard delivers exactly that. But I think the first part doesn't quite count after all, because if the job was given to anyone else in the team, then it would be done satisfactorily.
Yup, same here.
But - side note - when one submits a story and it gets published chewed up, rehashed last-year's Ai style, with major elements taken off and with the punch line of the story published in the actual title - it gives food for thought on whether to bring more in :-D
So - maybe we're looking at the result of some less than abundant supply.
