• (nodebb)

    Yeah, 99% of the times a project is not in trouble because of it's developers. In fact from my experience 99% of code wasn't bad because the developers were bad, they often just didn't get the resources (or didn't actually stand up for quality) to deliver acceptable quality. Sure, we here often see code from developers who should have picked another profession, like becoming a politician, but in general the root of the problem is actually not to be found at the bottom of the pizza delivery chain.

  • Tim Ward (unregistered)

    An alternative approach might have been to say "I can add as many new features as you like so long as they don't have to work".

    Which is not completely stupid, actually - we all know that customers request new features and then never try to use them.

  • (nodebb)

    This story registers a lot with me, because I've seen it frequently for years. There's always some bozo like "Steve" who thinks the only thing that matters is features, and fixing a stinking codebase to facilitate having new features is useless. They also end up running away any sane developer, so all the company ends up having left are the scum of the earth, the absolute dregs of shit programmers who don't know how to write tests or refactor (and are unwilling to learn) so it grows worse and worse.

    Seriously, fuck people like Steve. They have ruined so many companies and gotten so many good devs fired or hounded until they quit. They deserve the lowest circle of Hell.

  • Pabz (unregistered)

    Is this the same Steve as featured in this story: https://thedailywtf.com/articles/Six-Weeks-Steve ?

  • (nodebb)

    Assuming the project and/or customer is actually important, the real WTF here is upper management for not looking into why the project is always such a disaster.

    The first round would probably be Steve saying he needs better developers, so upper management puts the best developers on the project. When that doesn't work, they should talk to the developers about it, at which point they would discover the real problem.

  • (nodebb)

    When did Remy 2.0 appear?

  • Steve (unregistered) in reply to Dragnslcr

    haha - TRWTF is upper management.

  • (author) in reply to colejohnson66

    At the risk of being my own source of spam, I got new headshots from Ensemble Actors Studio in Pittsburgh.

    It's nice to have something that's made in this decade and also doesn't look like clinical depression in JPG form.

  • (nodebb) in reply to Remy Porter

    Mods, we got someone posting off topic stuff here. Plus how does he dare to not use a 20 year old picture of himself like I do? :-)

  • Wim ten Brink (github)

    I had a manager like Steve. I just stepped higher up to the CEO, explained the situation, explained how the manager 'Steve' was just making things worse, and in the end, 'Steve' got demoted and another developer got promoted to manage the project. And things improved a lot after that. And as 'Steve' got demoted, the CEO decided to check up his CV again to see why 'Steve' was supposed to be qualified for the job. And this time, the CEO contacted a few references 'Steve' had given. And those references were either non-existent or gave horrible reviews. As for the training 'Steve' had followed... Well, he never finished them, and it turned out he had lied about a lot on his CV. 'Steve' got fired the next day.

  • Argle (unregistered) in reply to Wim ten Brink

    As for the training 'Steve' had followed... Well, he never finished them, and it turned out he had lied about a lot on his CV. 'Steve' got fired the next day.

    I left the small contracting firm I worked for to join a big company last January. I still stay in touch with the other senior programmer at the old company. Since I left, I've been replaced twice. One guy lasted 3 days. The other, only 1. Both lied about abilities on their resume. "Don't they realize that someone is going to check their skills after being hired?" lamented my former co-worker. "No, dude. Candidates get away with this far too often," I replied.

  • see sharp (unregistered)

    We might imagine it all started with a product owner pressuring the development team to deliver on an unrealistic schedule, and developers incurring code debt in an attempt to meet deadlines. Pressure from the product owner never relents so the code debt starts to build on itself, impeding developer's ability to meet future milestones in a self-reinforcing cycle. The "Rudolphs" of the world come in to shop firmly believing they can do the needed reset until they come face to face with their "Steve". Until or unless "Steve" is replaced or has an epiphany, all that a "Rudolph" can do is make a quick escape and let his successor take their turn.

  • (nodebb)

    I'm yet another of those hobos finding this to resonate with my experiences. I've lost at least one job for testing. First time I was talking about them in about I think 2005 the answer was "If you are unsure what your job is about, here's the door".

  • Dr, Pepper (unregistered)

    Development is a three-legged stool: quality, features, time to delivery. Choose any two. Clearly, this company has gone all-in on features and time, and quality takes a very distant third. The sad thing is that managers don't understand that as time goes on, neglecting quality leads to less features and more time to delivery.

    There may be some justification in the beginning to get a product out the door, so that the company can actually pay the bills; but in the end, without that quality leg, you can't have a stool.

  • BCS (unregistered)

    The real WTF is that the narrator didn't seem to make any effort to tell upper management what needs to be done to fix the project; fire Steve.

  • (author) in reply to MaxiTB

    Right? (mine is only 8 years old). I still look almost exactly like this, though. The horns cover the hairline.

  • summerlin (unregistered)

    "Clear and concise README files are the backbone of any successful project! They not only guide users but also help developers understand the purpose and setup quickly. Thanks for emphasizing the importance of a well-structured README—it's often overlooked but so essential."

  • westhouston (unregistered)

    “Great to see a README file—such an essential part of documentation! It’s always helpful to have a clear and concise overview of the project or content. Looking forward to diving into the details and learning more about what’s included!”

  • (nodebb) in reply to BCS

    You assume they would have listened instead of giving some cock-and-bull response like "Steve has been with the company for 15 years, and he's a friend of the CIO. We trust him completely. now get back to work peon"

  • Argle (unregistered) in reply to Dr, Pepper

    Your analogy is a little off. Development is NOT a three legged stool. I think the saying you're looking for is "done quickly, done cheaply, done reliably; choose any two." Any manager/company who thinks they can have all three is living in a fantasy world. If you'd like to keep the stool analogy, then admit one of the legs must be one of expensive, late, unreliable... and you'd best not choose the last one.

  • (nodebb)

    For the purpose of this quarter's management bonuses, "late" has the most adverse impact, "expensive" the next most adverse, and "unreliable" matters not at all. QED.

  • Chris O (unregistered)

    I've worked for a couple of 'Steves' in the past. There are times when going over Steve's head can get a lot accomplished, especially if you are a known entity in the company, but when Steve is a member of the upper management 'old boys club' then the problem will never be Steve's fault. Those are the companies that you have to run from.

  • pif (unregistered)

    OK, I'll bite! In the long term, Steve is the problem. But, right now, Rudolph is the real WTF!

    When you are called to a fire, you do all you can to put it out as soon as possible. If you need features to calm the effing down, you work on new features now, with the code you have.

    Once the situation gets a bit more manageable, then (and only then) you talk with management about structural problems.

  • Neveranull (unregistered)

    We need to add the new feature for this sprint. There’ll be plenty of time to add the tests and update the documentation later.

  • (nodebb)

    Rudolf bit back a "well, actually," while Steve ranted.

    "So you're the one responsible I lost three days trying to build this thing!?", would have been the correct answer. If you just let yourself being talked over, you'll lose every time. Don't be Milton (https://www.youtube.com/watch?v=Vsayg_S4pJg). Better yet would have been to raise the issue of the outdated README at the second day latest, then the product owner would have been the one having to come up with a justification.

    It's sad but true: communication trumps expertise. If you complain about your incompetent managers but don't understand this, you don't deserve better.

Leave a comment on “README”

Log In or post as a guest

Replying to comment #:

« Return to Article