Don't be an architecture hipster

"Hasn't won any coding competitions"

I can't think of a single thing that has less to do with actual delivery of software & is more likely to indicate some level of supposed "hipster-ism" than thinking coding competitions matter.

I clicked through to the article that "ultimately annoyed" the author -- I found it to be a pretty decent, high-level discussion of architecture patterns in the real-world (N-tier, monolith, microservices, event driven, etc). The names may indeed be "25-cent word for a 1-cent idea" but they also allow people to put a shared name to a concept. In reality, very few systems follow a strict set of patterns 100% of the time, but having a shared vocabulary is useful for communication.

The friction between "architecture astronauts" and in-the-trenches engineers is nothing new. I think the author has identified the age-old struggles of dealing with Big Design Up Front UML diagrams, overbearing adherence to named patterns, and the disconnect between design and implementation that can happen in any project that has more than one person.

I would challenge the author to spend time trying to build up the community rather than tearing down others. Help clarify the "unintuitive names for very simple ideas", be open to new ideas but think critically and share your thoughts. Coming up with a new way to categorize someone as a poser or misguided does neither.

(Aside, you may want to consider removing the gendered pronouns from your lists -- there are women engineers and architects of all skill levels. I'm sure there was no malice, but it's worth writing in a way that makes everyone feel included.)

This part:

"Know-it-all / hipster Probably studied philosophy, english, film-studies, or engineering."

should cause us to remember this:

https://en.wikipedia.org/wiki/Ad_hominem

"An ad hominem... is an attack on an argument made by attacking the character, motive, or other attribute of the person making the argument, rather than attacking the argument directly"

We should remember, when we see an argument that starts with such a lazy use of a stereotype, there is a good chance that we are looking at a bad argument.

> Gets very emotionally attached to programming decisions, even if they will have no effect on the user.

Well, yeah? A lot of decisions affect the programmers — how easy will the code be to manage, extend, etc. Just because it has no effect on the user directly doesn't mean it isn't important.

> Isn’t actually very capable creating software (hasn’t won any coding competitions, has trouble with git reset, hasn’t written any software that people enjoy using)

Coding competition wins are a prereq for being capable?

> Probably studied philosophy, english, film-studies, or engineering.

This is absurd.

You're throwing out the good with the bad here. REST, microservices, SOLID, being passionate about the quality of the work are all good things. That they're presented poorly, or being overused where they're not needed is a separate issue, but that doesn't make the points of those things less correct.

Frankly, the original article[1] that seems to be the source of this rant didn't seem well written, but this is hardly constructive criticism of it. The original comment[2] from the author of this post (mentioned in the post, but not linked, unfortunately) was better, and while I feel some of the pain lamented (people assigning terms to ideas so simple they're better expressed directly; inscrutable UML diagrams), this post simply seeks to brand those people with a form of ad hominem rather than engage in debate with them.

[1]: http://www.firatatagun.com/blog/2016/01/09/analysis-of-softw...

[2]: https://news.ycombinator.com/item?id=10872314

There is very little in this article that has anything to do with doing architecture at all. This is all polemical griping about implementation—and that's developer territory.

Also, the initial dismissal about studying philosophy, English, film studies, or engineering—what the fuck does that have to do with anything at all related to software architecture? Sets an instant tone that what follows will likely be flimsy ad hominem arguments based on subjective shit the author personally dislikes. Useless.

This is a lazy blog post, and I hope this isn't used as a launching point for further discussion. The article in question is many times more substantive, and alexandercrohde rebuts with a caricature and no facts to anchor upon.

I'd also say that when people say things I don't understand in a domain that I'm interested in, that's normally a sign that there's a gap in my knowledge. Of course people bullshit competency, but I doubt it's through verbiage alone. Almost all the time, when I later go back to read what people were talking about, I come to understand that they were not bullshitters. In my experience, people who can talk in a complicated way without knowing what they're talking about are exceedingly rare. There are a lot of smart and knowledgeable people all over, and it seems almost impossible to hide behind complicated speech, hoping nobody knows that you're ignorant.

People might have a mean attitude of "Either you keep up with the lingo of the field or don't", but that doesn't mean they're bullshitting. And it's better to use an established "25 cent" word than your own idiosyncratic "1 cent" word. I mean, how else is that person going to Google or later verify what you're saying?

    Loves UML making diagrams

Four years of university desperately tried to convince me that UML is 90% of real world coding. I'll remain happy to not see this be the case.

From an architecture standpoint I'd agree that most of the author's points are lamentable - if indeed there are people that call themselves architects who exhibit those traits.

But I'd also say that several aren't really valid criticisms - (class vs functions, tail-call optimization, trouble with git reset, ...) as they don't really seem to be aspects/tasks that I would expect from an architect.

They look more like things that overblown software developers might do.

And on that last point "written software that people enjoy using" - I don't think that is a good qualification for being an architect. There are plenty of people who can write software that end users love - but that is a total shitshow behind the browser.

Ehhh, OP's characterization of hipster seems a bit off.

> He may be likened to Dwight Shrute, or the comic-book guy.

OP's characterization sounds more reminiscent of the pedantic 'nerd' than of the 'hipster.' Take most hipster fads of the past decade -- trucker hats in the early 2000s, vinyl records, hand cranked burr coffee grinders, people dressed as lumberjacks and park rangers in Bed Stuy, 24 year olds dressed like your grandma in Portland -- and the key characteristic is the fetishization of a noble, yet obscure and disenfranchised past, a poetic revelry in faux poverty. This seems a bit off from the typical 'comic-book guy' stereotype.

Expressing scorn towards people who didn't major in your field of choice: also pretty 'hipster,' I guess.

fighting hipsterism with hipsterism.

Modifying Peguy: It will never be known what development fads have been adopted out of the fear of looking insufficiently progressive.

Not quite related but right now I'm dealing with an infrastructure architect that a) refuses to document things because of some misguided sense that this will buy him job security and b) constantly chases the latest shiny tech without regard to how it fits into the overall system or ongoing maintenance and support. Frustrating to say the very least.

Can we please stop calling people who disagree with us "hipsters"? No one's disagreeing with you ironically.

Wow. Impressive that the author is able to compress so much negativity and lazy thinking into that space. The attributes of an "architecture hipster" are an assortment of unrelated things that presumably annoyed the author at some point in the industry.

Read his code on GitHub for an extra giggle.