7 ms·

> What works for us is to do the simplest thing that works, then iterate. The older I get, the more often I'm reminded that this un-sexy approach is really the

• usaphp 5y ago
  Or it could be that you just became old and don't want to learn new things anymore ))
  • jenkstom 5y ago
    This is the antivax sentiment of the IT world. It's new! It's shiny! Give me some Ivermectin because I know things other people don't! (Yes, I realize you're probably joking. I'm not, particularly.)
    • ThePowerOfFuet 5y ago
      What does ivermectin have to do with anything? Are you suffering from chronic parasitic infection?
    • rattlesnakedave 5y ago
      You have it reversed. “I don’t want the new vaccine! Who knows what the long term side effects are!” is equivalent to the technical curmudgeon. The voluntary early trial test group are the bleeding edge tech people. The Ivermectin crowd is the guy that suggests rewriting the backend in Haskell for no good reason.
    • nurettin 5y ago
      It's like you're just repeating the last inane discussion YouTube got you hooked on in order to get some ad clicks.
  • goodpoint 5y ago
    Such "new things" are just a big bunch of unnecessary complexity.
    • repomies69 5y ago
      Sometimes yes. But it is impossible to know for sure. New things still get adopted, some of those new things actually stick and provide value
      • spicybright 5y ago
        And at the very least, being old lets you be able to evaluate these new things more accurately.
        • rattlesnakedave 5y ago
          How?
        • goodpoint 5y ago
          It obviously does, but experience is not the only way: you can always read what people wrote and did in the past. It only takes some humility.
          • selcuka 5y ago
            You can, and it will certainly help, but as the old saying goes "unfortunately no one can be told what the Matrix is, you have to see it for yourself". In some contexts no amount of reading will give you the insight that experience does.
            • spicybright 5y ago
              And vice versa, too (granted my own learning style leads me to implementing what I read in little test projects, but I digress) Overall though, I'm finding the more unique sensory info you give your brain, the better it gets at solving problems in general. Even if that info isn't very related to your goal. It's a bit like trying not to be a hammer that sees everything as a nail.
  • basisword 5y ago
    Or their experience helps them have the wisdom to determine which new things are worth learning and which are a waste of time.
  • CuriouslyC 5y ago
    Some old things really are better, or at least not worse and already familiar.
  • rattlesnakedave 5y ago
    This certainly seems more common. Every time I’ve had to refactor 20 year old cruft it’s been because of engineers with the launch-and-iterate mentality 20 years ago, that stopped caring about the “iterate” part once they gained enough job security.
    • hkt 5y ago
      Blaming the engineers rather than the businesses seems.. odd. It isn't like the people writing that code had control over what the company set as priorities. If anything, what you experienced seems to be a reflection of corporate short termism.
      • dylan604 5y ago
        Quite right. The devs probably had a bunch of "TODO: This can be refactored" through out the code or at least mentally stored, yet the pointy haired bosses decided it was good enough and re-assigned the devs to other tasks.
      • ironmagma 5y ago
        That dichotomy falls apart because engineers are part of the business. If the business wants to do something but the engineers won’t do it, it won’t happen.
  • tomc1985 5y ago
    Such ageism.
• tra3 5y ago
  Choose boring technology [0]. For me, the choice is a trade off between the journey and the destination. Destination is the final objective of your project, business value or whatever. The journey is tinkering with "stuff". Depending on the project there's value and enjoyment in both. [0]: https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology
  • mateuszf 5y ago
    > Chose boring technology Doesn't fit in this case, I'd say Nix is still cutting edge. It may also be simple, but it's not easy (in the Rich Hickey sense).
    • spicybright 5y ago
      Can you elaborate more? From what I've generally heard, Nix has been a good foundation for a lot of companies.
      • mateuszf 5y ago
        As far as I know the final effect is great - getting reproducible, statically linked programs. However, learning Nix / NixOS is quite difficult - it requires a specific set of skills (functional programming, shell, Nix building blocks which you can learn from existing Nix code), the documentation is lacking, error messages are cryptic, debugging support is bad.
        • Ericson2314 5y ago
          Yeah Nix is why "choose boring" is a bit of a misnomer. The truth is tautologically unhelpful: choose good technologies. Most people have trouble separating snake oil and fads from good things, so old/boring is a safe heuristic. Nix is not boring, but it is honest. It's hard because it doesn't take half measures. It's not an easy learning curve gaslighting to you to a dead end. But taste in choosing good technologies is hard to teach, especially when people's minds are warped by a shitty baseline.
