15 ms·

And here's the trick to not building shit software: don't build shit software. It's a crude way to put it, but the reality is that you can build bad websites in

• afarrell 7y ago
  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 software engineer, there's no information there.
  • 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?
• jorblumesea 7y ago
  Do you think anyone goes into a project thinking: "I'm going to build some complete garbage"? Shifting project and business requirements, scope creep, poor design choices and lack of competence all contribute to what makes bad software.
  • johnisgood 7y ago
    Eh, many people think "let me shit it out ASAP for those quick bucks", and then there it is. I would say not giving a damn about quality is identical to your quote, feels a bit more passive, but still.
• avgDev 7y ago
  I agree as I build some terrible applications in .Net MVC, which is a decent framework. I think you have to build shit software not to build shit software. First, professional web app I developed 3 years ago is still being build upon now. Even though it is pure garbage and I hate touching it, because I "made it work". As I gained experience and got burned because I did something a certain way I slowly but surely looked for alternative approaches. Now 3 years later, I'm building an app with layered architecture, proper separation of concerns, dependency injection. Plus, before I start hammering code away, I think about what is the number 1 priority for a piece of code, am I gonna use it once and forget it? Will I use it all the time? Then, proceed accordingly.
  • ct520 7y ago
    " am I gonna use it once and forget it? " Always comes back to bite me in the a$$. Also taking over projects that were built this way always a pain. Now and days I just refuse to do the work if they pushing to cut corners.All in all I say my quality of life and the sense of being proud of work has increased.
    • avgDev 7y ago
      I do agree with you. Now that I think of it I rarely write "use it once and forget it", because as you said it will come back to bite.
    • benbristow 7y ago
      "am I gonna use it once and forget it?" Isn't the saying, YAGNI (You're not gonna need it)?
      • Izkata 7y ago
        YAGNI is meant for a "this could maybe be useful" scope-creep feature, that seems simple to add but doesn't have a reason to exist. (Aside, flip the contraction to get the acronym - "you aren't gonna need it")
  • JohnBooty 7y ago
• enraged_camel 7y ago
  >>It's a crude way to put it, but the reality is that you can build bad websites in any framework The point of (well-designed) frameworks is that they act as “rails” and make it difficult to make bad decisions. They also make it easier for people on a team (or people who maintain the project after you leave) reason about your code. Therefore, as far as I’m concerned, not using frameworks is a huge red flag. edit: bring on the downvotes!
• jeoeo0md 7y ago
  Agreed. Doing things in a computer is just organizing the information you have at hand. That could be files or symbols in files that defined a set of operations a computer should run on symbols in another file/db. This isn’t magic. But it’s susceptible to social behaviors and those are “growth every quarter, demand, demand!” so we latch onto buzzwords or trends because some VC funded dork thinks their way of laying out a todo app is best. IMO anyway. Having gone freelancer and flipped the bird to corporate life, I’m way happier and write little code: not having to learn new frameworks makes when to write more generic, re-useable, dependency less, code way more obvious. And I don’t have to worry about a Github repo going inactive. We’re making it harder with tent pool frameworks due to information overload. When the work is information organization, less is more. A parallel to all that “more data is just a bigger security liability.” theme that popped up a couple years ago. It’s also a progress liability.
• weberc2 7y ago
  These are strawmen arguments. No one is arguing that libraries matter more than organizations/teams, and no one is arguing that it's impossible to build good/bad frameworks in any given language/framework/etc. You can (and should!) solve the problems with your teams and your tools. If you pick a tool that solves problems you don't have (probably because it's new and shiny), there are probably hidden costs that you didn't consider and you're probably going to slow your team down. How much that slow down is going to affect your project depends on how significant the slow-down is and how sensitive your project is to developer productivity (the widely used internal tool with the big budget at BIG CORP is probably safe, but the team at the small startup with the shoestring budget and fierce competition is going to feel that friction in a bad way.
• PopeDotNinja 7y ago
  Define shit software.
  • jayess 7y ago
    Whatever the last developer did.
    • PopeDotNinja 7y ago
      That's pretty much the truth.
• rubicon33 7y ago
  That is THE benefit of a "framework" - It locks you, and future developers, into a paradigm. It might not be a "best" or even "good" way of doing things, but, adopting a framework helps keep everybody writing the same 'shit software'. Consistency, it turns out, is key. That's because (as others have pointed out) all software is ultimately shit software. If you wrote it, chances are you don't think it's shit, but everyone else does.
• crimsonalucard 7y ago
  What if I told you there is a theory about good module design and if you follow the formal rules of the theory (not design principles mind you there's a huge difference) good and organized designs can emerge from just knowledge of the theory itself?
  • dlcmh 7y ago
    Any material you’d recommend on this subject matter?
• Aeolun 7y ago
  I’d argue that it depends mostly on the organization. A great developer is still going to produce shit if the organization doesn’t work with them.