rhapsodic

I was around when browser based apps started to take over the enterprise software world. One of the big selling points was its simplicity compared to native desktop development languages like (horrors!) Visual Basic. Anyone could open up Notepad and create a simple HTML page with some form elements and a submit button.

Now, I realize that browsers' capabilities have advanced enormously in the intervening years, but it's still just HTML, CSS and Javascript, once the transpilers and the zillion other build tools get done with it. And I would argue that someone who really knows HTML, CSS and Javascript at a deep level can write it directly and maintain it a lot more efficiently than with a bunch of third-party frameworks and an overly-complex build process.

It's a pity that's the first result, because it's flat wrong. This article actually talks about the origin of the claim:

https://www.ybrikman.com/writing/2013/09/29/the-10x-develope...

I believe in 10x programmers, because I have known many programmers over the years, and I can think of many pairs where one was clearly 10x as productive as the other. And I think the reason there are 10x programmers is that our profession tolerates a lot of embarrassingly incompetent people. If someone were 10x as productive as an average developer, that would be truly extraordinary. But I don't see 10x programmers as all that extraordinary, because there are so many people who get paid to program but suck at it so bad, that being 10x as productive as they are is not all that impressive.

Yeah. It looks like the author laid out her views in the first sentence.

  > The myth of the 10x programmer persists, but the 
  > shine is wearing off.

You can't possibly know that for a fact.

Oh, and "someone on a team doing 10x more average code than his or her peers" is not what 10x programmer refers to.

The worst.

That's an absolutely valid point. And I hope they're very successful in their efforts.

At home, I like parking in a driveway better than parking on the street.

At home, I like parking in a garage better than parking in a driveway or alley.

At home, I like parking in an attached garage better than parking in a detached one.

I like living in my own house better than an apartment.

I like living in a free-standing house better than a duplex or row house.

I like a large yard where my young kids can play with their friends and I can keep an eye on them out the window.

I want to be able to make some noise without disturbing my neighbors, and vice-versa. I don't like living cheek-by-jowl with my neighbors.

I like living in a neighborhood that has virtually no violent crime or burglaries. I don't want to have to run a gauntlet of panhandlers when I go for a walk around the neighborhood.

I prefer to live in a house built since 1978, so I don't have to deal with lead paint, asbestos, knob & tube wiring, wood lath walls, lead (water) service lines, buckling foundations, damp moldy basements, rotting, leaking box gutters, or cheap, chalky aluminum siding that was installed in 1968 over Insulbrick that was installed in 1938. Unfortunately, those houses tend to be relatively rare and exorbitantly expensive in my local city.

I don't know why so many city dwellers seem to obsess over the fact that there are many people who simply prefer living in the suburbs. But there are.

https://l.facebook.com/l.php?u=https%3A%2F%2Fwww.wsj.com%2Fa...

https://en.wikipedia.org/wiki/Soldier%27s_Joy_(fiddle_tune)

It's the office responsible for processing TPS reports.

Then Reagan happened.

No, the ACLU happened. Because of their efforts, it's much more difficult today to involuntarily commit someone to an institution who thinks that aliens are controlling their digestive system.

That's not to say that state governments weren't happy to empty out and shut down their mental institutions, however.

Why shouldn't the US support Israel?

(Edit: No one ever explains it. They just downvote the question.)

> This seems ...honestly pretty reasonable and well thought out to me.

As someone who has changed a few diapers in my day, it's one of the most idiotic things I've ever read.

  > Ask Your Baby's Permission Before Changing Diaper, 
  > Says Sexual Consent Expert[1]

[1] http://www.newsweek.com/diaper-ask-baby-permission-changing-...

You're joking, right? When that statue was put up, there was massive hype and media coverage that went on for days. And there was a controversy when the bull sculptor objected to the way that the girl statue was juxtaposed, and that got a lot of coverage. Including here on HN, IIRC.

By "funny" I think he meant odd or perplexing.

What is your native country?

  > I have always been struck by the minimalist knowledge of
  > most developers, when it comes to the programming
  > language  they were using. It took a while, but
  > eventually I accepted the obvious: most developers 
  > don’t need to know much about the language they are
  > using to get their job done.

"Premium mediocrity" is still mediocrity.

Or kids with different tastes. I liked candy and cookies as much as any other kid, I suppose, but I never much cared for marshmallows. For me to leave one sit there would not have required much strength of will.

I wonder why they didn't ask each kid what their absolute favorite candy or sweet treat in the world was, and use that for the test instead.

It's frightening, the degree to which many professional web app developers do not know the fundamentals of Javascript. Our technical interview starts out with ridiculously simple questions and gets progressively more difficult and esoteric. And a dismayingly high number of candidates don't get past the first couple of questions. And these are people with years of experience and at least some of the hot JS frameworks on their resume.

I realize I'm outside the mainstream schools of thought. My approach to developing software absolutely depends on having a rare and special kind of developer doing the work. The emphasis is on deep expertise in the core technologies - JS, HTML and CSS -- that will stay around while fads come and go. And quite frankly, my approach does not scale well. It's not that I couldn't keep 40 developers of the caliber I require productive, it's just nigh on impossible for a non-Google-class company to hire that many in one place. (Considering all you've heard about Google's hiring process, imagine how much it costs them to hire a single developer -- even before the first paycheck is cut.)

