4 ms·

This sentiment, expressed collectively, commoditizes the entire profession. How can you expect to ask for raises if all devs are basically interchangeable? If

This sentiment, expressed collectively, commoditizes the entire profession. How can you expect to ask for raises if all devs are basically interchangeable? If we've eradicated all notions of design, and follow prescriptive rules of structuring and solving problems that anybody can Google and follow, then what avenues are left to express technical ability? What differentiates you?

aaronem 13y ago
Calmly, Chicken Little, calmly! Perhaps the sky is not falling after all...
- mattgreenrocks 13y ago
  Nope, it isn't. But clinging to frameworks in lieu of actual program design can hamper your ability to design something that doesn't fit neatly into a predefined box.
  - aaronem 13y ago
    Of course. But no one seems to be suggesting otherwise, that I can see, and for the relatively common case in which one needs quickly to prototype and roll out something which does "fit neatly into a predefined box", a framework is often just the thing.
    - Zelphyr 13y ago
      You touch on the one things that frameworks are actually good for: prototyping. Unfortunately they're never just used for that purpose. The prototype and all the framework cruft is then called "the product" and used as such. And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together.
      - scarecrowbob 13y ago
        "And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together." Is it possible that some of us have an idea about what we're doing, but have to do enough different projects that learning a common framework has enough of a benefit to outweigh writing bespoke code for everything? I don't feel the need to write a whole language for every problem I need to solve, and I don't generally think of the language functions I don't use on a given project as "cruft".
        Zelphyr 13y ago
        Who said anything about writing a whole language? Just know the language you're writing in well enough that you can build something better without a framework than you can with.
        aaronem 13y ago
        Well, sure. When I need something like URL routing, or object-relational mapping, or templating, why not reinvent it from scratch every time? Or, failing that, why not handle things like that with a collection of favorite libraries, each of which has its own calling conventions, its own requirements, and its own attitude toward the world? Reconciling all those differences certainly won't take a significant amount of time, and I'm always happy to spend my efforts on tooling instead of on whatever project inspired the need for tooling in the first place. More seriously, I can understand where you might be coming from with the implication that frameworks are a crutch for developers who don't bother to learn, or aren't capable of learning, the language in which the framework is implemented; I've had to clean up the wreckage left behind by Ruby on Rails hacks, too. But what's important to keep in mind is that the Rails dev community is extremely atypical in its extremely low average level of basic programming capability, and the Rails framework is likewise anomalous in the degree to which it forgives such incompetence. These traits, I stress, are not common to frameworks in general or to the developers who employ them, and consequently it is very much a mistake to use the Rails ghetto as a basis for extrapolation to more or less anything else. It's your mistake to make, of course, and if you insist upon it, then I won't go to any further effort on your behalf. But you can't say no one tried to warn you.
  - chongli 13y ago
    Frameworks tend to arise in languages with poor composability. Composable languages favour large numbers of small libraries which can be mixed and matched in many creative ways. Composability favours design.
cliffbean 13y ago
This sentiment, expressed collectively and somewhat unsympathetically, portrays the entire profession as prioritizing job security over true excellence.
- mattgreenrocks 13y ago
  Indeed. But excellence should mean using the right design for a program, not the Good Enough one advocated by today's fashionable framework. I'm more concerned about collective effects (such as negating the need for analysis and design). This is yet another instance of Worse is Better.
  - mooreds 13y ago
    What is worse? What is better? Often shipping something that is 'Good Enough' is better than getting the 'right' (perfect?) design for a program. In the post, it is clear that moot has a set of concerns that a typical business software developer doesn't have. So, pick the right tool for your business situation, which may include a framework, or not. But I have to say, as a developer, the times when I thought I had to start from scratch and been right were far fewer than the times I wanted to start from scratch and been wrong. That may be a testament to my skill, the problems I work on, or both.
- chongli 13y ago
  Or one could say that it reveals the fatal flaw in our current system of capitalism: Automation is desirable because it increases efficiency and lowers costs. Automation is undesirable because it eliminates jobs and automatons are not consumers.
  - vidarh 13y ago
    That was Marx main argument for the inevitability of a socialist revolution: That capitalism will eventually become efficient enough to on one hand create enough goods to make it possible to totally eradicate poverty, but on the other hand become efficient enough to substantially reduce employment.
