• Debra (unregistered)

    Am I right to understand that the "true/false midterm" is an exam in Boolean logic?

  • Tobi (unregistered) in reply to Debra

    I assume this is rather a series of questions like "Is it true that ..."

  • F tier programmer (unregistered)

    Well, at least this isn't one of those 'certifications' that is completely meaningless because no-one can ever fail!

    You do have to wonder how much this story is exaggerated - while management might not be able to tell the difference between a programmer and a faker, surely they can tell the difference between successful delivery and whatever this guy would be turning out.

  • akozakie (unregistered) in reply to F tier programmer

    As someone with well over a decade experience both in teaching at a university and managing an R&D team... I don't really see any obvious exaggeration here. Some people are just... yeah. Been there, seen that.

    My guess would be that he got funding for this class as a sort of last chance "get better or get packing" offer from his employer, but his ego didn't allow him to see that, making him think "jeez, if they really think that piece of paper is so necessary"... After all, he's far better than his management, peers or whatever the school has to offer, right? His panic at the end is real, as his self-illusion is beginning to break down. Seeing reality for the first time in a long time tends to hurt. A lot.

  • my name is missing (unregistered)

    During Dotcom my employer hired a "programmer" and assigned him to my team to work on a project. Turned out he had not even the faintest clue of programming, such as had difficultly understanding the concept for a variable or a loop. Since I had no option but to bill him to our customer, I did all of his work plus mine and sent him to lots and lots of training, none of which actually helped, but at least the customer got the work. To this day I have no idea how he was even hired (not related to anyone if you think that).

  • (nodebb) in reply to Debra

    Brilliant humor! Did Tobi miss the humor in your comment? T/F.

  • Old Fart (unregistered)

    I'm wondering if Manny is an example of the Dunning-Kruger Effect. That is, one of those clueless people who think they're in the top five percent and none of the lesser mortals are even qualified to judge their work. It seems that some of these people eventually move into a non-technical role where their incompetence cannot be easily judged, and then end up managing the rest of us. Or consulting. I've witnessed both.

  • Prime Mover (unregistered)

    After a particularly spectacular katabasis in the mid'90s I re-entered life as a lowly programmer at a company which at the time was an utter joy to work at. The salary wasn't the best, but my skills were (despite everything) still sharp, and the work was easy and refreshingly unchallenging.

    I was assigned a mentor (because I was new, this was de rigueur) who was a sweet young lady with whom I struck an appropriate personal rapport, and we got on well. The trouble was, she really, really, really did not know how to program, and she would continually be asking me how to do stuff.

    "I don't understand loops," she confided in me one time, "can you tell me how to write this bit?" And indeed, that I would do.

    The inverted nature of this arrangement was brought to light when the entire department had to undergo a competence test, one of whose tasks was to write -- on paper -- a tic-tac-toe program. I did not too badly on it, and my job title had "programmer" in it, while her own job title was downgraded to "business analyst". AFAIK she was never given to work on an actual program again.

  • Scott (unregistered) in reply to F tier programmer

    Don't think this has to be an exaggeration. I work with consultants who routinely:

    --hard-code values --can't follow method/parameter naming conventions --routinely fail to null-check (or empty-check) collections before using variables --etc, etc

    Unlike Manny, these people have apparently been in the business for decades.

    There's a saying I've found to be pretty true when evaluating software: "If they can't get the little things right, how can they ever get the big things right?"

  • BeenHereSeenThat (unregistered)

    One of the first things I realized as teacher is that your class of students will sort themselves out on the curve. No need on a assessment to do more than be straight-forward. No need to be obscure, nuanced, sneaky or tricky -- especially in this realm of programming-- those who know something will come out ahead of those who don't.

  • AnonDBA (unregistered) in reply to Prime Mover

    Last laugh goes to the 'mentor', as BAs typically make more than programmers in "business-oriented" management models.

  • Prime Mover (unregistered) in reply to AnonDBA

    Not at our place, at the time this happened. It was before the evolution of that particular layer of corporate bull. It was when Java was still barely newborn, and programming was still a revered craft.

  • Bruce W (unregistered)

    I was working at my first post-college job in the late 90s where my team oversaw deploying Windows 95 worldwide. I didn't want to be a programmer (I was good at programming; I just didn't want to do it as a job.) but I kept getting asked to write a quick utility in VB 5 or C++ because my team knew I would deliver.

    Another team hired a developer who needed some help. He just had graduated from Yale in Computer Science. He needed help getting going with a VB 5 project. I was asked to help him. He was clueless. I thought it was the language. I explained things in C terms. He still didn't get it. Maybe it was the IDE. Nope. I coded about the first 10% of the project for him to get him up to speed. He was slowly catching on. Luckily my boss needed me back so I didn't have to teach him programming.

    To this day I want to know 1) what they taught in Yale's CS program in the mid 90s, 2) how he graduated, and 3) how he was hired by my famously picky employer.

  • Hal (unregistered) in reply to akozakie

    My guess is similar but I suspect its probably more like this. He'd be supporting something someone else original wrote. Maybe he adds a this or that now and then that is very similar to what is already there. He's been getting away with tinkering for a week on hacked in copy/paste BS from the existing code base and stackoverflow and he occasionally delivers. He "knows" enough to read strait forward code and work the most basic features of the IDE. The quality of the code is utter crap but of course users can't see that. Bigger projects, the really are in fact that complex, are rejected as being to complex or costly or are simply never completed. Someone important in the organization like him so his supervisor can't just not renew is contract without first exposing him for the fraud he is.

    The reason I think this is because as an employer you don't generally pay for an "experienced" to "brush up on the basics" they should be expected to know the basics, you might do this for a very new and junior person but not someone you have had on staff for a long time. Sending someone to take 100/200 level courses over at the local CC just does not make sense unless its to help them get a full degree or something. No you'd send them to a bootcamp or similar to learn a new tech stack and gain currency.

  • Shipman (unregistered)

    "I don't understand why you failed me,"

    You don't ??? ??? ???

    Guess!

    ... ... uh-huh. uh-huh. uh-huh.

    Hey! Tell you what. I just sent you an email. I'll pass you right now if you click that link.

    You clicked it? <Hangup>

    Latter that day Manny was taken to a black site by the NSA.

  • MiserableOldGit (unregistered)

    This could be an anonymised version of something that happened at a place I was at for a few years and was, in retrospect, largely my own fault.

    We were short on coding resources and under a hiring freeze. I was also struggling with a person in one of the costing teams who kept "helping out" his colleagues by creating VBA macros in excel. These were, in the usual myriad ways, popping up as tickets for support and enhancement as they exceeded his abilities but at the same time had apparently morphed in to mission critical processes.

    We'd reached a point where we talking about trying to initiate disciplinary proceedings against him for causing some massive security and BC foul up with his antics when i suggested we should bring him in ... he clearly had taught himself a bit of coding, was interested, too intelligent for his team and bored, so why not? There were enough of us to manage and train him, and I had him signed up at a local college for a part-time course, quite well suited ... the basics of coding but not for techie noobs.

    The rest is pretty much as the article describes ... the epilogue being he managed to persuade management he should stay (I didn't recommend dismissal, but his survival probably had more to do with him having done the dirty with a director after an xmas party). He became impossible to manage, he had three of us around him by then who were perfectly capable and willing to help him, but he resented the fact his promotion from trainee had been stalled and refused to cooperate or share his work for review, went back to grabbing projects in secret to work on to score himself political points around the business. Things came to a head when his development contribution on a bigger project turned out to be a Brillant Paula Bean bit of noncode, he'd been lying about progress and submitting faked unit test results.

    He managed to save his ass from firing by cashing another chip. Moved to 1st line support :D

  • James (unregistered)

    Just speculating:

    1. what they taught in Yale's CS program in the mid 90s Math
    2. how he graduated, and Pay to play
    3. how he was hired by my famously picky employer. Yale
  • (nodebb) in reply to Scott

    --hard-code values --can't follow method/parameter naming conventions --routinely fail to null-check (or empty-check) collections before using variables --etc, etc

    I see this more often than not, and it no longer surprises me. What does continually surprise me is the incredible resistance to actually addressing these things. The attitude seems to be that anything over and above "make it work" is seen is useless time-wasting. This includes error logging, source control, and testing. You speak of method/parameter naming convention - I count myself fortunate when they bother to divide the program into functions at all.

  • MiserableOldGit (unregistered) in reply to Scott
    I work with consultants who routinely:

    --hard-code values --can't follow method/parameter naming conventions --routinely fail to null-check (or empty-check) collections before using variables --etc, etc

    A lot of that is future-proofing their revenue stream.

    Clients don't seem to mind paying a few days every year to have the highly paid expert fly in to change the hard-coded "variables" and clean the nulls out of the database. Especially if he remembers to take the right people to dinner/the races/local brothel during his visit.

    I've an ex-boss gold plated his retirement with that plan. If the cholesterol or syphilis don't get him before old age, the tax man should.

  • sizer99 (google)

    At least he made it really easy. 'Never turned in homework. Homework is 2/3 the grade.' is very clear cut when you're dealing with third parties, compared to someone arguing their B+ should be an A because REASONS.

  • Raj (unregistered) in reply to F tier programmer

    Thanks to the shift in priorities from productivity to diversity of the workforce, I've noticed a revival of the good old "programmer that can't program" syndrome.

    Because of lack of candidates, we used to hire anyone who would pass our technical quizz regardless of resume/diploma, now we're hiring anyone who tick the right boxes in the demographics questionnaire regardless of their ability to do the job.

    Deadlines are sliding and quality is worse than during the "outsource to lowest bidder" era but now we have really great team pictures and our biggest challenge in sprint plannings is to have at least one task for everyone to work on. One of the new UX designer had a single task last week, to enable transparency in the logo background, and it's probably gonna carry over to the next sprint.

    Welcome to 2020

  • Malcolm (unregistered)

    I had a friend who complained when he was doing a course that all the instructors were fools. His answers to a test were right and they had only given him partial credits. So I asked him some of the questions, they were very basic stuff. After the 3 question that I answered the way the instructors answered in the post test review. He gave up talking to me about it. I don't think that he every really accepted that he did not no best. Interestingly he kept failing the group project at the end of course and has never worked in IT.

    Very smart guy but all ways thinks he knows best

  • (nodebb) in reply to Bruce W

    While I don't know about the second two, my guess would be that Yale's CS course taught computer science.

    The university I went to was better at making the distinction clear. Computer science was taught in the Science school right next to the mathematics department that had spawned it; at the time it was one of the top places in the world for research in formal language theory. On the other hand, if you wanted to actually build software then you'd go across the road to the Engineering school and study software engineering.

    That said, even in CS you were expected to be able to muddle your way through programming tasks in order to prove your points about things like algorithm design and analysis. Where you learned enough C to do that was up to you, but here are some more senior students who are willing to provide tuition.

  • David Mårtensson (unregistered) in reply to Prime Mover

    On the other hand, if she truly could do analysis and a good job at that, she most definitely would earn her pay :)

    Just because someone cannot program does not mean they cannot help programmers.

  • gnasher729 (unregistered) in reply to Old Fart

    Remember that most people are affected by the Dunning-Kruger effect. There are the idiots, who are so incompetent that they cannot even realise they are incompetent. There are semi-competent people who know what they are lacking and think they are incompetent because of that. There are the competent to very competent, who are often surrounded by similar competent people and think they are only average.

    As Sherlock Holmes said: "As a kid I thought I was stupid, because my brother Mycroft was so much more clever than I was".

  • F tier programmer (unregistered) in reply to Watson

    I didn't know you could transmit transport emissions to eachother

    Yeah TRWTF in that comment is people who think that CS = development/engineering skill. It's like expecting a material scientist to be able to build you a bridge, or a biologist to be able to run a farm.

  • Canadian Academic (unregistered) in reply to Watson

    We have a Software Engineering professor who describes the difference between Software Engineering and Computer Science as being similar to the difference between Electrical Engineering and Physics. In that, originally, electrical engineering grew out of Physics but, in 2020, you would rarely consider a newly graduated Physics major to be also a fully qualified Electrical Engineer. No one would seriously argue that you don't need Physicists anymore just that they are not electrical engineers.

    He also makes it clear that being 'good at coding' does not automatically make you a software engineer. His analogy for this case is that while a good construction worker can make you a very nice garden shed, you would hire a structural engineer not a construction worker to design your skyscraper. In a similar fashion, you need a Software Engineer to work on the design of your large scale software system, not just a good coder. Obviously, you still need good coders to make large scale software just like creating a skyscraper will also require several good construction workers.

  • MiserableOldGit (unregistered)

    Coming from the building trade I do enjoy shit comparisons with my old industry. It's certainly stuffed full of WTFs, but it does have a better discipline of learning from mistakes. Well, sometimes, but sometimes money speaks louder than common sense.

    I am a qualified structural engineer, first class, with honours. I'd never hire me to design a skyscraper, that needs an appropriately qualified and experienced architect who would then, in turn, hire me to help them make their creation stand up. Well, not me, I'd turn that job down as I never did skyscrapers and wouldn't want to kill anyone.

    As for a good construction worker the same logic applies, I don't see any reason why a competent steel guy, or concrete guy would be any use at all building your garden shed compared to me, you or the architect. Other than them being stronger and fitter, natch. And I've seen plenty of friends prove that one by hiring competent "construction workers" who turned out to be incapable of doing basic things (like sheds, kitchens, bathrooms) without additional supervision.

    This is still the rubbish that means a developer can't walk through the building without people asking for help with a defective mouse or dodgy network connection, and within development, the basic failure to hire coders who can actually code.

  • (nodebb)

    I've seen plenty of friends prove that one by hiring competent "construction workers" who turned out to be incapable of doing basic things (like sheds, kitchens, bathrooms) without additional supervision.

    The pros are better at making a job profitable than the general public. That usually means they are faster, not necessarily better. Your average drywall finish guy can do a room at amazing speed... but his work will be far inferior to that of a reasonably capable homeowner who really cares about making it look nice. This assumes that the homeowner doesn't take dumb shortcuts like premixed compound.

  • (nodebb)

    We have a Software Engineering professor who describes the difference between Software Engineering and Computer Science as being similar to the difference between Electrical Engineering and Physics.

    Software Engineering barely exists. In other disciplines, the difference between an Engineer and someones that knows how to get things done is that the Engineer has a license on the line - so his judgement is given more weight. Some examples:

    Building code enforcers will let you do a one-off with a plan stamped by an Engineer Insurance companies are more likely to give you more coverage and/or a better rate if you have an Engineer assigned to a job

    In the software world, very few people will give any type of assurance that the software will actually work. I'll believe in the concept of a Software Engineer the day someone's license gets yanked over a security bug.

    BTW, I'm both a Mechanical Engineer and an IT Security Officer. One of these industries has their stuff together.

  • MiserableOldGit (unregistered) in reply to Jaime
    The pros are better at making a job profitable than the general public.

    Absolutely, my phrasing was a bit ambiguous. If you want a garden shed built hire a garden shed builder, don't assume that a structural steel fabricator will be any good at it just because he's also "a construction worker".

    It's even more specific than that. I've seen people get hired to do "private jobs" in their field of expertise and make a complete hash of it because, whilst they might have been a damn good builder of garden sheds, they failed to realise the contribution of the rest of the team in preparing the site, getting the right stuff there at the right time, double checking things.

    As a real world example that was particularly funny, I remember a friend getting a builder in to make him an en suite bathroom. This builder was a perfectly capable employee of a well known (and good) local firm. Friend/builder thought they'd help each other out by getting this little job done over 3 weekends and paying in cash ... ahem. Took months to get done, partly because every time he bought something it was wrong, whenever he got fellow artisan in (plumber, electrician) to do something he couldn't they had to tell him to change stuff so they could do their bit because he hadn't thought about where pipes and cables would run before positioning the equipment and tiling. I spoke to the builder a couple of times, he clearly thought people like designers, buyers and surveyors just "got in his way" on site. The punchline to this comic bathroom was that when it was finished, apart from leaking sewage from somewhere due to the botched plumbing, there wasn't room inside to get the door open to get out without standing on top of the toilet.

    In other words, pretty much identical to 90% of development projects, except my friend eventually got his bathroom sorted out, software gets deployed in that state and everyone lives with the smell and inconvenience.

  • (nodebb) in reply to MiserableOldGit

    In other words, pretty much identical to 90% of development projects, except my friend eventually got his bathroom sorted out, software gets deployed in that state and everyone lives with the smell and inconvenience.

    The difference between construction and software engineering is two-fold:

    1. It's much cheaper to build many copies of a piece of software than many identical buildings.
    2. It's much cheaper to change software after deployment.

    Those two things utterly change the economic model for software relative to construction (or most other engineering areas) and that drives the rest of it.

  • MiserableOldGit (unregistered)

    Well I'm not sure what this "construction engineeering" thing is that people refer to, having graduated as a civil/structural engineer and worked in that field for a number of years before deserting it for better paid endeavours. The engineering happens at the design phase, the construction phase is not engineering, although engineers are often present to deal with the fuck-ups, a bit like with software.

    Engineering is about the application of mathematical physics, which makes software design a dodgy member of the club, but I guess it can come in if the chemical engineers have been let in.

    Civil & structural engineering are about the design of solutions to building problems and, actually, it mostly involves identifying something recognisable and applying a pre-existing solution ... as should software "engineering", but as we know from this site, it usually involves re-inventing the wheel with a few more sides.

    And yes, it should be forgivable that software can be changed after deployment, actually buildings can too, but regardless, we put up with a lot of buggy software and iffy buildings.

    As I said, I know both industries, and I tire of the crap analogies.

Leave a comment on “Faking the Grade”

Log In or post as a guest

Replying to comment #:

« Return to Article