The Hating Game(rachelnabors.com)
rachelnabors.com
The Hating Game
http://rachelnabors.com/2015/03/13/the-hating-game
142 comments
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.
I have a hypothesis which is much less silly.
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.)
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.
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.
[1]. "Programmer Knowledge" http://henrikwarne.com/2014/12/15/programmer-knowledge/
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.
[1]. "Programmer Knowledge" http://henrikwarne.com/2014/12/15/programmer-knowledge/
Here is the limit of what I was saying.
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.
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'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.
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.
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.
People who disdain math as "brain teasers" are deprived of the rush of knowing that some piece of your knowledge will stay true forever.
Sounds good, but this is a bad idea.
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.
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.
Are you now saying Java isn't awful? That's news, coming from btilly.
He doesn't appear to be offering any opinions on Java, or any other framework, language, etc., at all.
That is true. But I have offered opinions in the past. For example see http://programmers.stackexchange.com/questions/66808/java-or... for an opinionated comparison I offered on Python vs Java. I still stand behind everything that I said there.
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.
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.
I can spell it out if anyone needs it:
Java isn't awful. Neither is PHP btw.
(I won't defend everything written in those languages though.)
Java isn't awful. Neither is PHP btw.
(I won't defend everything written in those languages though.)
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.
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.)
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
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
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
Of course. But I thought ITT we were being silly ;)
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?
Yep. I wish I didn’t like programming is C so much :)
Curious. If you like C, what is your opinion of Ada?
I have to say I have never used Ada. I have been curious about it, but I have never had a project where it seemed a good idea to use.
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.
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.
Putting people into different groups is enough to get people from one group to hate the other.
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.
brown v. blue eyes classroom experiment
http://www.pbs.org/wgbh/pages/frontline/shows/divided/etc/vi...
Indeed - I've heard it referred to as 'ingroup/outgroup behaviour' (https://en.wikipedia.org/wiki/Ingroups_and_outgroups)
It's nowhere that complicated.
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.
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.
It's weird that you put "winning arguments" in the category apart from the other Subcultures. Your biased self-image is showing :-)
Close.
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.
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.
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."
IS it not usually the other way around?
People towards the autistic end of the spectrum prefer to interact with machines rather than people.
I think programming can be very mentally taxing. I prefer empathy over dominance.
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.
How I would love to be able to program for 8+ hours uninterrupted at my work. I really enjoyed my job back when I did that.
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.
Ever listen to a group of men argue about the qualitative meaning of baseball statistics?
I don't think it has anything to do with technology at all
I don't think it has anything to do with technology at all
I don't think it's silly.
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.
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.
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.
[deleted]
Comments section considered harmful...
That's true. It's very easy to get caught up in that echo chamber even as an experienced developer.
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)...
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)...
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 only argument you need to justify your choice is the results you got from it. Now if you have no results, you can use petty argumentation instead.
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.
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.
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?
If anything, denying it would be evidence of ignorance, no?
They're pretty interchangeable in my experience.
I've used both in side projects (where the choice is fully mine) and usually the decision comes down to libraries I'm going to use.
I've used both in side projects (where the choice is fully mine) and usually the decision comes down to libraries I'm going to use.
[deleted]
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.
[1] http://mattdesl.svbtle.com/browserify-vs-webpack
[2] https://en.wikipedia.org/wiki/Psychological_projection
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.
[1] http://mattdesl.svbtle.com/browserify-vs-webpack
[2] https://en.wikipedia.org/wiki/Psychological_projection
I don't think it's insecurity. You get community status and improved job offers by creating and managing a high-profile project.
So the field is a firehose of high-profile projects, whether or not they're needed.
It's possible a very large and complex generalisation of Conway's Law, between groups that barely communicate:
http://en.wikipedia.org/wiki/Conway%27s_law
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.
So the field is a firehose of high-profile projects, whether or not they're needed.
It's possible a very large and complex generalisation of Conway's Law, between groups that barely communicate:
http://en.wikipedia.org/wiki/Conway%27s_law
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.
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.
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.
I think this applies all over, not just to PHP.
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.
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.
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.
Fortunately they had a section "what puts you off applying to us" where I voiced the absurdity of those questions.
> 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.
absolutely not surprising given that there is even a pretty popular language with indent base syntax out there.
> [...] 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.
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.
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.
no vi v. emacs?
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.
Do evil-mode users count?
No! Stop! What are you doing? We're already battered enough as it is; we can't afford yet another breach of the vi/Emacs cease-fire.
No GNOME vs. KDE either, or language wars. While they do demonstrate the general "haters gonna hate" principle, they're not strictly back end.
Probably should have thrown in something about systemd, though. ;)
Probably should have thrown in something about systemd, though. ;)
don't get them started :)
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.
> 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).
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).
"It's long since time we developers in all specialties tried to turn the corner on this issue."
But that's part of the fun :(
But that's part of the fun :(
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.
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 blog is good reading on the subject too - http://powazek.com/posts/3368 )
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 blog is good reading on the subject too - http://powazek.com/posts/3368 )
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.
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.
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)
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.
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.
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.
Why not try a quick prototype with both? FWIW Rails + Ember seems a fairly common choice.
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.
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.
[1] http://blog.stevensanderson.com/2014/06/11/architecting-larg...
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.
[1] http://blog.stevensanderson.com/2014/06/11/architecting-larg...
+1 Knockout is a treasure chest of powerful patterns from remarkably few core concepts.
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.
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.
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).
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'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.
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.
Or maybe he was being exceedingly dismissive because it's funny? I don't understand the need to make all these assumptions.
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.
Or not, everyone's different.
Or not, everyone's different.
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.
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.
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.
> He doesn't generally say "Framework X sucks because Y
Not sure how relevant frameworks are to the world of kernels but I'd imagine he'd chew you out if you tried to get any C++ into the kernel.
Not sure how relevant frameworks are to the world of kernels but I'd imagine he'd chew you out if you tried to get any C++ into the kernel.
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.
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.
Reminds me of a "too long; did read" psychoanalysis link: http://rint.rechten.rug.nl/rth/dennen/a-panal.htm
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".
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".
[deleted]
There's a good reason for this - pick an unpopular toolchain and you can become unemployable.
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.
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.
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.
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.
I see the opposite.
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).
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).
"An acutely negative mindset..."
Some people may say front end developers are not "programmers" in the strict sense of the word, but I believe much of this still applies...
http://edu.mkrecny.com/thoughts/be-nice-to-programmers
Some people may say front end developers are not "programmers" in the strict sense of the word, but I believe much of this still applies...
http://edu.mkrecny.com/thoughts/be-nice-to-programmers
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 :)
We would all do better to lead by example.
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.
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.
[deleted]
I appreciate you highlighting a sentiment that I too have felt at many meetups and in the JS community. It's toxic and unproductive.
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!
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.
"Imperative statements tend to evoke more visceral reactions than indicative ones."
Also as a general rule they will get more linkbaity attention.
Also as a general rule they will get more linkbaity attention.
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.
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.
BTW, the page doesn't render properly in my browser (current FF).
FWIW, looks fine in FF 36.0.1 here, same as in Chrome 41. Maybe you have an extension that's causing issues?
Here is a picture that shows the problem:
http://i.imgur.com/iunhbuR.jpg
http://i.imgur.com/iunhbuR.jpg
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!
[deleted]
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.)
What is satire?
I don't see why not.
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).
It does suck that a man is the default for this, but IMO it's a projection of toxic masculinity (i.e. Patriarchy).
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.
[deleted](1)
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.