ššš¤£ Are you kidding? Have you tried using nouveau? It works, sure, but you canāt play games that are even vaguely modern and if something uses up a bit too much RAM the entire display system starts jittering/lagging or becomes unresponsive. Source: I ran nouveau with a GTX 2080 for years. I was only able to fully ditch Windows once I fully ditched Nvidia (by switching to an AMD GPU and scrubbing every last vestige of Nvidiaās bullshit off my PC).
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).
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.
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.
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).
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 will use whatever the fuck license I want to for my projects
ššš¤£ Are you kidding? Have you tried using nouveau? It works, sure, but you canāt play games that are even vaguely modern and if something uses up a bit too much RAM the entire display system starts jittering/lagging or becomes unresponsive. Source: I ran nouveau with a GTX 2080 for years. I was only able to fully ditch Windows once I fully ditched Nvidia (by switching to an AMD GPU and scrubbing every last vestige of Nvidiaās bullshit off my PC).
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).
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, usegit reflogto 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.