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.
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.
"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.
"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.
"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?"
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...
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!
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.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 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.
> 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.
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.
Read his code on GitHub for an extra giggle.
That's mean and cheap, which means it breaks the HN guidelines. Same for https://news.ycombinator.com/item?id=10874432.
No matter how wrong you think the OP is, these comments are worse and don't belong here. Please don't post any more like them.