My company pays well. I'm remote. But sometimes I'm miserable. I expect too much from work and I need to learn not to.

They talk about how they want employees to be engaged, and they want developers to understand and solve business problems. They just don't mean any of it, and they don't know they don't mean it.

Anything you say about what we're building, why, or the process is wrong. Don't say it like this. Don't say it like that. Don't say it in the retro. Eventually I realized they're gaslighting me and probably don't even realize it.

There is no right way to say anything. There's no right time. The only way they're really happy is if you shut up and work your tickets.

I need to make my peace with that and collect my paycheck.

They're just so stupid. They don't see the disconnect between what they want and what they say they want. They can't be helped.

Thanks for listening.

My job is decent, but now I've got one developer who's been there a few months longer than me who pushes back on stuff that's considered standard, good practice.

We have a domain with lots of business rules. He's opposed to any sort of domain-centric architecture that puts business logic in one place. He doesn't give any coherent reasons. He can't describe his alternative clearly. He just wants to put stuff all over the place.

If I don't cite any references he says it's just my opinion. If I do, I'm talking down to him.

Then he decided that the database shouldn't have concurrency checks. His reasoning is that as the application grows we'll have more and more concurrent updates, and they all have to succeed.

What if that corrupts our data? He mentions "eventual consistency." which has nothing to do with what we're talking about.

The idea that our code should carefully ensure that our data is correct is "extreme." What are we going to tell people when bugs happen? That expecting the application to work correctly is extreme?

He's not a terrible developer. He's an advanced Expert Beginner. He's convinced himself that whatever he doesn't already know isn't worth knowing. That's fine if he wants to stop learning, but this affects the whole team. He makes such a fuss that it everyone gets stressed out and eventually I have to back off.

The problem is that someone with a reasonable degree of competence can pass off his experience as superior to all knowledge from outside sources.

I've been doing this as long as him. I don't claim to be a rock star genius, but I do keep learning. I don't tell myself that I've reached the pinnacle. But all of that learning goes to waste if I can't use it.

My eyes are opening to a sad reality. It's not just software - people in every industry are as bad at their work as they can get away with.

On the bright side it means that a person who excels at one thing has a shot at excelling at others. Mediocrity is everywhere.

They've literally left me with nothing to do. I'm doing nothing. I can't be happy doing nothing.

To illustrate the chaos: Everyone on the team was trying to figure out some defect. No one knows what is going on in the code. It's unlike anything I've ever seen.

I found an API call with a misspelled endpoint. It was wrong since the code was written two months before. There's no way it ever worked. Obviously no one tested the code because they would have immediately seen that the call returned a 404 every time.

I fixed it. That was my only PR in about a month. It was literally one character.

The next week that PR got reverted. Apparently the app works better if the API call fails. No one said what goes wrong if the request is made, just that it "causes problems."

That's how bad it is. No one knows why anything does or doesn't work. People write code that doesn't work, never test it, and the application works better in some unspecified way if that code never gets executed.

The last straw for me was when an architect told us that if we want to improve our skills we need to learn how to read and debug stuff like this.

1) Not to be immodest, but I'm good at figuring out bad code.
2) Just because I can doesn't mean I want to do it all day instead of actually developing software
3) He trivialized the really important skill, not making a mess like this in the first place. If his idea of skill is to sling crap without tests at the wall and then debug it, how is he an architect?

I tried really hard but I can't keep a good attitude. I don't want to become toxic, but why would I consider working that way? I try my best to be good at this. Writing decent code means a lot to me. It should mean a lot to them. Their code is costing them hundreds of thousands of dollars. Maybe millions.

I can't write good code and add value if all I do is debug bad code.

So I'm out. I'm going to another project. Have a nice life.

I'm working on a codebase that is terminally ill. It's split so badly into microservices that no matter what you do, every one of them talks to every one of them over and over. If there's any way they can avoid just invoking a method on a class and send themselves a message or make an HTTP request, they'll do it. One of the services just sends messages to itself for no apparent reason. Except it doesn't even send messages to itself. It sends an HTTP request to a controller in another app, and that controller sends a message which is received by the same class that made the request.

