Skip Navigation

Posts
11
Comments
357
Joined
3 yr. ago

  • Possible in the sense that biological brains and human brains aren’t special. But no one will ever convince me that large language models (I’m talking about the actual math and programming that they use today for “AI”) will ever be actually intelligent.

  • Virtually every company I’ve worked at used Office primarily. And by the looks of the other comments your experience seems to be atypical.

  • If I wasn't already convinced (for separate reasons) to never, ever work there, you would have thoroughly convinced me. That sounds absolutely awful.

  • You make that sound like a bad thing

  • And it’s management’s job to multiply the senior’s estimate by 5 and +/-50% for good measure. And even then, that’s a rough estimate at best.

    Maybe using points for some planning actually works; I’ve never worked at a place that could use it for actual estimates. My estimates are entirely based on gut feel, my feeling of the complexity involved and my feeling of how much the team can get done. Over the last two years (since metastasizing into a CTO) my overall estimates have pretty much always been in the right ballpark. Which is to say, when the CEO says “We’re going to do X, Y, and Z this quarter,” I say “We’ll be able to reach about 50% completion if we work on all of those at the same time,” I’m usually more or less right.

    I’ve never worked with a dev who could make significantly better estimates than me (excluding the early years of my career when my estimates were absolutely awful). Most of the devs I’ve worked with just wouldn’t give estimates; if pushed they’d be as vague as they possibly could. The only boss I’ve had who would give definite estimates was always off by an order of magnitude (as in he thought it would be 10x easier than it was, even though he had decades of experience writing code and managing teams).

  • Most devs absolutely suck at estimating the time involved in a task. If management is setting deadlines by asking “how many hours will this task take” then missing a deadline is on management.

  • If the squash merge is too big to review then that change should have been broken up into multiple separate changes. Regardless whether you’re using pull requests or some equivalent or directly merging feature branches, if “one unit of work” is too much to review when squashed, then your unit of work is too big and needs to be split up. A unit of work should always be reviewable as a whole.

  • I constantly rebase my feature branches regardless of how many commits there are and whether I’ve pushed any of them. So long as no one else has checked out my branch it’s perfectly safe. Personally I find rebase merge conflicts far easier to work with. Traditional merge conflicts are “Here’s someone else’s changes, figure out how to merge them into your feature branch.” Rebase merge conflicts are “The main branch has changed since you made your changes. Re-apply your changes to the new base.” For me/my brain, the latter is so much easier. The only time I ever run into problems is when there are merges in the history I’m rebasing. Which I avoid by never merging into my feature branches, only rebasing.

    And if it goes wrong, just git rebase —abort. Or if you already completed the rebase, git reset —hard origin/YOUR-BRANCH. Or if you majorly fucked up, use git reflog to find a good commit and reset to that. Zero risk if you know what you’re doing.

  • I liked it ~5 years ago when it was mostly Git + project management + excellent CI. I agree that it’s gotten really messy since then. Way too many features IDGAF about.

  • Scammers spoof the caller ID. Blocking numbers doesn’t do shit because those aren’t their real numbers.

  • Removed

    githubDownDaily

    Jump
  • The tangible cost of the server it runs on and the intangible costs of the engineering time required to set up and maintain it are more than the cost of SaaS equivalents. We could but it’s a better business decision to migrate to another SaaS (since GitHub has become so unreliable).

  • Removed

    githubDownDaily

    Jump
  • I set up and maintained a GitLab instance and GitLab CI runners for five years. It was fine. I still hated it. I loath maintaining infrastructure.

  • Removed

    githubDownDaily

    Jump
  • Oh fuck off. I’m not talking about the GitLab instance. Those aren’t hard. The trauma is from other stuff, but it adds a spicy flavor of stress and anxiety to all infrastructure work.

  • Removed

    githubDownDaily

    Jump
  • It’s not as much time as it is stress, anxiety, and trauma. Being on call when shit breaks is fucking awful and my best coping strategy to date is refusing to be an infrastructure person and aggressively not giving a fuck when things are down for a day or two.

  • Removed

    githubDownDaily

    Jump
  • I'm the only person at my (small startup) company who has the skills to maintain a GitLab instance. Been there, done that, never fucking again. I HATE maintenance. We're probably going to migrate to some other platform since GitHub is intent on turning to shit.

  • Removed

    githubDownDaily

    Jump
  • What do you use for project management? What platform-less system are you using for that? Or are you saying to use a non-US platform? Do you have specifics.

  • Removed

    githubDownDaily

    Jump
  • Git allows me to write code as much as I want. But GitHub does more than just Git. If you don’t remember the details of the next task you need to work on and GitHub is down, that’s a problem. As a senior I spend a lot of time reviewing PRs. That’s considerably harder when GitHub is down.

  • I used to like that. But then I graduated college and got a job and I don’t have the energy to deal with that crap. I just want my computer to work. The only time I fuck around with things is when something isn’t working the way I think it should work and the frustration reaches critical mass. Dicking around with a non-critical system can be fun, since if I break something on it my main PC is still fine. But I’d pretty much always prefer spending my free time on other hobby projects like programming or resin casting.

  • I’d much rather be a wizard living in a dark, forbidding tower that people only approach in times of great need and when they do they bring a sacrificial offering of homemade baklava to placate me

  • Yeah, I’ve had more than my fair share of people thinking I’m a wizard because I’m good at hunting down information and applying it. At my last job it got to the point where people either thought I was IT or that I was the magic computer wizard of Ox or something. “Hey, is Jira down?” “IDK, I’m not IT…” “Can you restart it?” “No, because I’m not IT…” But then I’d tell them who could actually help them so they’d always come back to me the next time they had a problem.

  • Programming @programming.dev

    The Curse of Knowing How, or; Fixing Everything | Blog

    notashelf.dev /posts/curse-of-knowing
  • Experienced Devs @programming.dev

    Is GitHub Copilot worth it to you?

  • Programming @programming.dev

    Why is crypto.subtle.digest async?

  • Programming @programming.dev

    What search engine do you use?

  • Programming @programming.dev

    What scientific journals do you recommend?

  • Experienced Devs @programming.dev

    Self taught = no imposter syndrome?

  • Experienced Devs @programming.dev

    Systems engineering in the software industry

  • Programming @programming.dev

    What languages are well suited for testing SDKs written in multiple other languages?

  • Programming @programming.dev

    Why should I use rust (as a Go enthusiast)?

  • Programming @programming.dev

    How often does branchless programming actually matter?

  • Experienced Devs @programming.dev

    How do you organize miscellaneous tasks?