>As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad.

Maybe you're reversing cause and effect. Maybe your exposure has been so bad because you've never made the effort to learn it from scratch.

When I adopt a technology for use, I go really deep. I'll get a book, start on page 1, and work through it to the end. (Sometimes I might deem the last few chapters skippable.) After a few months I'll re-read parts of it as a refresher. (That has proven super-helpful.)

That's why I think Reactjs and its like are a lot of fuss and bother to do something that I can already do easily with a lot fewer moving parts. And also, if I decide to use React, I, and (perhaps to a slightly lesser extent) my developers, will go deep into it, and that takes a lot of time and effort. So I have to be very judicious in what new shiny thing I go chasing after. I need to see an obvious, significant return on that type of investment. (I don't care about my resume having the latest buzzwords.) And I just don't see it with any of these frameworks.

I was a rank and file developer on a similar shit show years ago. The main difference was that it was a greenfield project at a startup. The people calling the shots were dead set on using the latest fads -- at the time it was the Rational Unified Process, with all the attendant documentation, and EJBs. I knew that Entity Beans were a monumentally stupid idea when I first read the O'Reilly book about them. And I said so, to anyone who would listen, to no avail. I think the team reached 40 developers at its peak, of which maybe half were totally incompetent. (By my standards.) The schedule slipped rapidly, we were put on mandatory 6 day work weeks, I bailed out, easily finding another job, and eventually the whole project cratered.

I'm not going to argue with your experience, tracker1, but all of my experience tells me that the ability of the developers is the best predictor of the outcome of a software development project. And our profession, unfortunately, is awash with incompetent people. For example, people who have worked for over 5 years as a Java developer, who are unable to write a Hello World program in Java from scratch in a plain text editor, and compile it and run it from the command line.

I have. Without problems.

>In practice, CSS blows up, other portions of the app stop working correctly.

Perhaps in your practice, tracker1. But not in mine.

That's what everyone seems to be missing here. This is all a bunch of hand waving to me, because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me.

If you need all of this stuff to ship robust, maintainable code, then you would be foolish not to use it. But I would be foolish to use some complex framework that I do not need to ship robust, maintainable code.

I think the facade is starting to crack with many of these JS frameworks. More and more people are writing articles like the OP and saying that this particular emperor has no clothes.

That's strictly your opinion, which I do not happen to share.

For sure. We have a team of people dedicated to testing. Compared to developers, they're easier and cheaper to hire. Our developers, who are very brilliant and very expensive, mainly write code for production, and leave testing to the testers. They write code designed to run efficiently and be maintainable, not to be more amenable to unit-testing.

This has proven to work extremely well for us. If you need unit testing to ship robust code in a short timeframe, it would be foolish for you to not write the unit tests. But our team culture is such that we don't do things that we don't need to do to be productive and successful, and unit testing is one of those things.

This defines what the developer wants to happen,

Yes, it does. All in one place, in about 10 easy to understand, easy to debug lines of code.

>but is brittle and hard to test.

I don't see how it's brittle, or hard to test. You click the button, and verify that it does what it's supposed to. Having done it more times than I can possibly count, and ending up with robust code, shipped on time, I can tell you that it's not hard, if you know how to do it.

> Frameworks would typically break this into actions or methods that modify state and a UI that updates when the state changes,

Which, IMO, makes something simple to understand and dead simple to debug into something painfully, ridiculously complex. And people complain about "jQuery spaghetti code".

>so that the parts can be effectively unit tested and the UI can be changed without touching the rest of the logic.

You cannot effectively unit test UI code, if by effective, you mean that it can replace manual testing. It can't replace manual testing. Someone will have to click that button under all of the likely scenarios and verify that it works. I'm sure it's not to you, but to me, writing unit tests for UI code would be a massive waste of time.

If someone thinks they can be more productive using JS frameworks, and I don't have any personal financial stake in their productivity, then they should use them. But I don't see web development using a few simple tools like jQuery as difficult or mysterious or time-consuming.

Last year I interviewed a few recent boot camp grads and they all sent me a link to their copy of the same React-based project. When I asked them questions about how things worked, in generic terms, for example, "what do you think makes this picture slide down slightly and expand in size when I mouse over it", they had no clue. I guess it was just a React component they dropped in, following the steps in the tutorial. I'm not faulting those people -- they paid a lot of money and did exactly what they were told they needed to do to land a sweet high-paying programming job. But they're simply of no use to me. I need the one who looks at it and knows right away that it would take about 4 lines of CSS to accomplish, even if they had to consult a CSS reference to find out exactly which properties/values to use.

I haven't found that to be a major issue. And I don't think the term "refactor" is the best choice here.

jQuery is library that provides DOM shorthand - it isn’t a true application framework.

Of course not. I don't want a third-party application framework. I discovered years ago that they're not worth the extra effort or the technical debt one incurs with them. (At least not to me. I'm not telling anyone what they should think or that they should design their applications like I do.)

My approach for me and the developers on my team is to develop a deep level of understanding of HTML, CSS and JS. Once you have that, the prospect of doing things for yourself that frameworks would otherwise provide does not seem all that daunting. To me, frameworks like React, Angular, etc. don't reduce complexity, they increase it.

And I hasten to note that I realize that many bright, capable people hold a different view , and I'm not saying they're wrong.

What does that even mean?