Ethan

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.

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

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.

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.

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.

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.

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.

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.

Have you not had friends or family come to you to solve their computer problems? Their problems are almost always some tedious, boring, “How do I make program X do thing Y?” It’s just a technical literacy skill check (how well can you navigate modern apps) not an actual “do you know how computers work” problem. Tedious as fuck. God save me from that shit.

If my girlfriend was a programmer bringing me some interesting technical problem, maybe. But even then, I spend 8 hours dealing with that shit, the chances that I want to deal with more of it after work are slim.

Fuck around and find out