[kristopolous]

There's a subculture that's reinvented the merits of software engineering to being as ornate and ceremonious as possible.

It doesn't have to work well, or be bug free, or compatible with the previous version, or address any real world need.

No! Instead it has to use fashionable technology and be extremely complicated so other programmers can see how incredibly clever they are!

Almost like they took a random bug from the issue tracker by looking at last nights lotto numbers and then they opened to a random page of Knuth by letting a fan blow on the pages for 5 minutes and said "alright, I'll solve this problem in that way! Surely everyone will acknowledge my genius!"

It may be a slow lumbering buggy pile of brittle barely functional code about to implode, but boy does it look nice!

[kovac]

I don't agree with this view. I agree with the original commentor's comment. I do this myself outside of work just to enjoy building something without the responsibility of having to maintain it with 20 other engineers for two more decades.

However, even I can see that a team would get burnt if they built an enterprise software the way I code my personal email client. The problem here is that people forget that building software professionally is an engineering job. Like other forms of engineering, there are processes and good practices to facilitate both functional and non functional aspects of a software and the building process. While the extra burden of version control, testability and extendability takes some of the fun away, I would have reservations working with someone who pushes directly to a release branch, does not write test and hardcode values instead of uaing configuration. It's about balance and realising that job is a job.

[kristopolous]

ok, let's go back to 2014. I was working on a project, a web front end. The ticket was "change color of button". This sounded easy, modify the CSS.

However, the CSS was generated. From YAML. The YAML was generated from JSON. the JSON was pulled from mongo. The Mongo was updated through a strictly validated XSLT that had an enumeration of colors. Those colors did not include the button color we needed.

Don't worry! There was an ability to reroute the xml through the use of ruby mixins and then add the attribute by parsing the dom, editing it, then re-ingesting it later downstream so it gets out to mongo right.

oh and there's a cache layer at every point here. so make sure you invalidate it to see the change. every time.

I closed the ticket and did a few more like this for 6 weeks, mostly in ember - they were even crazier.

The product, an interface to some server software, had basic html with markup like this:

<ul class='links'>

<li><a href=/a>link</a></li>

</ul>

Like the most trivial stupidest simple code you can think of. 15 minutes of php, at most.

However, changing it to do something else was never direct. 4, 5, 6 maybe 7 different languages, servers, restrictions, databases, input and output formats ... absolute and total batshit.

I left. Company is worth over $100 million today, looks like I'm the loser I guess.

This isn't about having a dev and release branch, this is about endless layers of abstraction and insanity that make easy things 1,000 times harder and almost impossible.

[eeZah7Ux]

> However, the CSS was generated. From YAML. The YAML was generated from JSON. the JSON was pulled from mongo. The Mongo was updated through a strictly validated XSLT that had an enumeration of colors.

I thought you were exaggerating to make a joke. Sigh.

> I left. Company is worth over $100 million today, looks like I'm the loser I guess.

Somebody played the lottery and won. 99.9999% played and lost.

You are not a "loser" for not playing the lottery.

[kristopolous]

The idea was that if they were going to port native than wow, we'd have this one amazing way to create all these interfaces on different systems!

As if we'd have 5 or so platforms and a single command to go "presto!" and build on a bunch of devices with a slight button offset change.

I always said "how about, if you want a linux version in qt, you fire up qt creator, drag your mouse around a bit, click a few times, take 20 minutes and that's it. You then literally just walk away because the work is done".

[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.

[ohvirginia]

I love this. you nailed it. modern tech stack is so bullshit. I won't mention the framework I detest most because that would be flame bait, but this.

[eeZah7Ux]

> Instead it has to use fashionable technology and be extremely complicated so other programmers can see how incredibly clever they are!

You are describing "CV-driven development", where people want to use heavily marketed technology brands in their CV as a substitute for real skill and experience.

[muyuu]

Really well put. It's a combination of this phenomenon and a push for commoditising engineers/makers. Paradoxically it's based on "sound economics" - the clear advantage of commoditising "resources" and the clear advantage of anticipating a future stage (which in a massive asymmetry of information is what checkbox-investment appears to be addressing).