pedalpete 13y ago
I find the difference to be that each developer is now more productive and can add more function in less time. The profession isn't commoditized, the lower end of the profession gets better, and those with the skills move up a notch and do more and more challenging things. I used to build single-page javascript apps in pure javascript (pre-jQuery), and it was a pain. Once jQuery came along, things were easier. I actually don't think I'd have too much trouble going back and using just jQuery, but I don't think I'd be as productive as I am with backbone, angular or knockout.
- mattgreenrocks 13y ago
  I want to believe you, but I also see that a significant portion of the industry is still on CRUD, and people still get really excited about CRUD frameworks.
  - porker 13y ago
    And yet I haven't seen a convincing web CRUD framework. Have you? I never did desktop development so don't know about there, but some must have been good.
    - wtracy 13y ago
      Isn't that basically what Rails and Django are? Or are you asking for something client-side?
  - pedalpete 13y ago
    I don't know why you were downvoted. I (think) I agree with you. I'm assuming you mean they are on CRUD as in most projects are what I call 'simple I/O'. Data goes into a database, data comes out of a database, and the job of the developer is just to make that happen. For the most part, that is true, but I don't think you can blame that on the 'industry', that's the 'market'. The majority of the market didn't/doesn't need anything more than that. However, if you have the skills, there are lots of jobs out there in data-analytics, robotics, etc. etc. (depending on where you are) that probably wouldn't have been available if we were ALL neck deep building every CRUD app from scratch. The frameworks make average people right faster and better code. Hell, they help me write better and faster code. I'm no coding genius, but I've built apps in rails, and it is faster than when I was building everything by hand in PHP. I haven't been doing much CRUD lately, seems like Front-End has taken the majority of my time in the last few years, but that's part of the 'craft' of being a developer. I actually find front-end more challenging and rewarding than CRUD (these days) simply because frameworks have made CRUD so easy.
SkyMarshal 13y ago
It doesn't commoditize the entire profession, only the 50% of it that is common to every web site or app you ever build. The other 50% is where the artistic license, craftsmanship, business sense, empiricism, and other value-adds of your team comes in.
al2o3cr 13y ago
"then what avenues are left to express technical ability" I dunno, maybe actually solving problems for clients instead of playing endless rounds of "my JS is smaller than yours"?
- mattgreenrocks 13y ago
  This is not about code golf, this is about the widespread automatic use of frameworks in lieu of an analysis/design/build-one-to-throw-away phase.

aaronem 13y ago

Calmly, Chicken Little, calmly! Perhaps the sky is not falling after all...

mattgreenrocks 13y ago
Nope, it isn't. But clinging to frameworks in lieu of actual program design can hamper your ability to design something that doesn't fit neatly into a predefined box.
- aaronem 13y ago
  Of course. But no one seems to be suggesting otherwise, that I can see, and for the relatively common case in which one needs quickly to prototype and roll out something which does "fit neatly into a predefined box", a framework is often just the thing.
  - Zelphyr 13y ago
    You touch on the one things that frameworks are actually good for: prototyping. Unfortunately they're never just used for that purpose. The prototype and all the framework cruft is then called "the product" and used as such. And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together.
    - scarecrowbob 13y ago
      "And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together." Is it possible that some of us have an idea about what we're doing, but have to do enough different projects that learning a common framework has enough of a benefit to outweigh writing bespoke code for everything? I don't feel the need to write a whole language for every problem I need to solve, and I don't generally think of the language functions I don't use on a given project as "cruft".
      - Zelphyr 13y ago
        Who said anything about writing a whole language? Just know the language you're writing in well enough that you can build something better without a framework than you can with.
        aaronem 13y ago
        Well, sure. When I need something like URL routing, or object-relational mapping, or templating, why not reinvent it from scratch every time? Or, failing that, why not handle things like that with a collection of favorite libraries, each of which has its own calling conventions, its own requirements, and its own attitude toward the world? Reconciling all those differences certainly won't take a significant amount of time, and I'm always happy to spend my efforts on tooling instead of on whatever project inspired the need for tooling in the first place. More seriously, I can understand where you might be coming from with the implication that frameworks are a crutch for developers who don't bother to learn, or aren't capable of learning, the language in which the framework is implemented; I've had to clean up the wreckage left behind by Ruby on Rails hacks, too. But what's important to keep in mind is that the Rails dev community is extremely atypical in its extremely low average level of basic programming capability, and the Rails framework is likewise anomalous in the degree to which it forgives such incompetence. These traits, I stress, are not common to frameworks in general or to the developers who employ them, and consequently it is very much a mistake to use the Rails ghetto as a basis for extrapolation to more or less anything else. It's your mistake to make, of course, and if you insist upon it, then I won't go to any further effort on your behalf. But you can't say no one tried to warn you.
