[kovac]

That sounds complicated. Though I'm not sure if this is a valid example to counter my view. I can't comment on the exact situation you went through. It could be that that complexity was a side effect of having to solve far more complex and frequent issues more easily as opposed to doing simpler and rarer things more easily (unless of course changing button colours is a frequent modification). It's also possible that the design was simply bad.

This doesn't mean that you were going to better off without git workflows, code reviews, tests. My experience has been the opposite. It's exactly where there's no good technical leads/technical discussions/code reviews I have seen this kind of mess. Each person goes on and do their own thing with no clear direction or architecture.

At the end of the day, for me, to stay sane in the face of this kind of nonsense(as in bad engineers - unfortunately there are those even at senior positions), so what if the button that could have taken a few minutes to change now takes 6 days if we are paid to do it? As a responsible engineer, you point out the issue perhaps with a proposal for improvement. If they listen, good. If they don't, fuck it. On the other hand, if all I end up doing is changing colors of buttons regularly, each taking a week, then for the sake of my career, just say no and move on - unless of course if the pay is so good that it makes sense to spend a couple years doing it - people have to do far more shitty jobs for less. And spend some of the free time to code like a cowboy :)

[kristopolous]

No it wasn't!

That's the whole point. What some people consider to be "good engineering" is a different set of standards, a different set of qualifiers.

Let's go back to 2012. I was yet again doing web stuff.

We had this hodgepodge of jasmine, junit, eslint and selenium and couldn't commit unless it all passed

But the tests broke more then the code itself, because it was <far more complicated then the thing being tested>. So more time was spent on fixing and babysitting the tests then writing the damn software.

Alas, we finally released and it totally completely bombed. Why?

Because those test suites don't care if something "feels" clunky or "looks" wrong ...The machine responded to the interface in machine time, it didn't actually test human time, which was the only thing that mattered. We should have relied on human dogfooding, like the business books say to do. I got arrogantly laughed at for suggesting it, multiple times; that simply wasn't "engineering" to this team.

Now of course tests are valuable, sometimes. But "sometimes", that's the important thing. Understanding when to make that call is actually important. When, where, what, why, and how - not just important for journalists.

But instead, like some 18th century royal court disconnected from reality, we did ceremony. So we wrote tests, most of them bullshit. One of the tests was essentially: "Does this image on the page load from s3?"

At least that one usually passed.

Except when AWS was down or our internet went out: "I guess we can't work today, the does_image_load_from_s3 test is preventing the commit." They were a waste of time and got in the way of actual work. But we HAD to have them, we MUST, right? Nonsense.

I'm convinced the tests were there because "doing it right" was about virtue signaling. So we built a salary defending potempkin village composed of pure thought stuff.

I imagine it all like a catholic mass: Men in robes walk around, ring bells, and use special boxes to wash their hands with special cloths; it's all very important if you go to church, but that's the point, it's praxis and faith: we were coding from plato's cave, creating intricate shadows of reality representing actual work.

Symbols passing as tools: like Dumbo fetishizing the feather and being oh so worried when it falls, everything passed the most sophisticated testing I had ever seen yet the program still crashed in the user's hands almost every time. All that work was mere ceremony.

Understanding how modern computing speeds and vc capital has allowed people to be wrapped up in their own bullshit, call it programming and get away with it, is a major insight into why technology sucks today.

It's not just you, everyone agrees. It's lame now.

[kovac]

What's strange is I can also give you examples of how testing code bugs that had been there for more than 3 years (security related mind you) and a company whose release branch didn't compile on my day one because a guy who doesn't believe in any software development process and committed directly to the release branch.

I don't mean, dogmatically follow unit tests (actually my statement wasn't predicated on unit tests). If you have a better approach that can validate the software is correct then I'm all ears. If you have a better collaboration tool than git, I'd be happy to try it. With all due respect, what I can't do is take your word for it that you can build software that works (covers all functional and non functional specs), and they continue to work as more code is added, and is worked on by more than one or two developers, and that you can continue to validate and roll out more software over the years even when the original developers aren't around. It's difficult, costly. It can work, it's just not the best way. The industry will evolve and come up with better tools and processes than we have today as we did before yesterday. Only thing I took from the couple examples you gave is that you've had the misfortune of working in some terrible teams. Though I still don't see how you'd be better off without the rest of the usual practices we have today. The guys who couldn't code the tests, I can't imagine them building a non trivial software well either. I'm not defending any one process. I just don't agree that we don't need any process, and that we should just write code that (seems to) works.

[ratww]

The thing that the parent poster is trying to point out is that our fancy programmer tools, processes, ceremonies and tests are worse than useless if they get in the way of actual work and make you miserable and unproductive. People leave jobs because of this. People burn out because of this. Companies lose money because of lack of productivity.

This is what this whole thread is about.

If tests are "taking the fun away", like you said, they're shit. Simple as that. Tests are a productivity tool, they're supposed to make your job easier by providing faster feedback. If manual test is faster than automated test, your automated tests are shit. If they're causing developers to write the bare minimum of tests it will only generate a false sense of security. This is even worse than saying "ok we don't have tests, let's be careful and test manually".

It's like that stupid saying that bad documentation is "better than nothing". It's funny how people change their minds when they spend four hours or more on a stupid rabbit hole because of outdated documentation.

On the other hand, one of the best jobs I ever had was maintaining shitty web apps written without source control, tests, documentation, patterns. Thousands of lines of code. Some of them didn't even have source code: I had to decompile the production server DLLs. I don't have any coder friend that got burned out by "bad code". Not having autonomy to improve the bad code, on the other hand, made a lot of them change jobs.