The point is that this application is screwed. The defects pile up and there is literally no one who can understand what it's supposed to do in any scenario. I'm good at this. I can follow confusing code and document it. But not this one. It's overwhelming. It's insanity.

When these defects come in we're told to just run the app from the UI, see what HTTP requests it makes, and start tracing the code manually. Running and debugging it locally would be a nightmare but it's impossible anyway.

They decided that we all need to understand the application better so we can work on it, so we were each given six poorly-define five-hour tasks to "understand" various things. Those things don't make any sense. It's like if someone gave you the source code to Excel and told you to spent five hours understanding columns, five more understanding rows, and five more understanding cells.

Here's the thing: I'm okay with learning and understanding some code. It's part of the job. But I'm not going to abandon my career as a software developer so I can become an expert on debugging their awful code. I didn't make this mess. I'm not going to live with it. I'm moving on as quickly as I possibly can.

I've tried to explain to them that if they want the situation to improve they need to improve the code. They need to learn how to write tests. If your plan is that people will study your code, know it inside and out, and then spend all their time debugging it, that's a plan for failure. Everyone who can will leave and take what they know with them.

These companies just don't get it. They need their software to work, but the types of developers who can help them don't need that software to work. No one capable of doing good work is going to spend several years debugging their awful code unless you pay them a crazy ton of money.

Just don't make a mess in the first place. Hire developers who can do a good job. If you hire the cheapest people you can find you won't be able to get someone else to fix it later. It's not personal but I wish failure on those projects or even those companies. I want them to fail because failure is so expensive. I want them to fail so that others learn from it and don't repeat the same mistakes.

As an industry we're a bunch of genuine idiots. We just keep doing the same things over and over again no matter how much it hurts.

I've got a decent developer job with decent people. It pays well enough. I work from home. There's a lot to be grateful for, and I am grateful. That being said...

I work for a consulting company with Agile in the name. It's the sort where they hire you and tell you that you'll work with an Agile team on exciting stuff and that they want to make sure you're learning and doing what interests you.

The reality is starting yet another engagement which is really just staff augmentation, joining another organization that's made a mess of what they're building. It works, but the code is all over the place. They've got tons of defects and work is slowing.

The idea is always that if we show them what great work we can do they'll let us do more. That sounds like an okay plan for the company but not so much for me.

My motivation is drained. I'm not going to fix your machine. I'm just going to become part of it. Show me what you want me to work on and I'll write the code. Then I'll spend several days trying to get a local environment to work so I can test what I did through the UI because you don't have enough tests. I'll spend more time debugging the environment than anything else. I won't really know if it works and it doesn't matter because without tests the next change someone commits will break it anyway. The next person can't manually test every scenario any more than I can.

While I'm doing this, someone somewhere is building the next application that I'll work on after they're done screwing it up.

If you're about to start building some new application, pretend it's done but it doesn't work very well, it's slow, it's buggy, and every new feature you want takes months. Pretend that you need to hire someone to fix it for you. And then hire them to build it for you in the first place.

