6 ms·

I worked for a few years at an agency that adhered very closely to these principles, and you know what? When things started to rapidly change around 2013 everyo

• hiou 11y ago
  I watched a company almost go under(shrank to almost no employees) after exactly what you described. The BFEDs(including the CTO) refused to update their skills and the company tools/stack and the company was beaten out by competitors.
  • Azkar 11y ago
    I worked at an organization that didn't let us use stored procedures or OOP because the older devs couldn't understand them (it was a Navy contractor, so there were guys that had been there 15+ years). If you decide not to use a technology because the developers can't or are unwilling to learn them, you've got bigger problems than technology choices.
    • motional 11y ago
      I realize you were just making a specific observation about one situation, but it's worth noting that being an "older" developer (which at 15+ years experience would be late 30s) in no universe means that the developer doesn't know things. Indeed, the irony is that many shops full of junior FEDs found databases and stored procs so intimidating that we saw the rise of things like MongoDB. Even if it completely sabotages any medium or long term plan, if all you know is JavaScript and have very naive notions about the uses of data, seems great.
      • Azkar 11y ago
        There were definitely "older" devs that wanted to do those things, but they didn't have the 15 years of tenure to be able to make those decisions. I should rephrase to say that if your devs don't want to learn new things, they probably aren't in the right field.
    • omouse 11y ago
      I'm at yet another place where every one does their own thing and once you get past 2 devs this quickly becomes an issue. But heaven forbid you want to set aside time for training and making sure everyone is on the same page with regards to skill and methods. I'd say you also have a problem if one or two devs want to use a tech but aren't also willing to train the rest of the devs in them (passing around links to a few tutorials doesn't count as training).
      • cnp 11y ago
        Almost all of my "successes" in bringing people over to more modern practices centered around actual training. Meaning, creating sample apps and arguing effectively with upper management and the devs that I worked with daily.
    • 0xdeadbeefbabe 11y ago
      CRUD isn't technology anymore.
    • pc86 11y ago
      For about 4 months I worked at a place where the senior dev's first question regarding any technology would be whether or not it could be done in VB6 (this was circa 2009 or so). If it could, he'd make the decision that it just had to be done in VB6 because that's what the shop was using at the time.
      • krapp 11y ago
        I've seen PHP projects that require NPM to compile the css and js...
• copperx 11y ago
  > There are too many good ideas being born right now to risk falling into rigid patterns of thinking. The problem is that there are too many ideas out there, period. It's almost impossible to separate the wheat from the chaff. See: JavaScript libraries.
  • deleted 11y ago
    [deleted]
  • deleted 11y ago
    [deleted]
  • nkassis 11y ago
    Definitely an issue but it shouldn't prevent you from using some tools. For example, I've mostly stayed away from compile to JS languages except for ClojureScript (for personal project) and TypeScript because I see real value in both of them. TypeScript has been a massive boon to help with the largish client side app I work on professionally. Helps keeps the code base somewhat sane and easy to develop in. CSS preprocessors have been similar, cutting down on duplication that leads to potential bugs is hugely useful. Obviously taking small steps and sticking to things as long as there is no major benefit from switching helps. No reason to jump from Angular to React or whatever is new if it's fulfilling your needs.
    • omouse 11y ago
      I wish I was using TypeScript right now; we're using babel for ES6 transpiling and I've found a situation where a particular importing of a module doesn't work correctly. It appears correctly when I run it through the eslint tool and babel/webpack don't seem to complain when compiling, but in the browser it doesn't work. When trying TypeScript and CoffeeScript I never ran into issues like that.
      • cnp 11y ago
        OMG, Webpack... you love it and you hate it.... and it never gets easier!
  • 11y ago
• lojack 11y ago
  I think this is just one of those things that every developer needs a healthy balance of. BFED qualities are required to ship code on time with minimal defects. Using the latest-and-greatest technology helps drive growth as a developer, but introduces risk. For me it's a matter of identifying new technology that is valuable to invest my time into learning, and knowing when it's appropriate to learn the new technology.
• wwweston 11y ago
  > someone not ready to handle the incredible momentum of the industry The momentum of the industry certainly presents some credibility questions, but I'm not as sure as you are if they're about anyone who isn't content with a treadmill as their professional lot. Here's big quote of the article: "The BFED will develop a site based on the context of the problem and provide a solution accordingly." A BFED isn't necessarily someone who's reflexively resistant. Skeptical, maybe, because another way of describing the "momentum" of the industry would be that it's filled with tools whose adoption is often carried along by their own adoption/social proof as much as their unique merits as solutions (and that's the good case, we're not talking about the problem of hyped products whose merits might be deeply in question). And if CSS preprocessors are an example of industry momentum presenting necessity... well, I've worked on lots of projects with LESS and SASS and lots without. They can be nice, but there's no way I'd draw them inside a circle of necessity. There's a set primary problems they can address relating to keeping source keystrokes down and keeping values defined in single places. They tend to produce some of their own problems (emitted code size and source mapping). There are other solutions a good team that knows CSS and a good text-editor well can use -- good enough I'd be willing to bet on such a team's ability to keep up with (or surpass) than a team that reflexively uses LESS or SASS and considers their problems solved because that's How We Do Things Now™. What about build tools? http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/ http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt... http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool... Not a repudiation of the concept but the "momentum" of the industry has given us some questionable implementations. And they're hardly new ideas being born. They're new implementations. Any developer worth their salt is going to think first about their problems, and second about whether these new implementations should be adopted.
  • thebfed 11y ago
    This.
  • cnp 11y ago
    All of your points are good ones, but just to clarify: 1) While there are already new approaches to CSS via Webpack and CSS modules which in a way completely invalidate the term 'necessary', I've worked on some apps at said company that literally required CSS preprocessors. It would have been an organizational nightmare otherwise, considering the size and the scope of some of the asks. 2) Build tools encapsulate NPM, just like Make encapsulates bash (in a way). Coordinating a large team using shell scripts or cramming everything into package.json is never fun, though I do prefer NPM for smaller, more focused projects where each dev is on the same skill level. The point is: these tools have their purpose, there is a ton of documentation around them, and even if they are not the best tools for the job it is the frontend developer's role to research and evaluate their merit rather than dismissing them outright.
• snarkyturtle 11y ago
  All front-end devs should be able to switch to that BFED mode though, especially on pages that don't _need_ to be fancy. This helps with cross-browser compatibility and pagespeed. You could still be fancy, but only as a necessity and even then it should be layered on the BFED-side. The problem with devs nowadays is they skip the BFED and just jump into SPA's without knowing how to make a well-working website without tons and tons of sass/js.
• niutech 11y ago
  There is a great KISS principle. When you can effectively develop a website using only vanilla CSS & HTML and a bit of JS, why use some overhyped fancy tools like grunt, gulp, bower, less, sass, yeoman, etc.? I can open vim or any other code editor on any PC and start coding web pages right away, without spending hours on configuring complex toolchains, writing build scripts and so on. If web pages could be done that simple oldschool way 5 years ago, couldn't they be done the same way today? Put it this way: there are still great C99 programmers who make fast programs, are they useless only because they don't use C++14 with all bells and whistles?
• shalmanese 11y ago
  I think the ideal is a "tick tock" strategy where you're either allowed to innovate on tooling or innovate on product but never both at the same time. Reserve interesting tooling experiments for small, well defined, non user facing systems so that your team becomes familiar with the pros/cons, then apply it to large scale core functionality once you've gained the experience.