29 ms·

The trouble is that "don't build shit software" isn't actionable advice on how to avoid building shit software. For someone seeking to be a more skillful web so

• justbaker 7y ago
  It means the underlying problem is not the tooling, but the use of the tooling. In other words, "I can choose the correct tool but still fail from poor approach of problem."
  • orf 7y ago
    If the tool allows you to shoot yourself in the face without warning, and has a reputation/history of doing it to a lot of other people, then the tooling is indeed the problem.
    • chrshawkes 7y ago
      Nobody is building anything unique with the same tool. I get your point though. The more handholding these frameworks do, the less we learn it seems.
    • MadWombat 7y ago
      Most tools out there allow you to shoot yourself in the face. In this case, the guy replaced client-side JavaScript (very notorious for its amazing face shooting abilities) with server-side PHP (also, a very notorious face shooter).
      • jdnenej 7y ago
        The real metric of quality is does it do what you expected. PHP is a gun that sometimes shoots backwards with no sensible reason where as rust has a gyroscope that can work out when the gun is pointing at your face and requires that you turn off the safety first. Entire classes of bugs simply don't exist in better languages.
        • MadWombat 7y ago
          Well, yes. You can write a web application in Haskell and enjoy the beautiful and flexible type system, first order functions, monads and all the other wonderful things. But you shouldn't. Because when you leave, the client will never be able to find someone to maintain the damn thing and chances are they will hire someone else to rewrite it yet again in PHP. And possibly hire someone to make a voodoo doll of you and stick pins up its ass.
          • afarrell 7y ago
            You can also write your application in Ruby or Python or Java or Go
  • TAForObvReasons 7y ago
    There's no guarantee that good approaches in 2019 will still be good approaches in 2029 and beyond. OOP was considered a good approach many years ago, and now in many circles it is derided and bashed.
• void445be54d48a 7y ago
  Just don't build software and then we won't have shit software
  • gen220 7y ago
    I know this was probably meant as tongue-in-cheek, but I think this is a powerful idea. I think it should be a more widespread idea that people should aim to leave a company with a net-negative `cloc` contribution.
    • johnchristopher 7y ago
      Actually, that's a well know mantra: the best code is no code.
      • keithnz 7y ago
        no code is also the fastest thing you can do!
      • BubRoss 7y ago
        People don't know what that means though. It is only helpful after explaining to shoot for deeper yet simpler rules for your system along with identifying what can be separated from execution as static data.
        • Frost1x 7y ago
          Part of that mantra also falls under problem solving in general. Not every solution needs a technology solution. Sometimes fixes can be made in processes or policy in general. Many jump to technology solutions too quickly and I feel this is lazy and often passing responsibility for someone else to fix a situation.
        • johnchristopher 7y ago
          Yep, I can see how beginners or god-level guru could turn that into a thousand characters one-liner.
• castis 7y ago
  It most certainly is actionable advice, but it's usefulness depends on how well you take blunt advice.
  • enraged_camel 7y ago
    What exactly is actionable about it? Just curious.
    • castis 7y ago
      Google the inverse question "how to build good software" and dont stop reading until you die?
      • SketchySeaBeast 7y ago
        That's like googling "how to eat right" - it's going to be 99% unhelpful and contradictory.
  • chrshawkes 7y ago
    Unhelpful advice. Typical programmer up his own ass bullshit really. Oh that ways not good. Well what's good? I don't know, just not that. Look at how many clowns criticize jQuery these days as an example of garbage software.
    • benbristow 7y ago
      jQuery isn't garbage as per se. It's a great library for directly querying & manipulating the DOM. Trying to make web applications with it is another story though. The lack of any state management is a nightmare, hence declarative frameworks/libraries such as React/Angular(JS)/Vue/Svelte etc. etc. came along.
      • lacampbell 7y ago
        The lack of any state management is a nightmare What makes the lack of state management a nightmare in the javascript world, but a complete non-issue when doing .NET or Qt apps? As someone who started with desktop apps and then moved into web dev, I never really understood why Javascript developers wanted a library to help them manage state.