I thought I found a place where I could work for 5-10 years. Maybe I have. Maybe when I explain (in the most positive way possible - this isn't how I normally talk) how utterly depressing this is they'll put me on something else.

Once I'm out of this depression I'll go back to trying to make this better for myself and everyone else. We can do better. It doesn't have to suck like this.

I'm out of my mind bored. I'm an unemployed person with a great job. You'd think this would be awesome. It's torture.

I work for a consulting company. I get paid whether or not they have work for me. They haven't for several months. I'm not hearing anything. I don't know when it will change.

I'm a skilled developer in a few very popular languages - nothing remotely in the ballpark of old or obsolete. I hear that's in demand. I spend most of my time answering questions on Stack Overflow. I really like to help people, but it boggles my mind that the people struggling with the stuff I help them with all have actual work to do and I don't.

I like to learn about new stuff, but I'm just not interested in learning another framework or anything else to add to the giant pile of stuff I'm already not using. It's not fun anymore.

I don't want to do another side project, either. I have a job as a software developer. That should, at some point, involve developing some software.

This is sucking the life out of me. It's harder and harder to get out of bed and come to work. I've held off looking for another job because I'm hoping this will change. The people here are great. I could go somewhere else and it could suck for completely different reasons.

Ironically, this is close to the reason why I left my last job. Ten years ago I went through a spell where I just gave up and stopped coming to work for over a month. No one noticed. Other people were stressed about getting laid off. Some of them were. Not me.

Am I part of some weird experiment to see how insane someone can go in this totally screwed-up circumstance? Are people following me around with cameras?

I'd love to find something else, but by all outward appearances I had already found an awesome place to work. There's only one thing missing - the work.

Thanks for listening. I'm just going to put my head on my desk for a while and despair. What is wrong with this industry? We're a mess on so many levels.

I had the most depressing realization last night after I spent a good chunk of the day answering questions on Stack Overflow.

I can usually understand their code, I often understand their questions, and I know how to help and when to recommend that they completely change direction. I'm effectively trying to mentor total strangers using a few code samples and paragraphs. I'm happy to do that, and I'm good at it.

Then I realized - these people all have programming challenges of their own to solve. I work for a so-called "consulting" agency where I sit around for weeks because they have nowhere to put me. When they do find me a client it's some company that has no idea how to develop software and no interest in how I can help. They just want to add another developer into the giant mess they've created to keep doing what they're already doing. I'm still using any of the skills I put to work all day long helping people on Stack Overflow.

In other words, the people who need my help figuring out how to write code actually have the jobs writing code, and I don't. Clearly I'm doing something wrong.

Ironically, when I go to one of these companies with a lead developer who doesn't know how to write a unit test or put together three lines of coherent code, that person tells me to just follow what everyone else is doing without making any improvements. Then he goes on Stack Overflow to figure out how to do his job, and chances are I'm the one answering his questions.

As my wife always reminds me, I work in air conditioning so I shouldn't complain. It's a stable company with nice people and it pays the bills. But I sure would like to develop some software in my software development job instead of treating it like a personal hobby.

I'm finishing up the most depressing client engagement ever. Ultimately it all traces back to their worthless Expert Beginner EA who thinks he's a genius but can't write code. I don't mean that he's not great at it. It's some of the worst I've ever seen by a person in his position.

In the time I have left here I could do so much to help them clean this stuff up so that future developers could ramp up more easily and there wouldn't be tons of duplicate code.

But I've just given up. You can't help someone who thinks their code is perfect. I don't even bother suggesting stuff any more (like don't have two methods in a class - a "real" one and one for unit testing) because he gets mad or just says that's his "pattern."

If I have a useful improvement, first he'll want me to put all new code in some new library, which is fine as an end result but you don't start with putting single-use code in a library separate from where you're using it. You work with it for a while to see what's useful, what's not, and make changes. But, you see, he just loves making more libraries and calling them "frameworks."

He tells me what he wants me to name classes, and they have nothing to do with what the classes do. When you haven't done any development yet you don't even know what classes you're going to create. You start with something but you refactor and rename. It takes a special breed of stupid to think that you start with a name.

I've even caught the dude taking classes I've committed and copying and pasting them into their own library - a library with one class.

The last time we had to figure out how to do something new I told everyone up front: Don't waste time trying to figure out how you want to solve the problem. Just ask the EA what he wants you to do. Because whatever you come up with, he's going to reject it and come up with something stupid that revolves around adding stuff to his genius framework. And whatever he says you're going to do. So just skip to that.

So that's the environment. We don't write software to meet requirements. We write it to add to the framework so that the EA can turn around and say how useful the framework is.

