This sort of negativity is not just unhealthy, it can make it really difficult for beginners to figure out where to start and realize that it actually is okay to start pretty much anywhere. When I was learning how to code, every single day I would come across some new package or framework that was described as being revolutionary and awesome by the people who supported it while other similar stuff that I had been previously interested in was just basically shit on unequivocally. I don't personally know of any other field that does this sort of thing and it made it extremely difficult and negative before I realized how many people in tech are just full of hot air.
Hacker news is not immune from this behavior either. Nearly every day I read an article and I think "wow, that might be really cool if I ever have time for it" but then I read the comments section and 90% of the comments go out of the way to disagree with EVERYTHING that the author said. It can be really off-putting to be honest.
I have a hypothesis, but it's VERY silly. Programming, like many tasks created in the 20th century, is not nearly as physically demanding as traditional jobs. People who work behind a desk 24/7 feel emasculated and try to compensate by showing off their expertise through aggression. It's a game of dominance and frustration. Of course, this is totally unproven.
Programming expertise is very fragile. A variety of changes in your environment, such as different coding standards, dependencies, programming languages, etc, will cause a severe impact to your performance. The result is a strong negative reaction to things that should be objectively neutral.
That is, a change in your environment can make you feel incompetent, and it is easier to get angry at the change in the environment than it is to be honest with yourself about what is happening.
I forget which book I ran across this theory in, but it explains a variety of conflicts that repeatedly come up about formatting, libraries, programming languages, operating systems, and so on. Furthermore it is easy to experience the feeling yourself when you go from an environment where you're competent to a new one. (At the moment I'm going through this having to learn Eclipse and Java, after many years of being primarily a Perl dev.)
It's fragile, it's highly specialized, and it's overwhelmingly human-constructed. The fiddly bits have very little wedding in anything else, not even human-constructed hardware. If you're fussing in bits which don't impose their own forms of inertia, e.g., CLI tools whose arguments are exposed to shell scripts and hence, if changed tend to break a great many things which is Generally Not Recommended, then you can find that years or decades of expertise can be wiped out in a very brief time.
Unlearning is generally as hard as or harder than learning.
And there's a strong tendency to view the first system you learned as "the proper way" to do things. Sometimes it is, sometimes it isn't.
The transition you're going through in Perl => Java is a pretty good example. You happened into a skillset early in your career which was highly capable and offered ample opportunities, but its flower has faded. That's something that the kids today who're building up competency in various currently-popular toolsets might do well to consider. They're starting to see hints of that as tools such as RoR are fading. What happens when we, say, bin the entire present set of Web dev, will be interesting.
And it's happened to whole industries before. Sucked to graduate in nuclear engineering in 1979, or petroleum engineering in 1990.
I don't agree that programming expertise is fragile. There is a kernel of knowledge that transcends language and syntax, and that is by far the bigger part of "programming knowledge", much more important than knowing specific syntax and how to use certain tools. For more, see [1].
This doesn't mean you aren't correct. People may still be reacting negatively to change, because it does require work to learn new libraries, frameworks and languages. But that is not the same as saying that programming expertise is fragile.
I'm going to have to disagree with you, especially in relation to large frameworks.
I spend a lot of time working with medium to large ruby on rails applications. I know them very well and I am pretty good at doing things quickly and correctly. If I have to work on a php, python, or javascript project, it takes me one or two orders of magnitude longer to get things done than it would in a rails application.
The ability to start working with a new language after reading a blog is useful but it doesn't mean you'll be effective and useful in that language in a week.
A person with the ability to program, probably will have that raw ability in various languages. There is a knowledge core that is very transferable. An experienced programmer can come up to speed very quickly as concepts get mapped into things they already know. A polyglot will have been through this several times, and won't be afraid of the process.
But there is a great deal of knowledge that we use every day that is environment dependent. A programmer with 20 years of experience in various languages will not be noticeably better by day 5 in a new language than someone who has been programming for 2 months only, but in that language. A simple change can leave a programmer feeling incompetent.
Programmers who respond to this badly are not going to handle such transitions well. Furthermore if they get stuck in defensive behavior, then the initial discomfort will turn into permanent failure.
I never bothered memorizing stuff which is "fragile", e.g. browser quirks. Luckily, there's no shortage of programming knowledge that is the very opposite of fragile. Under a few common assumptions, sorting can't be done faster than O(n log n). All NFAs can be converted to DFAs. 2-SAT is polynomial but 3-SAT is NP-complete. And so on.
People who disdain math as "brain teasers" are deprived of the rush of knowing that some piece of your knowledge will stay true forever.
You can't get useful work done on real problems without learning a lot of that "fragile" stuff. How are things scheduled on your OS? Where do you find your logs? How do you run unit tests? What are your local coding standards? What is the library call for doing X? How do you find your documentation? What was that section of code you found foo in the other day?
All of this stuff is fragile. None of it is going to last. But it is context for your current life, and you're going to be more productive if you learn it. And when this stuff changes on you, you're going to feel the productivity drop. But there is no sense in hamstringing yourself so that you won't feel so bad later. You learn it now, and you learn the replacement later.
Back in the 1800s there was a belief that you could only learn so much, so you had to keep your brain clear for the important stuff. (Go read Sherlock Holmes for an example of this prejudice.) But these days we know better. People can practice learning. And those who do, constantly are learning. About everything. Including trivia. And it pays off. It really, really does.
If you go farther back, you'll find more negative opinions of Java like the one at http://www.perlmonks.org/?node_id=41244 that I stated 15 years ago. I believe that the substance of my complaints were true then. They are true of some organizations today. But they are not true of all of Java, hence my willingness to use Java today.
Eh, simple tribalism seems like a simpler answer to me. It's the reason Navy folks talk smack about Marines, Target shoppers look down on Walmart, Yankees fans bash the Red Sox, etc. — I don't see why it can't explain a React fan hating on Ember or whatever.
I think this is the right answer, it's pretty high level, and maybe more nuanced than "it's my tribe" because there's always infighting amongst the tribe, but it cuts to the chase, this whole attitude is endimic to the human condition.
Sometimes maturity cuts through it, but IME, sometimes it takes maturity and intelligence (though not a huge amount of it), and on the rare cases, there's something more, like a primal competitive nature.
I have an alternative, and potentially equally silly, hypothesis.
Many programmers are young and have just enough money, time, and knowledge to get into trouble.
This is compounded by the growth rate of the programming field. New, young, programmers jump into the industry every year. So, a young programmer can potentially encounter entire teams of equally young programmers, creating a school like atmosphere of aggression and dominance. (Which is sometimes taken advantage of by employers.)
As silly as your theory is, I have anecdotal support for it based on some of the places I worked at. The younger the crowd, the stronger the "new, assert technology X" superiority vibe is.
Where I work now, no one cares and I get questioned on using something that is less than 3 years old. xD
> The younger the crowd, the stronger the "new, assert technology X" superiority vibe is.
This could also be due to simple inexperience. The first time you come across something that seems amazing, it's easy to make the leap from "amazing" to "perfect" and become a zealot about it.
Then you live with the amazing thing for a while and discover that it actually has flaws that weren't obvious at first glance. Then you go through this cycle a few times and realize that everything has flaws, and that the art is learning how to identify the things whose flaws impact what you want to do the least, rather than being able to find the One Perfect Thing that solves every problem cleanly. And you come to value the tools that tell you their flaws and limitations up front over those that try to hide them behind blustery assertions of perfection.
But by the time you realize all that stuff, you're not young anymore :-D
My silly theory is that this is economically driven- why compete with senior devs in technology x, when you can choose new tech Y and be just as senior as everyone else to managers and recruiters?
I don't think it's related to the physical nature of it. I think it's just that it's a field that is infinitely faceted (so room for different perspectives and opinions) and one which many of us have a serious personal interest in. I.e., it's not JUST a job for many of us. I am one of those kids who has been a 'power' user since middle school. Now I'm a programmer. If I didn't do it for a living, I'd still do it.
So what that boils down to is I have opinions that are semi-personal. A lumber-jack or a secretary probably has much less personal investment in their field. Personal interests yield opinions, and where there are opinions there are people who are aggressive about them, whether it be music, religion, sports, cars, or technology.
This in one of my "i believe it, but can't prove it" ideas about the negativity in programming: Programmers tend to be very insecure about their intelligence. I think it has to do with how (at least in the us) skills in STEM fields aren't valued too highly until you get into college and beyond. If the damage is done early then it can be hard to back it out later in life, so a lot of programmers carry around some residual scars.
This isn't really true as far as I am aware. If you are getting this from the Robber's Cave Experiment(HPMOR), it was misrepresented there. They were only hostile after it was induced and they went back to being nice in the last stage too.
Everyone likes to feel special/superior. There are many ways to do this. Easy ways are money and power. If you are smart, you can win arguments.
If you aren't any of these things, you can be superior in other ways. You can feel morally superior to those 'millionaires and billionaires'. You can save the planet or the animals, which those others for all their money/power/specialness don't care as much about (or so you tell yourself).
You can become a shameless hedonist. Those corporate fuddy duddies would love this lifestyle, you see, but they are cowards even though they are rich, right?
In every case it's about being unique or on top of those things or making a mark that will last. Special. Valuable.
When we program it's from our heads. If anyone questions why we do something, it's as though they are questioning our intelligence, so the natural (for some people) reaction is to be defensive.
To elaborate with an example: when you pick a programming language or framework you presumably have other options which you don't take for whatever reason. The reasons for picking something over others don't need to be strong: its what I use at work, its what a friend uses are probably a lot more common than 'this programming paradigm is better'.
When someone else comes along and says you made the wrong choice, or even if they stop at just championing their own, different choice and therefore 'implying' you are wrong, its easy for individuals who might not have their self-awareness guards up to respond as if they were being personally attacked. Even if your original choice isn't something you, all being equal, don't really care that much about.
Here is my theory, which could serve as an addendum to yours: people who spend a lot of time interacting with machines, instead of people, tend to have an under-developed sense of empathy and similar social skills. Often times they don't realize or put a high value on how their negativity will affect those whose work they criticize. So you end up with a ton of hostility in the industry, not just towards new products and ideas but also between established "tribes."
At some point you got to wonder whether the practice of programming itself can make people unhappy. Maybe it's just not natural to put your mind into that straightjacket of formal thinking for 8+ hours a day.
I think Internet comments encourage this behavior but it has always existed and isn't unique to programmers. Just today I read a long reddit thread with military people arguing about aircraft.
I come from the training business. Where coaches, personal trainers and their followers like to praise their training methods and say other methods are not only stupid but can even hurt you.
The thing they do not understand though is that what works on one individual might not be the best for everyone. And that we are all different and the best approach is to tailor the tools for what suits the exercise and the individual.
Now when I'm into technology I see the exact thing and I'm just like face->palm. So I guess this exist in all fields.
My advice for someone new in the field is to listen to what the veterans say, try some stuff out. Then make up your own opinion and use the stuff that works best for You and the task at hand.
I am also from the training/teaching area too, and I must say that the people who denigrate other methods usually seem to be the worst trainers. Great trainers/teachers know exactly what you are talking about - what is the best way to teach this to these people? It depends...
Hacker news is famously home to the middlebrow dismissal (explained nicely by patio11 here: https://news.ycombinator.com/item?id=5072224). Trying to show off nerd machismo by crapping on everything.
"I don't personally know of any other field that does this sort of thing"
Filmmaking. I love my artform, but if you want an example of a culture where there are a lot of strong negative opinions about almost every potential methodology, it's definitely one.
One problem with front-end development at the moment is that there are such a ridiculously large number of ways of doing things, such an incredible rate of churn, that there is this sense that you have to say something to justify whatever choices you've made. Perhaps because the actual arguments for choosing, say, Webpack over Browserify really aren't very strong (perhaps both are great solutions to the same problem; perhaps neither are perfect solutions and will be superseded in another six months!), there is a tendency to resort to an emotional and dismissive argument, the so-called "smack talk" mentioned in this article.
Certainly it's frustrating for any front-end developer who has invested his time in learning Grunt only to find out he should now be using Gulp, or Broccoli, or make(1)...
There's nothing wrong with saying "I chose technology X over technology Y because they are basically the same, they each have small advantages in certain areas but nothing that will materially impact our success, and making any decision is better than making no decision."
I remember the last time there was this sort of fragmentation and polarization in the web framework world (2005-2007), I chose Python & Django over Ruby on Rails because, well, I liked it better (that and the RoR community had a certain evangelistic quality to it that turned me off, while Pythonistas are basically like "Yeah, it's a tool. I can build cool stuff with it. Let's move on and solve some problems"). I'll freely admit that it doesn't matter, Ruby is a fine language, and Rails is a fine framework. But they do largely the same thing, I've never once regretted my choice, and I've been able to build some pretty cool things with the energy that wasn't expended getting emotionally involved in language/framework/tool wars.
> There's nothing wrong with saying "I chose technology X over technology Y because they are basically the same, they each have small advantages in certain areas but nothing that will materially impact our success, and making any decision is better than making no decision."
Well, except that saying that X and Y are effectively the same is not a great method of getting booked to speak at conferences about X and write articles for sites dedicated to Y. It's the truth, of course, but if your main goals are self-promotion and/or demonstrating how smart you are, it's not going to help you much.
I don't see why "they're effectively the same, but I chose X and have been using it for Z years now, and I'm widely considered an expert" would be any different from...I don't know, denying that they're the same.
If anything, denying it would be evidence of ignorance, no?
Sigh. I had just about decided on using Browserify in my current projects (instead of Require.JS), and now I have to find out there's ANOTHER option... (Though looking at one comparison [1], I guess I'm sticking with Browserify moving forward.)
It does feel like information like this is siloed: Everyone talks about their own favorite solution, and few actually make intelligent comparisons. I didn't know about gulp until after I'd already set up grunt, for instance, and I don't really want to tell the team "now we're using gulp" after having selected grunt only two months ago. I hadn't even heard of Broccoli until just now, either. I obviously need a better JavaScript news feed.
That said, I don't feel a need to slam gulp or say grunt is great. But something that the article misses is that the kind of loud, rude argument that it describes is a basic, well-known psychological reaction to insecurity: The less self-confidence you have, the more you feel the need to be loud about your opinions. And I think a lot of JavaScript developers are insecure, based on the evidence.
Then you get aggressive opinionation about the projects, but really that's a secondary phenomenon.
One problem is there are no objective metrics for framework or language quality. I don't think anyone knows if objective metrics are even possible, never mind how they would work.
So you pretty much just make a choice that works for you and stay with it until something obviously much better comes along.
And if it doesn't - if it's obviously much different, but not so obviously better - you can still be getting useful work done.
The seductive promise is that Framework X will make the job take half as long and produce half the bugs.
I doubt that's ever true in practice, for general values of X, especially when you consider learning/retooling time.
Actually, the main reason I was feeling like I might want to switch from Grunt to Gulp was the extreme and measurable time difference between running the two. Honestly the "it's easier to set up!" arguments fall somewhat flat; it's not HARD to set up Grunt, and you don't need to do it often, so that stinks of "premature optimization." Broccoli seems to entirely be about how clean and tiny the configuration files are; not interesting, because that means it's actually harder to understand how to change them to do something the designers didn't expect. If it's even possible.
It does feel like each group has their own little fiefdom and they want you to use THEIR tool rather than a competitor. The Grunt main page says "THE JAVASCRIPT TASK RUNNER", as if there are no other options. As a new JavaScript developer, it made me think that was just the only option.
I am much more impressed with the integrity of open source projects that actively advertise the options -- especially when they cite advantages and disadvantages of the options. Actively misdirecting you to believe that there no options is pretty much the opposite of that philosophy.
> [...] there is this sense that you have to say something to justify whatever choices you've made.
Whenever I somehow get time to work on a new "weekend project", I go through that every time. I know better and should stick to the rivers and lakes that I'm used to, but when working with (often) sub-par code in my day job, I always have the itch of trying new shiny things.
After I get that out of my system, I often keep my own "standard" stack and force myself to just say "No" to the new tools that are not fit for the project. At that point, I've probably wasted the entire weekend playing around with tutorials and fiddles to see that going through the learning curve isn't worth the time.
You've basically described 99% of the PHP development community there too. When there are so many ways to do something, it fosters the worst kinds of pedants, who don't seem to understand that "using exactly the same syntax/libs/style that I use" isn't the same thing as writing good code. I've seen people over on reddit's /r/shittprogramming make posts about how someone used a 2-space indent instead of a 4-space indent, and _that_ got upvotes.
You read plenty of comments about always "write tests first" or 100% test coverage, ignoring the fact that many businesses don't have the resources, and just want something quickly. Even if it is a bit buggy, the something that works for 98% of the cases today is better than something that works for 100% of cases in two months time.
I stared filling in an application form the other day:
do you prefer
A) I prefer "standard" solutions because they work and are easier to implement and maintain.
B) I prefer to create from scratch because it fits better the needs and offers better performance.
Without a context this question is entirely pointless to me.
And I will be judged on it? There people obviously have their ideals and I am going to be judged on them. There is no "it depends" in the answers.
Yikes, that's bizarre. I don't even think the conclusions they draw are even correct: there are many solutions I build from scratch because they're easier to maintain. e.g. this morning I needed to fetch data from 3 APIs: google analytics, twitter, and soundcloud. I could have downloaded the PHP lib they bundled for each of them separately, read their docs, and pulled my data from those. Instead, I just looked up their API docs, found the endpoints I needed and fetched what I needed with libcurl. I think it's easier to implement and maintain 3 simple calls to curl than it is 3 different libraries. Conversely, there are many 'standard' solutions that perform quite well, e.g. underscore.js has many methods, such as its .each(), which often outperform their builtin counterpart.
Questions like that are like being asked if you prefer:
A) A backhoe, because it gets the job done faster.
B) A shovel, because you have finer control
without being told what it is that you're actually digging.
> I've seen people over on reddit's /r/shittprogramming make posts about how someone used a 2-space indent instead of a 4-space indent, and _that_ got upvotes.
absolutely not surprising given that there is even a pretty popular language with indent base syntax out there.
I agree. FE technologies are in and out of fashion faster than anything else, it seems. Dig in and hate away and then maybe your knowledge will get a slightly longer ROI.
The bad news is that what the author's seeing is only the tip of the Hating Game iceberg. Over here on the back end there has always been a lot of bonding through hate, and it reached toxic levels long ago. I've been on projects that were the target of unjustified hate from people who had never even installed or run it, or had any idea how it worked or was different from any alternative, just because that was The Meme. I've probably slung my share of snark myself. Mention Lustre to a Ceph fan, MongoDB to a Riak fan, Solaris to a Linux fan (or vice versa), and watch the sewer floodgates open. It's long since time we developers in all specialties tried to turn the corner on this issue.
I don't even understand how people can have this argument. I mean, how many people have actually invested enough time into both vi and emacs to meaningfully compare them? I doubt there are that many. Really, either one is a fine choice and will probably be able to handle all your coding needs, once it's customized to your liking.
Vi vs emacs isn't really comparable. Emacs is a lisp VM with a built in full scale editor. I'm not saying emacs is wrong, but they are just completely different ways of building editors.
Actually they are comparable. Someone starting out in programming needs an editor, and they are two of the options you have to choose between. Simply saying that they are not comparable doesn't help that person decide which environment to use.
I should also point out that in theory vimsh is just as powerful a programming language as Elisp. People don't use them the same way, but you theoretically can.
> I should also point out that in theory vimsh is just as powerful a programming language as Elisp. People don't use them the same way, but you theoretically can.
That's a bit of a Turing tarpit, though. A one-instruction computer can compute any function, too, but I wouldn't want to use it.
Likewise, vimsh isn't awful, but it's not a general-purpose language (elisp has a lot of warts at this point, but it is general-purpose, even if it wouldn't be my first choice for anything but extending emacs) and it's Yet Another Language; at elisp is a Lisp (which is a virtue).
Religion is borne out of not knowing what on Earth is the right thing to do, and hence having to adopt a certain approach instead of being convinced by the merits of one over the others: it's policymaking in the absence of facts. Do something for long enough and it becomes a part of who you are (your so-called "worldview"), at which point an attack on the thing is actually an attack on the ego, and we'll naturally and automatically defend it with the same dirty emotional bullshit trickery we use to gloss over all our insecurities.
The toxicity of this is not limited to front-end development, of course -- this is, in fact, the very framework we base modern democracy on. It's just lots of completely unqualified people (myself included) making a great deal of noise based on shitty information, then - once it inevitably goes tits up - we get together and point the finger at some scapegoat to absolve ourselves of liability.
We like to think that as a society we've developed from the primitive peoples of yore, but really all that's happened is that communication tech and industrialism has allowed us to mass produce and saturate our world with the achievements of a very, very select few and thereby create the illusion of universal progress. This entirely baseless pretence is giving unjust confidence to the (figuratively) blind, who are now leading us into a society of completely misguided moral absolutes: one in which local government officials will parent your kids for you with legislation, physicists will be lynchmobbed for the wrong choice of shirt, and Github will outlaw the use of the word 'meritocracy' for fear of intimidating the weak.
So yes, these issues are very important, but HTML and CSS hate games are the least of our worries.
From running a large OSS project, the general passive-aggressive (or just plain aggressive) complaint ratio to the amount of "thanks, this is awesome" ratio can be quite overwhelming and painful at times. Usually.
I've basically resolved to not complain about anything given to me for free, ever, at least on twitter, because I've felt so much of it. "Why I personally prefer X vs Y" is ok.
For twitter, it can be anything from a software project to some customer service guy somewhere, but it's important to remember that real people are out there.
That guy's boss might be a jerk to person XYZ about what you said about his software on twitter, even if you weren't particularly upset. And you definitely didn't make the author feel very good either. And who are you to complain when you couldn't build it yourself, and are putting in much less energy?
If you have a problem with free OSS bits, help fix it, or use something else.
If you've paid for something, this is what support departments and customer service groups are before too.
This is one reason despite its oddities, I like php.
Maybe because it because as a php programmers we're used to being the butt end of jokes, maybe because we think the language is eventually going to end up a backend serving json... but the people I've met at php conferences have been nice, humble and interesting. More talk about projects than tech. Haven't met a lot of dismissive people or people badmouthing other languages.
That's funny; for me, it's the one annoyance I have with PHP.
I love PHP; there's some really neat modern OO methodology and cutting-edge ideas and best-practices that I'd love to share on HN, for example.
But with the PHP-haters, the downsides of sharing outweigh the benefits. So like the OP article says, quality PHP developers just put their heads down and get back to work. Let Laracasts do the best-practices evangelism and move on.
If you're looking to find some rude, inappropriately hostile PHP pedants, there are plenty of them on IRC. A language that has so many ways to do one thing attracts a lot of people who believe their way of doing that thing is correct and anyone who disagrees is an idiot.
For a few years there I felt good (on a very superficial level) when I had to use java for some project because it was so uncool. As soon as an orthodoxy sets up I just have a default reaction. Its immature I'm sure. But you have to remember those teenage years and how absolute and stifling that orthodoxy of what's in and what's out could be.
At this stage though Java is getting so old that it seems no longer a threat to people so they are backing off (from the superficial, social point of view. There are still technical pros and cons to be debated)
If this is a 'thing' it explains a lot. I tried to engage some front end developers on their stack and got the whole smack talk thing thrown back at me. I was trying to figure out if it was something I said or what.
I played this game a bit in the late 90s and early 2000s, and ... it's just so tiring. And largely pointless. So many good points in the comments here, they've triggered so many more thoughts. I talk about this topic on and off at user groups now and then - informally, not full on presentations, but usually get thanked by someone afterwards.
There are so many tool choices that it's really really hard to even trust anyone's 'review' of the tool landscape, even in a particular vertical niche. And so many people that are writing the tools (and promoting them) are, in fact, primarily tool authors, not necessarily having to face the sort of 'in the trenches' problems that most devs have to deal with (both technical and political).
Denouncing tech XYZ because you're using ABC is often, I've found, done because the person wants some external feedback that they made the 'right' decision. Public (on forums or f2f) signaling of the choice you made, with some 'reason', lets people support you and your choice. There's certainly more to it, but that seems to be the root motivation I've seen in a lot of people in my locality who behave this way in public.
I've told the story about being at a ColdFusion developer conference, helping set up chairs the night before. One of the speakers starting ragging on PHP. Of all the people to be picking on an 'easy target' like PHP, I would have thought CF devs would be more sensitive to that sort of trash talk, likely having been on the receiving end more often than not. Not this guy - we were all treated to a 5 minute rant about how shitty PHP was is, PHP devs need training wheels to use the internet, etc. Unbelievable, but right there in front of me.
When I did it, I was trying to make sure my reasons for my choices were 'correct' (tech X was faster to write, faster to execute, cheaper, etc). After a few more years around the block, it became apparent that there are generally so many more factors at play that are not always readily apparent, and often, the best choice is the one someone already knows, because estimating learning time for 'newtechX' is essentially impossible (doubly so for stuff that's not even out of beta yet).
Argh... maybe we can get Rachel to come speak at one of our local dev groups - this message needs to be driven home more, I think.
"When we monger hate, we inspire these guys. These guys are all kinds of trouble, even if they aren't outright malicious. We can spread spread harm through them."
You are doing the we vs. them thing, not just in this sentence, but throughout the text. It's never the right approach. There's some us and some them in all of us. I see this often in writing on social issues in tech; a strong tendency to categorize and polarize, even when intentions are good. Regardless, I find the article well written and on point.
I'm actually largely experiencing this issue right now trying to pick a front end framework for an FOSS project. I know I'm using Rails on the backend because that's what I'm most comfortable in, but I can't decide between Angular.js and EmberJS and 99% of the articles comparing the two just sound attack-ey and biased and I don't want to make a decision based on someone else's preconceived biases. If anybody knows a good compare/contrast between Angular and Ember for use with Rails that is, mostly, unbiased and doesn't resort to "this framework is better because holy shit did you see how the other one solved this same problem in a slightly different but horrifically terrible way?" I would greatly appreciate it.
Depending on your requirements don't rule out other frameworks.
I use Knockout (which is supported, just had a release, picked up some new core devs and added component support) extensively and I like it a great deal.
It's not as large as either Angular or Ember but it's worth a look.
Steve Sanderson has an awesome video on it [1] which is worth a watch even if you aren't interested in Knockout, fella clearly loves and is passionate about what he does.
I'd take a look at React depending on the complexity of what you're building. If it's not too complicated, React is fairly easy to pick up and it's a joy to work with. If it's a larger project the guidance of Angular/Ember is probably worth it though.
Gonna hate here, but I've had to work with angular and it was unpleasant. The api is strange and the docs openly recommend hacking around it. Lmk if you want me to find an example.
I'd like to see some examples. Not specifically because I doubt you, but because I don't. That was my early impression of Angular, but I can't remember anything specific, just an overall impression.
This article strikes so many right notes for me and I can easily come up with even more examples of it in action, like systemd. I'm sure there exist valid criticisms but there's also a lot of people who would hate it just to look smug or feel like they're smarter to reject something so popular[0]. "If there's a lot of people who like something, and I find a reason to detest that thing, that means I know something they don't. Go me. Everyone will think I'm cool and respect me. Bring in the upvotes."
I also used to be the guy to swear by Emacs and C, bitch about how awful Java and C++ are with all the crappy IDEs (despite never having tried them out, just reading articles and comments bashing them). Eventually I matured a little and tried both out, then tried a few IDEs like NetBeans, QtCreator, and PyCharm, and I actually prefer them now. If I had never broken out of the "hating circle" I would only be able to write programs in Lisp and C. Some of you may think that's fine, even preferable. Personally in retrospect I'm happy to have widened my horizons.
[0] This is from my own experience, I used to do that.
There's certainly a Thing where you tribalise through aggression.
There's also a Thing where you signal your knowledge about crappy solutions by peeing on the crap; this informs others that you have enough knowledge to Not Use Crap. (or, alternatively, showcase yourself as an elitist jackass. ymmv).
This is a general problem in modern communication, thanks in large part to the accelerating factor of the internet. It's evolved to the point that making observations about the weaknesses of an overly adversarial/confrontational position is dismissed as a 'tone argument,' along with negative insinuations about the proponent's motives. It seems as if many people prefer to be in a social echo chamber and express violent rejection of anything that is considered foreign to that environment. I wouldn't be surprised if there is some obvious model for this in the world of cell biology.
Hmm, while I understand this (I've even written about it before!) I wonder about this specific example. Maybe another example would be better (for instance: people who hate on PHP).
I've seen plenty of people present things as literally the worst, but they're doing so in a very tongue in cheek way.
For instance: javascript is totally stupid and does totally stupid things stupidly (unlike go, which is awesome, and doesn't do stupid things) - The Presentation (given by a huge javascript fan who literally writes javascript all day every single day).
I got the impression he was hiding his own fear of inadequacy behind a wall of disapproval and smack talk. I know this method. I used to use it myself, when I felt for sure I’d be fired from the team as soon as they realized I’d never used Handlebars.
Fascinating. In that this episode represents an only slightly exaggerated instance of a pattern of such profoundly dysfunctional and self-blocking behavior in the community that has become so widely entrenched that it is beyond epidemic proportions; it has practically become the new norm.
What the author describes is just one step into becoming a godlike developer. I can't find a link / attribution right now, but it starts off as new, then you get skills and start to feel smug and good about yourself - which is in a lot of cases combined with a hating on other developers or packages. The next two steps are disillusionment - taking a fall, realizing you're still a very new developer, etc, and only from there on out do you start to develop into a more exemplary Good Developer.
I actually disagree with the entire premise of this article, and the sentiment of that premise.
This seems to be a thinly veiled attempt at censoring free speech; "you hurt my feelings, therefore you are not allowed to talk."
Frankly, I'd much rather have someone like Linus chew me out, because at least it's an honest and clear criticism. The tech industry prides itself on being an open and transparent environment, and I don't think that should change because someone's feelings got hurt.
Linus's butt-chewings are generally specific to one aspect of someone's code. He doesn't generally say "Framework X sucks because Y, let's all talk about how much it sucks for several hours instead of being productive."
I suspect that in many cases he gets frustrated when people repeatedly do something he's asked them not to do because he has to review their patches over and over again.
She touches on this in the comments there, but I see this becoming especially problematic in exclusionary hiring practices.
You can go to an interview as an expert in a given language, but if you don't know what framework a company just happens to use, you'll lose the job and they might give it to a novice who does.
Also, I would be curious to know which conference she is referring to. I realize this is a pandemic problem, but if she would name some names it might get the ball rolling on turning things around.
Freud had it that sublimated aggression provides energy. Like all things w/ an indisputable theorist, I'm not sure if he's on the right page. However if it was true, it would explain the value in developer holy wars.
Quote from the above link -->
The sublimated libido, according to Freud, contributes to the formation and maintenance of permanent object relations and to the 'molding of psychic structures'; once the psychic structures are formed, the energy is at the disposal of the ego and the superego. Similarly, aggressive energy is 'neutralized' (Hartmann, 1952) and thus can be transferred from the id to the ego. According to Hartmann, Kris & Lowenstein, "the capacity to neutralize large quantities of aggression may constitute one of the criteria of ego strength".
I agree that this sort of thing is bad, but that notion is starting to reach saturation level. At least for the things I read on the web. Boorish teammates, hostile speakers, misbehavior at conferences, people dismissing technical ideas for dumb non-technical reasons, etc. are indeed all bad things. Noted.
Also, maybe part of the problem is thinking/assuming that a bunch of front-end devs are going to be "your people". Yeeuch. It's a job, some of those people you will like and get along with, most of them less so.
I don't think there's anything wrong with being negative per se. I work at Google, and can think of a couple of developers who complain about others' products a lot. And they can usually get away with it, and in fact even be popular simply because they're helpfully negative.
What's wrong is when someone is unhelpfully negative. This is the person who just complains no matter what happens.
We do tend to get very tribal/ideological. This likely happens in all fields, but that doesn't excuse the behavior. Getting tunnel vision and only thinking a specific way of development/design is right is problematic.
There's a difference between this and just general "best practices". The latter are positive and suggestive whereas the former tends to be very absolute.
In my experience, the continually evolving art of programming lends itself to cognitive dissonance. One has a history of doing something in manner X and yet manner Y holds clear promise. Two thoughts collide. In some individuals is expressed as a rejection of Y leading to entrenchment in X. The byproduct is irritation or even rage.
Relational Databases are a perfectly good tool and will fit 90% of the applications being developed. But NoSQL is shiny, and we have to try the new way (despite the fact the new way was what people were doing before relational databases came along). Likewise with back end languages. We have plenty of good mature solutions on the back end, but people want to use Nodejs. Fine if your use case is many concurrent connections, but otherwise why not use something more "traditional" (mature, tested, understood).
Great article, I myself have been both on the sending and receiving end of such discourse. I like OSX and love Node.js which can become a source of confrontation. Talk about node.js in the Reddit programming sub and prepare for the backlash :)
Instead of bashing technology X, show everyone how good technology Y is. There is no need to be negative about anything. There is enough negativity in the world to go around.
This industry has become too anxious. It's like the new standard is when ever someone makes an post like "10 books you should read" and the first comment here on HN is "Why the hell are you telling me what to read?".
When I express my opinions I don't have to account for anyone. My opinions are my opinions and I'm going to be proud of them. And personally I want everybody else to feel the same. Be opinionated and be proud!
It is a subtly different - and more persuasive - thing to say "Here are 10 books I liked, and here's why" than it is to say "Here's 10 books you should read." Imperative statements tend to evoke more visceral reactions than indicative ones.
It's OK to be opinionated (I am) and it's OK to be proud of one's opinions (ditto) but the issue comes when we go into promotion mode, claiming everyone must share our opinions or be an idiot (I feel this way about some things, not others) and insisting that everyone needs to learn about the background for our opinions (likewise).
In the particular situation when platforms are multiplying and the years behind us are littered with the corpses of failed initiatives that promised a world enough and time, the call to learn The One Best Technology becomes stale and annoying. It looks like an invitation to waste our time rather than becoming more expert with the technology we've already invested a lot of time in, and are just hoping we can make that time worthwhile before it becomes obsolete.
Bingo! The dual sidebars are independently scrollable (via overflow-y: auto on the relevant containers). On recent OS X versions with the vanishing scrollbars, this looks great. But on other platforms (e.g. Windows, such as you're using), boom!
I find it sexist that the author chose to use the words "this guy" and "don't be him". Would she be writing this same article if the presenter at the conference were a woman?
I find it sexist that you're complaining about her using the words "this guy" and "don't be him". Would you be writing the same comment if the blogger was a man? (Not even joking. There are far more gendered comments by men in this HN discussion that didn't get this kind of response.)
That was such a small part of the article I don't think it's even worth calling out. Sibling comment mentions the relevancy to the actual graphic, that's probably all it is. Author also called out her own negativity previously. This isn't "men shouldn't be so negative". It's "we as frontend developers shouldn't be so negative". Context.
was that a drawing of the presenter? or just following the statistical prevalence of male programmers? was his male-ness really the focus of the picture, or was the artist just using the proper pronouns for the character? was his masculinity being presented as the cause for his behavior?
It does suck that a man is the default for this, but IMO it's a projection of toxic masculinity (i.e. Patriarchy).
I work in an office with a mix of highly professional, low-ego workers and highly dismissive, high-ego workers. No history of freelancing there that I know of. One group is multiples easier to work with... guess which.
If I were to try and draw a line, I'd be more general and say that it depends on culture during early career. You can learn one of two lessons: That aggression is required and accepted way to win an argument, or that aggression is an unacceptable way to reach the correct solution. Both lessons are true in certain contexts, and depending on which goal is valued more in your culture (winning argument or correct solution), you'll learn one or both of these two lessons. If you truly believe that you will find the most correct solution alone, without the help of your team, you're very likely to learn lesson #1 and behave that way. That type of person, though, is destined to make a huge mistake and learn the hard way how to collaborate.
You are dismissing the reality that some people are actually smarter than others. There are some people who really do have a real vision of a 'best' solution. However, it is true that collaboration is the requirement for a working relationship and thus a product out of that working relationship... But, the collaborative effort and resultant end product is always, by necessity, a non-ideal solution for at least a portion of the end-users. Keeping this in mind, it can be understood that "the best product doesn't win" -- rather, the most popular and most agreed upon solution or product is what wins.
In summary -- I agree that negativity and/or aggressiveness in pursuit of a solution leads to a unworkable /collaborative/ environment... But I disagree that the collaborative environment produces the best product or solution to a problem [programming or general]
Warning! I am not one of the smart ones. I tend to sit in a corner and doodle like the article writer. Perhaps, if the collaborative environment was less collaborative and more constructive, I would participate more... see Office Space for better answer.
>You are dismissing the reality that some people are actually smarter than others.
I never dismissed anything like that. If I did, please quote my dismissal. In fact, this sounds like an assumption you made before reading what I wrote. Change your assumption and try reading it again.
> There are some people who really do have a real vision of a 'best' solution.
This statement only works with quotes around "best" and phrased as "a best" instead of "the best." I do not question that it is possible for a single person to have a driving vision, but what happens when this person, instead of explaining their reasoning to their collaborators, uses aggression to dominate them and force them to accept his or her solutions? Do flaws get pointed out? Or are we under the assumption that "smarter" people do not make mistakes? If not, with everyone on a team looking up to a single person to make all the decisions, who will catch the mistakes?
The question here was never "collaborate vs. don't collaborate." We're talking about teams, where a degree of collaboration is necessary to move forward, and individuals who disrupt the collaborative process via aggression.
>But, the collaborative effort and resultant end product is always, by necessity, a non-ideal solution for at least a portion of the end-users.
How is this different than non-collaborative effort? What exactly are you saying here? That a single person can build a completely perfect product that meets the needs for all end users while a group cannot? What you have said above is true whether collaboration is involved or not -- everything has flaws.
>Keeping this in mind, it can be understood that "the best product doesn't win" -- rather, the most popular and most agreed upon solution or product is what wins.
In a working collaborative environment, these two can be the same thing. When one person makes all the decisions by fiat, the solution that wins is that person's favorite, not one that has been thoroughly vetted or necessarily correct. I would rather rely on a vetting process than on a single human's biases. This is what collaboration is for, diluting biases and natural cognitive flaws. No one is immune to all biases and flaws.
>Perhaps, if the collaborative environment was less collaborative and more constructive, I would participate more.
What do you see as the difference between "collaborative" and "constructive"?
Hacker news is not immune from this behavior either. Nearly every day I read an article and I think "wow, that might be really cool if I ever have time for it" but then I read the comments section and 90% of the comments go out of the way to disagree with EVERYTHING that the author said. It can be really off-putting to be honest.