• madeofpalk 7y ago
  But "Javascript makes you build shit software" isn't actionable in the sense that its definitely incorrect.
  • gameswithgo 7y ago
    There is some truth to it. The whole ecosystem encourages a lot of things that are bad for developing simple, stable, good performing systems. I don't go anywhere near that world unless I have to for these reasons. You get all the downsides of dynamic language ecosystems, with worse compile times than Rust (webpack etc).
    • rhengles 7y ago
      In my opinion, the biggest complicator there is in javascript land is Webpack and similar loaders. They do absolutely everything in the name of optimizing performance in production, things which even the "development mode" don't simplify. I developed my own custom scaffolding for Vue projects[0], which is a lot simpler and customizable. It even allows you to develop Vue projects without a build step/tool, you save and reload. Yes, there are tools that reload the page when you save, but I don't think they're worth the complexity. It could be further improved to actually compile/build when you actually want to deploy, I hadn't the time or a strong need for it yet. But when you are developing, things need to be simple, I think you need to know everything that is happening in the browser so you can resolve any bug with much more speed and confidence. [0] https://news.ycombinator.com/item?id=20270816 https://news.ycombinator.com/item?id=20270816
    • scarface74 7y ago
      I try to know just enough of the $cool_kids front end stack to pass an interview, but I’m very honest - I don’t like front end development and that’s not my forte. Besides, front end developers are a dime a dozen. Your typical software as a service CRUD company, is looking for mere competence and pays at that rate. I have no interest in competing in a commodity market.
  • cwp 7y ago
    It's not Javascript that makes you write shit software. It's trying to write software that runs correctly on a wide variety of platforms that you don't control. reaperducer's rewrite was an improvement, not because he replaced Javascript with PHP, but because he moved all the logic to the server, which is a single environment he controls. He could have used Node instead of PHP and achieved the same thing.
• jfaat 7y ago
  Sure but for that person is “use a no-nonsense lamp stack” going to result in a better outcome than them just starting with react?
• thaumaturgy 7y ago
  This is fundamentally because our industry is built on opinions, not standards. You talk to one software engineer, and they'll say, "that's built in PHP, so it sucks; it should have been built with npm, obviously." Then you talk to another and they say, "I can't believe they built that with npm, the package management system is just terrible and the whole mess is bloated and there have been a ton of security issues. They should have used a static generator instead." And on, and on, and on. Now compare this to a mature industry with real engineers who are able to say things like, "sure, that material might not be the most durable on the market, but unobtainium would have added $35 million to the project cost and ongoing maintenance costs would have gone up by another $5 million / year." That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project. Nobody's bothered to do that work. We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects. This is absolutely shameful IMO, and the reason why I cringe a little inside whenever I see the words "software engineer".
  • pfraze 7y ago
    Not that software can't improve on this front, but I'm pretty sure that every engineering profession has its fair share of opinions and disagreements around them. Heck, my dad's a general surgeon and he's constantly debating with other surgeons over things like whether a procedure should be out-patient or which procedure has the best outcomes. They have a better concept of outcomes, which helps them make data-driven decisions, but they also have a higher risk profile which slows down the innovation process. I agree with most of your premise, but I think you overstate it a bit. Like the GP's point above, it seems like you're describing bad engineers. In the good web dev agencies I've worked at, they work pretty hard to make informed decisions which stay within budget and timeline. It doesn't always happen, but that's not just due to poor practice.
  • testy3 7y ago
    There are reasons why other industries are more mature, like: they've been waaaaaaaaay longer than CS/SE they do not change so robustly & fast in short peroids of time. >We can't even accurately estimate the cost of a complex project given our choice of tools Let's do not pretend as if that was limited to our industry.
• 6gvONxR4sf7o 7y ago
  I think that's the point. If you're looking for actionable advice in terms of "hammers are better than screwdrivers" you aren't going to find it. You'll find people purporting to give that advice. Look elsewhere, like "best practices for hammers" or "when to use a hammer instead of a screwdriver" or better yet "best practices for working as a team."
• krageon 7y ago
  Build software that you would still want to work on five years later. That usually means tests (that aren't so embroiled in the technical details they break with every trivial change, but instead describe the business logic that is important for your application), sensible abstractions, etc. Usually from there you can select some paradigms that make sense for you. Fundamentally, all of it is a matter of opinion. You have a million options and they are all correct. Don't take a million options at once, practice a lot, understand your problem domain. You won't write something perfect every time but you'll write something a whole lot better than if you were using a million frameworks instead of real thought.
• cjfd 7y ago
  There may not be actionable advice for someone hiring a software engineer if that person knows nothing about software engineering. However, I would argue that that person is in a bad position no matter what. There is actionable advice for a software engineer here insofar as the general 'shitiness' of software is due to a lack of discipline on the part of the software engineer. Having witnessed inexcusable practices like functions that contain 10000 lines 'don't build shit software' sounds like very much actionable advice to me.
• hhas01 7y ago
  The key to being a competent software developer is really, really simple: Learn the Business. Because if you can’t/won’t/don’t understand the problem domain, how can you expect to solve problems in it?