Except it's not. The overhead for new developers to learn how to navigate his copy-pasted code, tons of inheritance, dead methods, meaningless names, and useless wrappers around existing libraries is massive. Whatever you need to do you could do in a few hours without his framework. Or you can spend literally a month modifying his framework to do the same thing. And half the time his code collapses so that dozens of applications built on his framework go down at once.

I get frameworks. They can be useful, but only if they serve your needs, not the other way around.

I've spent months disciplining myself not to solve problems and not to use my skills.

Good luck to those of you who actually work there. I am deeply sad for the visa worker I'm handing this off to. He's a nice guy and smart. If he was stupid then he wouldn't mind dragging this anchor behind him like an ox pulling a plow. Knowing the difference just makes it harder.

The place where I work has a restroom on each floor with two urinals and two stalls. That's it. Sometimes one urinal or both have been out of order.

Then, in a stroke of pure evil, they renovated the restroom and put doors on the stalls that go all the way to the floor and swing shut by themselves. Universally the way we know if a stall is occupied is by whether the door is opened. It took days for people to even figure out that the stalls weren't really in use because no one would ever do something as stupid as making stall doors that swing shut.

So now you've got a few choices. You can knock on both doors. You can try to open them, which is risky because unless you jiggle the knobs a little bit the doors won't actually lock, so you could open the door and someone could be in there. Or you can go to another floor.

I didn't include looking under the door because the doors go almost to the floor.

What really ticks me off about this is that it's creating a problem that's already been solved since the beginning of time. The doors swing open. It's really simple. We figured this out a long time ago and moved on. Making the door swing shut is actually more work.

It's so obvious that someone who gets it wrong has to be either stupid or evil.

Here's a shorter version of my earlier question in case it was way too long and wordy. It's informal research.

Have you experienced a scenario in which you did not feel accountable (or felt less accountable) for the outcome of some development work you did because of bad decisions that were forced upon you?

I'm interested in any specifics, including how you felt about it. Or even just, "Yes, that's happened to me."

The key detail is that in this situation you felt the person who made the decision was or should be accountable, and that you were not accountable or less accountable.

Thanks

When Do You Stop Taking Responsibility?

Let me clarify by describing four scenarios in which you are tasked with some software development. It could be a large or small task. The fourth scenario is the one I'm interested in. The first three are just for contrast.

1. You either decide how to implement the requirements, or you're given directions or constraints you agree with. (If you hadn't been given those specific directions you probably would have done the same thing anyway.) **You feel accountable for the outcome**, such as whether it works correctly or is delivered on time. And, of course, the team feels collectively accountable. (We could call this the "happy path.")

2. You would prefer to do the work one way, but you're instructed to do it a different way, either by a manager, team lead, or team consensus. You disagree with the approach, but you're not a stubborn know-it-all. You understand that their way is valid, or you don't fully understand it but you trust that someone else does. You're probably going to learn something. **You feel accountable for the outcome** in a normal, non-blaming sort of way.

3. You're instructed to do something so horribly wrong that it's guaranteed to fail badly. You're in a position to refuse or push back, and you do.

4. You're given instructions that you know are bad, you raise your objections, and then you follow them anyway. It could be a really awful technical approach, use of copy-pasted code, the wrong tools, wrong library, no unit testing, or anything similar. The negative consequences you expect could include technical failure, technical debt, or significant delays. **You do not feel accountable for the outcome.** If it doesn't work, takes too long, or the users hate it, you expect the individual(s) who gave you instructions to take full responsibility. It's not that you want to point fingers, but you will if it comes to that.

---

That fourth scenario could provoke all sorts of reactions. I'm interested in it for what you might call research purposes.

The final outcome is irrelevant. If it failed, whether someone else ultimately took responsibility or you were blamed is irrelevant. That it is the opposite of team accountability is obvious and also irrelevant.

Here is the question (finally!)

Have you experienced scenario number four, in which you develop software (big as an application, small as a class or method) in a way you believe to be so incorrect that it will have consequences, because someone required you to do so, and you complied *with the expectation that they, not you, would be accountable for the outcome?*