• caffeine 5y ago
  Being really good at using boring tech is better than being a noob with cool tech. So as you get older and you get more competent, the relative benefits of boring tech grow. Whereas if you’re a noob at everything, being a noob with cool tech is better. If the problems are hard enough, and you are competent, you iterate on boring tech for a while to solve the hard problems, and then it becomes cool tech.
• 0x20cowboy 5y ago
  Jonathan blow had a great take on this that really spoke to me. I can’t do it justice, but paraphrasing as best I can: Get the simple to understand, basic thing working and push the harder refactor / abstraction until later. Leave the fancy stuff for a future engineer who better understands the problem. That future engineer is you with more experience with the actual problem.
  • oblio 5y ago
    > That future engineer is you with more experience with the actual problem. With the average tenure of a software developer at a company being about 2 years, that future engineer is for sure some other poor soul.
  • xmprt 5y ago
    The way I see it, I can either prematurely use the complex solution where I don't fully understand the problem or the solution OR I use the simple solution and learn why the complex solution is needed and more importantly what parameters and specific ways I can best leverage the complex solution for this specific problem.
    • chousuke 5y ago
      Simple solutions are also easier to refactor into more complex solutions when the complexity becomes necessary. Going the other way is much harder. In simple systems, you often have the option of simply throwing away entire components and remaking them because the system is simple and the dependencies between components are still clear.
    • toast0 5y ago
      Sometimes the simple solution works well enough for as long as you need a solution, too. Often times, it just works, or the problem changes, or the company changes.
  • mikepurvis 5y ago
    This works well if you know you're building it all yourself regardless. I think the calculus does change a bit though if you have frameworks available in your problem domain. Like, there's no point in scratching away at your own web CMS just to prove to yourself that you really do need Rails or Django. Especially when part of the purpose of a framework is to guide your design toward patterns which will fit with the common, preexisting building blocks that you are likely to end up needing. If you do the design separately, you risk ending up in a place where what you've built isn't really suited to being adapted to other stuff later. For a humble example of this from myself, I built an installer system for Linux computers— initially very simple, just a USB boot, perform partitioning, unpack a rootfs tarball, and set up the bootloader. Then we added the ability to do the install remotely using kexec. Then we added an A/B partition scheme so there would always be fallback. It got more and more complicated and fragile, and the market around us matured so that various commercial and OSS solutions existed that hadn't when we first embarked on this effort. But the bigger and less-maintainable the homegrown system became, the more features and capabilities it had which it made it difficult to imagine ditching it in favour of something off the shelf. There isn't really a moral to this story other than it would be even worse if we'd built the in-house thing without doing a thorough evaluation of what was indeed already out there at the time.
• api 5y ago
  https://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html https://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer...
• asiachick 5y ago
  Hmmm, me, I want batteries included. Why I don't I have continuous deployment? Because that would require work doing something I don't have time to do. Why don't I have a staging server? Because more work. Why don't I have backups. Again, more work. Why don't I have metrics so I can see where my bottlenecks are? More work. Why don't I have logging? More work. Why don't I have a way to do updates without taking the servers down? No time, more work, too complicated. Sure I can write a server in 5 lines of code but adding all that stuff is many many many person years of work and plus I'd have to go through all the learning pains of doing it wrong, crashing things, losing data, before I'd add it correctly. I want some existing solution that domain experts already created that do things right. It has nothing to do with "sexy/unsexy". It's unsexy to use UnrealEngine. It's sexy to write your own. But unsexy ships while sexy is spending time recreating stuff that already exists, unsexy is moving on to the actual content and shipping.
• ironmagma 5y ago
  The thing is, “simple” is not trivial to discern. What looks simple to a beginner may look quite hard to maintain to an experienced dev. “GOTO” being the obvious example.
• _0w8t 5y ago
  If a solution has been working for 20 years, then by Lindy effect there is a good chance it will be relevant in 20 years as well. Basically an old but still actively used software or principle implies that it has being compatible with a lot of new things in past and, as such, is rather universal. With new software one does not know if it is the one that will survive challenges from even newer software.
• kitd 5y ago
  The simplest thing for "dev" is not necessarily the simplest thing for "ops" though. I'm in my late 50s and been developing for 35 of them. Honestly, containers are not rocket science and solve a mountain of ops-type problems simply. If you really are only developing a single instance to be deployed in-house, then you may find you don't need them. But as soon as your instance might possibly get exposed to more than one environment, they're a no-brainer for me.