Principal Engineer for Accumulate

  • 0 Posts
  • 235 Comments
Joined 3 years ago
cake
Cake day: June 12th, 2023

help-circle
  • Speak for yourself. I’m a huge Linux fan but I find it rather easy to not annoy people. Mostly because IDGAF what OS anyone who isn’t me is using. And the only time I’d ever recommend Linux is if someone technical was asking for advice. If they’re non-technical, I will tell them to not use Linux (no fucking way am I going to be their tech support). If they’re technical, they can decide on their own (unless they ask me directly).






  • 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).




  • 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 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.