Emphasis is not on the outcome or who was held accountable, but on whether you *felt* accountable when you developed the software.

If you just want to answer yes or no, or "yes, several times," that's great. If you'd like to describe the scenario with any amount of detail, that's great too. If it's something you'd rather not share publicly you can contact me privately - my profile name at gmail.com.

The point is not judgment. I'll go first. My answer is yes, I have experienced scenario #4. For example, I've been told to copy/paste/edit code which I know will be incomprehensible, unmaintainable, buggy, and give future developers nightmares. I've had to build features I know users will hate. Sometimes I've been wrong. I usually raised objections or shared concerns with the team. Sometimes the environment made that impractical. If the problems persisted I looked for other work. But the point is that sometimes I did what I was told, and I felt that if it went horribly wrong I could say, "Yes, I understand, but this was not my decision." *I did not feel accountable.*.

I plan on writing more about this, but I'd like to start by gathering some perspective and understanding beyond just my own experience.

Thanks

For obvious reasons, this question only applies if the person who cleans your office restrooms is of the opposite sex.

When the cleaning person knocks on the bathroom door and says, "Hello, housekeeping," what do they think is going to happen? Am I going to yell out from the stall into the hallway, "Taking a crap! Gimme 10!"

I'm not going to yell out anything, ever, not even "Occupied!" because *people can hear me.* I could flush the toilet, but what if I'm halfway through applying a seat cover at the moment and flushing it means having to start over (in addition to wasting both the water and the cover?) It's bad enough when I put down the seat cover and the toilet autoflushes before I can sit down.

Just discovered https://twitter.com/ExpertBeginner1. It's the story of my life. Giant classes, copying and pasting, and architects who create frameworks. It's great when we combine all three: A "framework" created by an architect which is made of giant classes that you copy and paste. Imagine a giant generic class where the generic argument is only used by dead code. Pause for a moment and try to visualize that.

It inherits from a base class with lots of virtual methods called by base methods that throw NotImplementedException, so if you don't need them you have to override them to return empty collections. If you're going to do something so messed up you could just put those default implementations in the base. But no, you can inherit, it compiles, and then it throws a runtime error unless you override methods the compiler doesn't require you to override.

The one method you're required to override has a TODO comment telling you what to put there. Except don't ever do what the comment says because that's the old standard. The new standard says never, ever do that.

Most of the time when I read about copy-and-paste coding it's about devs who copy and paste because they don't know how to write or reuse code. They don't mention the environments where copying and pasting the same classes over and over again is the requirement and you're not allowed to write your own code.

Creating base classes where you just override a method or two can potentially work, but only in the right scenarios and only if you do it right. If you're copying and pasting a class that inherits from the base class and consists entirely of repeated code, why the heck isn't that the base class? It could be a total mess, but at least it would be out of sight and each successive developer wouldn't become responsible for it by including it in their own code.

It's a temporary engagement, but I feel almost violated. I know it's a first-world problem, and I get to work indoors and take vacations. I'm grateful for those things.

Before leaving I had to document the entire process of copying and pasting an entire repo, making a ton of baseline edits that should just be in the template but aren't, and then copying and pasting from other places into the copied and pasted code. That makes me a collaborator. I apologize more than once in the documentation, all 20 pages of it that you have to read and follow before you even get to the part where you write the code for what you actually need it to do.

This architect has succeeded in making every single thing anyone does more about servicing the needs of his "framework" than about writing actual code to do what needs doing. Now that the framework is in and around everything it creates the illusion that it's a critical part of our operations. It's not. It's useless overhead.

Because management is deceived into thinking they need it they overlook the fact that it blows up, big and small, every single day. The log is full of failures that I know no one ever sees. A big chunk of what they think it does fails silently, and they don't even notice until months later when they realize how much data they're missing. But if they lose, say, 25% they'll never notice.

