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 thought a blog post about a hacker news discussion being submitted and voted up to the front page of hacker news was navel gazing; that last bullet point makes it an unintentional parody of our site culture. The void is staring at itself.
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.)
That would probably be closer to a "tech lead" but, of course, it all depends on how your team or organization is structured and what arbitrary titles you may use. Someone playing the architect role while staying acquainted to the codebase has been the most effective method in my experience. Finding the balance between looking ahead at future work and needs and working with the team is one of the most difficult aspects of being an effective architect -- but if you can strike that balance, you have the makings of a very productive and happy team.
"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.
"Self-taught all-around software-guy in his 20s. Just moved out to California. Passionate about software, psychology, self-sustaining systems, and business. Dabble in everything else (philosophy, go, reverse-engineering, painting, writing, chess, meditation, music, DVORAK). Preference for writing in fragments rather than sentences. ;)"
Obviously, philosophy is only worth attacking if you studied it formally.
I imagine software hipster-dom must be a bit like actual hipster-dom:
"lol, did you see that new hipster place with their freshly ground coffee/craft beers/ethical brunch/something gelato/ironic something."
"Yeah, totally. Bloody hipsters everywhere! Can't stand them..."
"..."
"..."
"Their brunch is pretty good though..."
"Yeah, well I mean everyone loves brunch..."
"And they've got this smokey larger thing which is totally the bomb!"
"I know! And they've got this crispy bacon thing you can get with the beer tasting menu...with references to my favourite internet/pop-culture thing in this delightfully subversive/kinda ironic way...like the thing I've got at home/on my desktop/on my desk"
"...We should totally check it out this weekend."
"Yeah...those hipsters though...can't stand em."
"I know. Bloody hipsters everywhere we go. What's up with that?"
I studied philosophy and as of right now I am self-taught. It's a bit insulting for someone to just suggest that I am a "hipster" who has pretentious opinions about software. I like coding and there are a lot of interesting parallels with philosophy, but I would in most cases defer to someone more knowledgable or experienced than myself.
> 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.
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.
"Self-taught all-around software-guy in his 20s. Just moved out to California. Passionate about software, psychology, self-sustaining systems, and business. Dabble in everything else (philosophy, go, reverse-engineering, painting, writing, chess, meditation, music, DVORAK). Preference for writing in fragments rather than sentences. ;)"
So, philosophy is only bad if you study it in school!
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?
Fine, UML probably isn't the fix, but maybe it would be helpful if developers were able to communicate via drawing a consistent set of objects and interactions without having to explain themselves at a simple level.
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.
I know that every time I have to use it (which isn't very often) I have to look up WTF each switch does in the manual because there's no way I'll ever remember what "hard", "soft", and "mixed" are supposed to mean.
In https://git-scm.com/blog, scroll down to "The Role of Reset" - it's always helped me remember how reset moves up the various tree roles.
I will say, I personally rarely use --soft, it's either the default --mixed, or --hard in a more 'severe' case, so it's a bit easier for me to remember the roles and the relation to the flags.
Well I know lots of great developers who haven't used git (but have been using version control systems for 30 years), so using a particular command of a single version control system as a qualification for whether someone can architect something is inane.
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.
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.
You could discuss how the lack of documentation is causing the team issues; maybe even frame it in a way to highlight how documentation will make him more useful (more time to spend on architecture vs answering questions, better chance that his architecture will be implemented as designed).
Express your concerns about introducing new technologies -- something that I've had some success with is asking 'which library/framework/dependency will we able to remove if we add this new one?'. Propose that the architect allocate time to training the team or being on pager duty or fixing maintenance bugs if they feel strongly that a new tech is the best decision.
If that doesn't work and the situation is unworkable, then consider a move.
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.
Have some stones and comment with a main account. His article resonates with many developers, that's why it's #1 on HN as of this comment. And throwing a personal attack because you stalked him online is pretty low and immediately telling.
Calling another poster a "stalker" for reading someone's code on github after that person condemns a lot of other people for being bad coders and asserts that they're better is totally bizarre. Are you the author of the original article?
I don't think Alex called anyone a "bad coder". He just seems to be calling a certain group of people (brogrammers?) out for being pretentious and ignorant.
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.