- chongli 13y ago
  Frameworks tend to arise in languages with poor composability. Composable languages favour large numbers of small libraries which can be mixed and matched in many creative ways. Composability favours design.

cliffbean 13y ago

This sentiment, expressed collectively and somewhat unsympathetically, portrays the entire profession as prioritizing job security over true excellence.

mattgreenrocks 13y ago
Indeed. But excellence should mean using the right design for a program, not the Good Enough one advocated by today's fashionable framework. I'm more concerned about collective effects (such as negating the need for analysis and design). This is yet another instance of Worse is Better.
- mooreds 13y ago
  What is worse? What is better? Often shipping something that is 'Good Enough' is better than getting the 'right' (perfect?) design for a program. In the post, it is clear that moot has a set of concerns that a typical business software developer doesn't have. So, pick the right tool for your business situation, which may include a framework, or not. But I have to say, as a developer, the times when I thought I had to start from scratch and been right were far fewer than the times I wanted to start from scratch and been wrong. That may be a testament to my skill, the problems I work on, or both.
chongli 13y ago
Or one could say that it reveals the fatal flaw in our current system of capitalism: Automation is desirable because it increases efficiency and lowers costs. Automation is undesirable because it eliminates jobs and automatons are not consumers.
- vidarh 13y ago
  That was Marx main argument for the inevitability of a socialist revolution: That capitalism will eventually become efficient enough to on one hand create enough goods to make it possible to totally eradicate poverty, but on the other hand become efficient enough to substantially reduce employment.

pedalpete 13y ago

I find the difference to be that each developer is now more productive and can add more function in less time. The profession isn't commoditized, the lower end of the profession gets better, and those with the skills move up a notch and do more and more challenging things. I used to build single-page javascript apps in pure javascript (pre-jQuery), and it was a pain. Once jQuery came along, things were easier. I actually don't think I'd have too much trouble going back and using just jQuery, but I don't think I'd be as productive as I am with backbone, angular or knockout.

mattgreenrocks 13y ago
I want to believe you, but I also see that a significant portion of the industry is still on CRUD, and people still get really excited about CRUD frameworks.
- porker 13y ago
  And yet I haven't seen a convincing web CRUD framework. Have you? I never did desktop development so don't know about there, but some must have been good.
  - wtracy 13y ago
    Isn't that basically what Rails and Django are? Or are you asking for something client-side?
- pedalpete 13y ago
  I don't know why you were downvoted. I (think) I agree with you. I'm assuming you mean they are on CRUD as in most projects are what I call 'simple I/O'. Data goes into a database, data comes out of a database, and the job of the developer is just to make that happen. For the most part, that is true, but I don't think you can blame that on the 'industry', that's the 'market'. The majority of the market didn't/doesn't need anything more than that. However, if you have the skills, there are lots of jobs out there in data-analytics, robotics, etc. etc. (depending on where you are) that probably wouldn't have been available if we were ALL neck deep building every CRUD app from scratch. The frameworks make average people right faster and better code. Hell, they help me write better and faster code. I'm no coding genius, but I've built apps in rails, and it is faster than when I was building everything by hand in PHP. I haven't been doing much CRUD lately, seems like Front-End has taken the majority of my time in the last few years, but that's part of the 'craft' of being a developer. I actually find front-end more challenging and rewarding than CRUD (these days) simply because frameworks have made CRUD so easy.

SkyMarshal 13y ago

It doesn't commoditize the entire profession, only the 50% of it that is common to every web site or app you ever build. The other 50% is where the artistic license, craftsmanship, business sense, empiricism, and other value-adds of your team comes in.

al2o3cr 13y ago

"then what avenues are left to express technical ability" I dunno, maybe actually solving problems for clients instead of playing endless rounds of "my JS is smaller than yours"?

mattgreenrocks 13y ago
This is not about code golf, this is about the widespread automatic use of frameworks in lieu of an analysis/design/build-one-to-throw-away phase.