When they do notice they just act like it's normal, go into fire drill mode, and fix it. Doom. You're all doomed. I'm standing on the deck of the Titanic next to my jet ski.

I'm coming off a lengthy staff augmentation assignment awful enough that I feel like I need to be rehabilitated to convince myself that I even want to be a software developer.

They needed someone who does .NET. It turns out what they meant was someone to copy and paste massive amounts of code that their EA calls a "framework." Just copy and paste this entire repo, make a whole ton of tweaks that for whatever reason never make their way back into the "template," and then make a few edits for some specific functionality. And then repeat. And repeat. Over a dozen times.

The code is unbelievable. Everything is stacked into giant classes that inherit from each other. There's no dependency inversion. The classes have default constructors with a comment "for unit testing" and then the "real" code uses a different one.

It's full of projects, classes, and methods with weird names that don't do anything. The class and method names sound like they mean something but don't. So after a dozen times I tried to refactor, and the EA threw a hissy fit. Deleting dead code, reducing three levels of inheritance to a simple class, and renaming stuff to indicate what it does are all violations of "standards." I had to go back to the template and start over.

This guy actually recorded a video of himself giving developers instructions on how to copy and paste his awful code.

Then he randomly invents new "standards." A class that reads messages from a queue and processes them shouldn't process them anymore. It should read them and put them in another queue, and then we add more complication by reading from that queue. The reason? We might want to use the original queue for something else one day. I'm pretty sure rewriting working code to meet requirements no one has is as close as you can get to the opposite of Agile.

I fixed some major bugs during my refactor, and missed one the second time after I started over. So stuff actually broke in production because I took points off the board and "fixed" what worked to add back in dead code, variables that aren't used, etc.

In the process, I asked the EA how he wanted me to do this stuff, because I know that he makes up "standards" on the fly and whatever I do may or may not be what he was imagining. We had a tight deadline and I didn't really have time to guess, read his mind, get it wrong, and start over. So we scheduled an hour for him to show me what he wanted.

He said it would take fifteen minutes. He used the first fifteen insisting that he would not explain what he wanted, and besides he didn't remember how all of the code he wrote worked anyway so I would just have to spend more time studying his masterpiece and stepping through it in the debugger.

Being accountable to my team, I insisted that we needed to spend the scheduled hour on him actually explaining what he wanted. He started yelling and hung up. I had to explain to management that I could figure out how to make his "framework" work, but it would take longer and there was no guarantee that when it was done it would magically converge on whatever he was imagining. We totally blew that deadline.

When the .NET work was done, I got sucked into another part of the same project where they were writing massive 500 line SQL stored procedures that no one could understand. They would write a dozen before sending any to QA, then find out that there was a scenario or two not accounted for, and rewrite them all. And repeat. And repeat. Eventually it consisted of, one again, copying and pasting existing procedures into new ones.

At one point one dev asked me to help him test his procedure. I said sure, tell me the scenarios for which I needed to test. He didn't know. My question was the equivalent of asking, "Tell me what you think your code does," and he couldn't answer it. If the guy who wrote it doesn't know what it does right after he wrote it and you certainly can't tell by reading it, and there's dozens of these procedures, all the same but slightly different, how is anyone ever going to read them in a month or a year? What happens when someone needs to change them? What happens when someone finds another defect, and there are going to be a ton of them?

It's a nightmare. Why interview me with all sorts of questions about my dev skills if the plan is to have me copy and paste stuff and carefully avoid applying anything that I know?

The people are all nice except for their evil XEB (Xenophobe Expert Beginner) EA who has no business writing a line of code, ever, and certainly shouldn't be reviewing it.

I've tried to keep my sanity by answering stackoverflow questions once in a while and sometimes turning evil things I was forced to do into constructive blog posts to which I cannot link to preserve my anonymity. I feel like I've taken a six-month detour from software development to shovel crap. Never again. Lesson learned. Next time they're not interviewing me. I'm interviewing them. I'm a professional.