3 ms·

Sure, you can do that for your hobby projects. But "at work" you generally have these decisions made for you. And these decisions have changed over time for the

• skrebbel 11mo ago
  > But "at work" you generally have these decisions made for you. The idea that most employers make terrible decisions now, and amazing decisions back in the day, is plainly false. The author vividly recollects working at a decent Java shop. Even there I strongly doubt everything was amazing as they describe, but it sounds decent indeed. But plenty businesses at the time used C++, for no good reason other than inertia, usually in Windows-only Visual C++ 6-specific dialects. Their "build server" ran overnight, you'd check in your code in the late afternoon and get your compile errors back in the morning. The "source control" worked with company-wide file locks, and you'd get phoned your ass back to the office if you forgot to check in a file before leaving. Meanwhile, half the web was written in epic spaghetti plates of Perl. PHP was a joy to deploy, as it is now, but it was also a pain to debug. If you care deeply about this stuff, find an employer who cares too. They existed back then and they exist now.
  • vdupras 11mo ago
    The "terrible decisions" of yore hold no comparison to today's "terrible decisions". It's not the same ballpark, it's not the same sport.
    • deleted 11mo ago
      [deleted]
  • mexicocitinluez 11mo ago
    Amen. We love the idea that we don't have any agency in this field and we're constantly being pushed by the mean baddies at the top.
  • CyberDildonics 11mo ago
    Did people really only compile once a night in the days of visual studio 6? There were pentium 2s and 3s back then.
    • vessenes 11mo ago
      It was definitely on the order of hours for large code bases - the Microsoft Excel team passed out punishment “suckers” for those who broke the build - causing 100+ people to not have a new working build to look at and test. Linux kernel compiles in the 1990s were measured in hours, and that codebase was tiny compared to many. So, yep, builds were slow, slow enough to have an entire xkcd comic written about them.
      • CyberDildonics 11mo ago
        Entire builds being slow isn't the main point though, it's iteration time from changes. I have a hard time believing people were working on a single compile a day and building an entire huge program on every iteration. That's the whole point of compilation units.
    • skrebbel 11mo ago
      In large C++ codebases of mediocre quality (the example I'm referring to is a manufacturer of large complex machines), yes. People would compile their local unit locally, of course (a "unit" would be a bunch of files grouped together in some hopefully-logical way). But they wouldn't be 100% sure it compiled correctly when integrated with the larger codebase until the nightly build ran. So like if you didn't change the .h files you were pretty sure to be in the clear, but if you did, you had to be careful and worse-case-scenario do a 1-day-per-step edit-compile-test loop for a week or so. I'm not entirely sure how they managed to keep these compile failures from hurting other teams, but they didn't always (I think they had some sort of a layered build server setup, not too dissimilar from how GH Actions can do nightlies of a "what if this PR were merged with main now"). Visual Studio 6 itself was pretty OK actually. Like the UI was very limited (but therefore also fast enough), but compiling smallish projects went fine. In fact it was known to be a pretty fast compiler, I didn't mean to suggest that VC++6 implies overnight builds. They just coincided. In fact better-structured big-ish C++ projects (pimpl pattern anyone?) could probably recompile pretty quickly on the computers of the day.
  • zozbot234 11mo ago
    > Their "build server" ran overnight, you'd check in your code in the late afternoon and get your compile errors back in the morning. This. Let's keep things in perspective when people complain about long Rust compile cycles. And even that's a whole lot better than filling in paper-based FORTRAN or COBOL coding forms to be punched into cards in the computing room and getting back line-printed program output (or a compiler error) the next week.
    • deleted 11mo ago
      [deleted]
    • s_ting765 11mo ago
      Rust's notorious compile times sticks out like a sore thumb partly because other system languages can run laps before your Rust build is done. And also because everyone and their grandma swears Rust is blazing fast. Until you have to compile the program without prior build cache or start a build in a CI pipeline.
  • mamcx 11mo ago
    This is like economic growth: First bad, then upwards trajectory, then now in free-fall You are describing it: Things in programing were bad, then suddenly all in the upside UNTIL it start to coming down. Is not a refute of the problem. Is to pick a moment were both were bad, and like all the discussions about tech, MASSIVELY ignore that MASSIVE internet with MASSIVE money with MASSIVE backing is worse than before. Is like people complaining that pistols on the wild west kill as do nuclear weapons, ignoring the massive difference in size and blast damage
  • pjmlp 11mo ago
    Not everyone has the privilege to live in world regions where there is a wealth of options in job opportunities.
• ongy 11mo ago
  jubernetes?
  • skrebbel 11mo ago
    jubernetet
  • zozbot234 11mo ago
    That's the "let's rewrite k8s in proper enterprise Java like it was meant to be in the first place, none of this Golang nonsense" project.
    • nunez 11mo ago
      funny enough, I believe Kubernetes before v1.0 _was_ written in Java!
• Otek 11mo ago
  > And these decisions have changed over time for the wrong reasons. Have you ever considered that you don’t understand why those decisions were made and that’s why you think they were made for the wrong reasons?
  • fainpul 11mo ago
    I simply don't agree with the reasons, while you seem to imply that all decisions made, are good.
  • Sharlin 11mo ago
    The reasons are always the same. 20% because some changes are actually improvements, and 80% cargo cultism where if you just build the right containers and chant the correct YAML incantations, you too will become a Google… followed by the phase where everybody just keeps doing these things because they organizationally don’t know any other way anymore, until the next big trendy thing, which does revert some of the issues of the previous trendy thing, but introduced a new set of already solved problems because this profession is incredibly myopic when it comes to history.
    • davidw 11mo ago
      If Google does it, maybe it'll work out for my small business, right...?
• jagged-chisel 11mo ago
  > if we say k8s, we should also say j8t It’s that one extra spoken syllable that pushes it into k8s I guess. ¯\_(ツ)_/¯
  • fainpul 11mo ago
    But it's only used in written form. You don't actually say out loud "kay eight es", do you?
    • arccy 11mo ago
      kate's
      • fainpul 11mo ago
        Seriously? What if you have a Kate in your team?
        • jabbywocker 11mo ago
          Then she ends up taking the blame for causing lots of headaches from people that can’t parse context
          • lloeki 11mo ago
            It's sometimes Kate, Jason, or Yamal. But it's always Dennis.
        • 63stack 11mo ago
          The automated system rejects their CV when applying obviously
    • phantasmish 11mo ago
      Haha, oh my, no. That would be silly. Clearly it’s “Kates”. Like “sk8er boy”.
• marcosdumay 11mo ago
  > j8t Javascript? That would solve the trademark problem...