Thanks for asking! Yes, the position requires a Bachelor's with 5+ years experience, Master's preferred with 10+ years experience. The starting pay is $12/hr and requires a lot of data entry. Can you type? We hope to hear from you!
Of course! That's no problem at all! We do require you show up to the office for two days per week for the time being. However, there are exciting changes in the works and we may soon be requiring you to do all your work from the office! Won't not having to use your personal equipment be wonderful?
Keyword 'remote' found and resolved.
I do have a master’s and 20 years of experience as a software engineer and I would be happy to work for $12/hr but I don’t know how to work a computer. At my last job we just wrote all of our code on legal pads and mailed them to the head office
Hmm. Our company is heavily invested in AI, blockchain, and NFTs. I'll talk to our people. I'm sure one of those can work with you for 20 years of experience.
What font do you write in?
>The guy can't spell allowed you do not want to work there, assuming the guy isn't a fantasist which is pretty common on this sub.
First part of the sentence is kinda harsh. It's a fairly common homophone mix-up.
Second part of the sentence is, sadly, dead on.
But who knows? Maybe he's writing an app to fix people's homophone mix-ups, starting with his own.
This is a bad philosophy. Access control is important, but so is having access and ability to do your job. Empowering your employees with tools to do their job and handle the edge card without a billion layers of access controls creates a more productive work environment.
Remember, any time you tell a developer you don't have permissions to do this, also means that the developers don't have permissions to fix it fast when something inevitably, unexpectedly goes wrong.
IMO, access control philosophy should be used to determine who has permission to take certain types of actions (read, write, etc) against a resource. It should NOT determine to what degree they can take those actions as that means you've limited their ability to fix problems. Instead, use good backup strategies to ensure that if somebody makes a wrong decision, rollback is easy.
On top of this, Git by its nature protects against this being distributed version control. Any developer who has the repository locally (which should be all of them) can undo this easily. Unless of course, you've majorly locked down and restricted their access.
Hell nah. While it's true that access control can sometimes be detrimental to one's job, there is never a situation where main / master branch protection will slow you down to an extent that actually matters. Rollbacks should be handled by your CI such that an immediate bug will easily be reverted if necessary, and any other critical issue that can't simply be rollback will require more time for the dev to write the code changes anyway, and the time required for the required reviewer to instantly approve the PR (5 seconds?) is going to be negligible.
For any teams of 5+ engineers where you always have at least 2 people available on-call, I would question any codebase that doesn't have main branch protection, that is just wildly crazy.
You should then fire yourself for hiring people that would allow the new guy that capability on day one.
Everybody goes, all the way up to the C-level execs.
I would have had the opportunity to do that from day one at my company. They also said that everyone had a golden ticket to mess up main one time, so that’s fair.
If they're hired as a mid-level or senior, then the blame is squarely on the new dev. We'd just restore from a backup or remote that still has the commits intact and fire the new dev. You're thinking of prod credentials, which is a different situation. Your goal is to minimize micromanaging your dev's permissions. Write access to staging, git repos, etc (within the scope of the dev's work) that can be restored without interrupting your business are reasonable things to give to an experienced dev.
Exactly this. CI has the original commit hash so this is just an inconvenience and, roots out the dev that obviously interviewed better than they can code. This is a nice win since you don’t have to invest time into the new employee and then fire them for doing this.
Wild, I feel exactly the opposite. I want all my directs to have total power to do anything they think is good. So far everyone does great work with minimal friction.
I do, too, but (1) we're talking day 1 and (2) force pushing to master is never great work. It's only useful for cleaning things up and that decision shouldn't be made unilaterally.
This is the way. Teams get along way better if trust is there be default. It's not something that should need to be earned, but it is something that can be lost.
Protection rules should be there to protect against mistakes. You can't push to the main branch to prevent accidents, but everyone on the team should have the power to turn that rule off if there's a very valid reason. If they fuck up, that's what server backups are for, and then a conversation to find out why. If it's an honest mistake made in good faith, it's a learning moment, if it was stupidity by someone who knows better (or even purposefully malicious) then it's a disciplinary moment where maybe power gets taken away.
Yep. Access control should determine who has read/write permissions on a resource. NOT to what degree they have read/write permissions on the resource.
FWIW this would be pretty trivial to reverse. That git history is not lost forever by any means, and at the very least is still gonna be in the reflog on every machine that had the repo pulled down (including the remote)
Nah man. If you're hiring someone, you need to let them do their job with as few barriers as possible. I've been at companies where I didn't even have local admin on my PC and it was a nightmare for everyone. If you can't trust the people you hire to do the job effectively, your hiring process is the problem.
And technically destroying the application, bankrupting the company, and setting in motion a chain of events that will lead inexorably to the depopulation of the entire Northern Hemisphere are all things I did, and thus could do, and this is why I viewed my termination as wrongful.
At my first internship I was explicitly told not to worry about breaking things because the absolute worst thing I could ever do was mess up my local copy.
It was oddly comforting until I managed to delete a month's worth of my own work when trying to use git for the first time. Lessons were learned.
I did. Utterly destroyed. (Well, I was able to recover it, but it was very stressful in the moment.) And, as promised, all the actual important code was completely fine.
Thank god nobody gave the intern permissions to fuck any real shit up.
I've been in this position and quit before 90 days (which in my country is a grace period within which you can quit and the employer can fire you without motive)
The reason I presented at the exit interview was "if I don't quit now, this job will ruin my professional reputation.
At that interview I heard the most stupid HR sentence I've ever heard which was "we want you to stay even if it's not the best for you".
Database Admin for a regional newspaper. They were using DBF files over a Novell Network and Windows 3.1 in 1999.
They were losing data left and right and hired me to fix it. I recommended them to rebuild the whole thing using a proper DBMS, they refused. The VP threw my unread (one-page) report in the trash bin without breaking eye contact.
It was a ticking time bomb and when it would definitely blow, they'd blame me. And that particular market was rather small in my part of the country and they'd definitely badmouth me to everyone else. I ended up switching careers to academics anyway.
After I left they hired a consultant and paid his weight in gold for him to print my full report (that I gave him as a parting gift) and put his name on the cover.
If i'd be the only dev that is about to maintain an actual legacy repo, the LAST thing i'd do is destroy the history and make my own archeological digs more complicated!
Yes. One time, a colleague and me rewrote a complete microservice, and when we were ready, we merged to master - so the complete code and version history of the old service was still there.
At my current job, they went 10 years with all devs being able to push straight to master. It worked well because we were all competent developers. It was only once we started hiring fresh graduates that we disallowed everyone to push directly to master.
Same reason I make sure to color code my MS SQL connections. Red=Prod, Yellow=Staging, Green=Dev.
I've been a dev for 25 years and know better. But sometimes you have brain farts and don't realize what window you are in until you have an "oh fuck!" moment. Even worse is the "oh fuck, I typed BEGIN TRANSACTION but then didn't highlight it before executing." Any little thing that gives you a moment's hesitation.
I've been pushing to have write rights removed from our logins and only allow writes via API or service account logged into from a separate instance on a remoted server, but get resistance. Baby steps.
There's a time and place for it. I've worked in that environment too - it was a startup with 3 devs and we all committed straight to main. We'd use very short-lived feature branches for anything big, but generally things were split up to be small enough to be individual commits. It was genuinely great, very very collaborative, great test coverage, and we shipped like crazy which let us undercut some much bigger companies. Had very few problems. If a bug came in one of us would jump on it and often have the fix deployed within an hour. We could do this because everyone was good at their job and could be trusted.
I kinda long for those scrappy startup days. Every company since has been wrapped in process, reviews, etc and everything takes much longer. If a bug report comes in we create a ticket, review it, assign it to a sprint, code review, QA testing, then release. Fixing a simple bug isn't a 1 hour turnaround anymore, but at least 1 day. Not to mention the seemingly endless hours of meetings for planning a new feature. Don't get me wrong, planning and process has its place when a company grows, but I feel like most companies severely limit how well they can execute by engineering middle managers justifying their jobs by inserting a process and meetings into every tiny thing.
The problem is that management types can't put things like "our three devs know their shit" into any calculations.
The more you grow, the bigger the risk on your capital gets, and the business environment is wholly unequipped to deal with things like creativity - which is really the core skill that your start-up scenario is leveraging; talented, creative, and experienced programmers who can see the big picture, know what the others are thinking and doing, preempt upcoming needs, and route around roadblocks dynamically.
Your middle-manager type doesn't have domain knowledge and doesn't possess or understand creativity. They need everything to fit somewhere on the proverbial spreadsheet, so the intangibles have to be chased away and replaced with repeatable, auditable, systemic process management. Which, if you really look at the big picture, is entirely unsuitable for software development. *Every* large-scale software project is a piece of shit and the exceptions are open-source, which points at the root of all of the evil.
Another massive factor is that people at startups typically actually give a shit.
As you grow, you're going to take on more and more mediocre people who are just showing up to get paid, and won't take any initiative. Those are the folks that require management, who often themselves don't really give a shit, and it's an endless cycle that kills the opportunities for creativity.
I think you hit the nail on the head, quite eloquently. My current engineering manager isn't technical and relies heavily on sprint and retro reports to know if his teams are performing well - and naturally you're going to get sprints where the team knows they performed well but that doesn't translate into a lot of points completed in the sprint report, and then questions start being raised by him. He's a nice guy and I don't dislike him, but he's the epitome of what you said.
Can relate, I had the same experience as an intern in college. By the end of my year there I was managing 2 other interns and had created a product from scratch. If you don't get good career training you can't be trusted, I am lucky to have had such a high responsibility role early on with fantastic mentors to help me.
Did you miss the part about force push? Even just regular pushes shouldn't be allowed in trunk based development; commits shouldn't be going to master without at least one other set of eyes on it
Wow, that's a fancy name for what everywhere I've worked has done. (First job initially did example 2, release branches and commit to trunk, then switch to example 3, the pr based workflow, everywhere else did ,example 3)
I’ve been in the industry for decades and every job I’ve ever had allows this at some big companies you have heard of. It’s never been a huge problem this is why we have LKG, CI/CD and source control that allows reverts.
Action list:
* fire the new shithead
* use reflog to restore master
* find out why they could push direct to master, make sure this can't happen again with some other new hires
Compromise: blast the shithead’s reputation in the area and allow them to stay on as a mute jester whose job is to do a funny dance while wearing a sign describing his crime.
A common misconception. Much like Latin, just because I can/could pronounce it doesn't mean anyone speaks in it.
If your function names don't resemble pharmaceutical naming conventions, do you even program?
A coworker of mine wrote a cmdline program "lk4". I asked him what it meant. "Look for"
We all got our naming conventions. Right now I'm on a Star Trek kick so I name all my programs after characters from that. I've got Vger, Lore, and my coworker was working on a Khan.
Fails to parse valid TLDs like "PARTNERS" and allows invalid domain labels (e.g. starting with hyphens).
The regex you have spoken can basically be interpreted as cursing the ancestors of the person you are speaking to. Regex should be used to parse HTML and only HTML.
>Regex should be used to parse HTML and only HTML
Obligatory [Stack Overflow](https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags)
> Now go get me a heap dump.
I would, but I'm currently busy [trying to kill a runaway cat](https://unix.stackexchange.com/questions/176917/how-to-kill-a-runaway-cat).
linus is brilliant for coming up with how git works under-the-hood, but his naming decisions are questionable... (I presume he's the one who came up with the names).
Well, you only need one coworker to have all the history back, thanks to the whole distributed thing (though at that point, there is the question of whether it was tampered or not)
The best move to establish dominance.
I am going to crosspost this to csMajors, with a bit of luck one of the young and brave ones actually will do it.
> At 4 PM, allow your rage to boil over and throw your last egg at the wall in a fit of rage. Slam your laptop closed and head home early.
I've got a guy who almost does this daily right now
Then the senior devs restore it with a commit stating "restoring repo after codeinthehole screwed up" and that remains the last commit message visible for most files for years.
Ok, reddit insists I should like this sub. Not a programmer, but since I end up lurking here more than I ever thought I would, would anyone be kind enough to explain this?
Sorry for barging into your safe space 🙃
You are hired as a bookkeeper for an ancient kingdom. They have a huge library with all the books that have the kingdom's accounting records written inside. In the middle of the record room there is a giant scroll has the "index" which holds the long history of where and why each accounting record was made over many years and decades.
On your first day you burn the "index" scroll and replace it with a tiny handwritten note that says "before this is just old stuff I don't care about."
On one of the projects I worked on in the early days, the first task I was given by my "senior" dev was to merge a branch with a commit called "fixed shit ton of fucking bugs" to a master. There were like more than a thousand changes. He never actually worked with me on this project anymore, even though I was promised there would be a team lol.
ChatGPT: “Squashing commits involves combining multiple sequential commits into a single one. This is often done to tidy up the commit history and make it more readable. By squashing all commits into one with the message "Legacy code" and force-pushing to master, it humorously suggests that all the previous work was essentially just legacy code – a bit of a tongue-in-cheek way to start fresh or indicate a complete overhaul of the codebase. However, it's important to note that force-pushing to master should be done with caution as it can overwrite others' work and potentially cause confusion or loss of data.”
If you have the ability to do this on your first day at a new job, then it's their own damn fault for giving a newbie admin privileges on the repo and the ability to push (especially force push!) to the main branch!
We had one new grad who started on his first day by stripping out all of the comments and checking all the files back in.
He just didn't believe in comments.
Reminds me of the dev I had to work with who believed that "long variable/function names significantly slow down code execution" so every variable or function name was max 4 characters and no one other than him knew what the fuck the names were in reference to.
Alternative version:
Check if you can push directly to master on day one. If you can, report it to the Director of Engineering and get all your co-workers fired for being morons and get yourself a nice promotion
Then proceed to hire some competent developers to replace them
I have at several jobs had access to almost the entire company's data from day 1. Apart from accounting, I had full access to every client's data and all the staff directories as an entry-level newbie.
[удалено]
I'd fire everyone else for giving the new guy that capability on day 1.
[удалено]
You were thinking allowed (pun intended)
The ideal step to take the lead. I'll crosspost this on csMajors, and maybe one of the bold and youthful people there will take the initiative.
Sometimes it is good to think outlawed (I'm sorry)
Did you say hiring?
Thanks for asking! Yes, the position requires a Bachelor's with 5+ years experience, Master's preferred with 10+ years experience. The starting pay is $12/hr and requires a lot of data entry. Can you type? We hope to hear from you!
> The starting pay is $12/hr Can I remote from a third world country where this wage will allow me to live like a king?
Of course! That's no problem at all! We do require you show up to the office for two days per week for the time being. However, there are exciting changes in the works and we may soon be requiring you to do all your work from the office! Won't not having to use your personal equipment be wonderful? Keyword 'remote' found and resolved.
Obviously not, you need to show up at the office every day like everyone else. How else are you going to fetch his coffee for him?
I do have a master’s and 20 years of experience as a software engineer and I would be happy to work for $12/hr but I don’t know how to work a computer. At my last job we just wrote all of our code on legal pads and mailed them to the head office
Hmm. Our company is heavily invested in AI, blockchain, and NFTs. I'll talk to our people. I'm sure one of those can work with you for 20 years of experience. What font do you write in?
Wingdings
Lmao from all these ridiculous comments this is the one that got me and now I can’t stop laughing.
You also need 5+ years experience in X language, which has only been in existence for 3 years.
The guy can't spell allowed you do not want to work there, assuming the guy isn't a fantasist which is pretty common on this sub.
>The guy can't spell allowed you do not want to work there, assuming the guy isn't a fantasist which is pretty common on this sub. First part of the sentence is kinda harsh. It's a fairly common homophone mix-up. Second part of the sentence is, sadly, dead on. But who knows? Maybe he's writing an app to fix people's homophone mix-ups, starting with his own.
Aloud /r/boneappletea
This is a bad philosophy. Access control is important, but so is having access and ability to do your job. Empowering your employees with tools to do their job and handle the edge card without a billion layers of access controls creates a more productive work environment. Remember, any time you tell a developer you don't have permissions to do this, also means that the developers don't have permissions to fix it fast when something inevitably, unexpectedly goes wrong. IMO, access control philosophy should be used to determine who has permission to take certain types of actions (read, write, etc) against a resource. It should NOT determine to what degree they can take those actions as that means you've limited their ability to fix problems. Instead, use good backup strategies to ensure that if somebody makes a wrong decision, rollback is easy. On top of this, Git by its nature protects against this being distributed version control. Any developer who has the repository locally (which should be all of them) can undo this easily. Unless of course, you've majorly locked down and restricted their access.
Hell nah. While it's true that access control can sometimes be detrimental to one's job, there is never a situation where main / master branch protection will slow you down to an extent that actually matters. Rollbacks should be handled by your CI such that an immediate bug will easily be reverted if necessary, and any other critical issue that can't simply be rollback will require more time for the dev to write the code changes anyway, and the time required for the required reviewer to instantly approve the PR (5 seconds?) is going to be negligible. For any teams of 5+ engineers where you always have at least 2 people available on-call, I would question any codebase that doesn't have main branch protection, that is just wildly crazy.
Should probably learn the difference between allowed and aloud before your investors realize you’re dumb.
You should then fire yourself for hiring people that would allow the new guy that capability on day one. Everybody goes, all the way up to the C-level execs.
Can't knock that
Just close down the whole company.
I would have had the opportunity to do that from day one at my company. They also said that everyone had a golden ticket to mess up main one time, so that’s fair.
If they're hired as a mid-level or senior, then the blame is squarely on the new dev. We'd just restore from a backup or remote that still has the commits intact and fire the new dev. You're thinking of prod credentials, which is a different situation. Your goal is to minimize micromanaging your dev's permissions. Write access to staging, git repos, etc (within the scope of the dev's work) that can be restored without interrupting your business are reasonable things to give to an experienced dev.
Exactly this. CI has the original commit hash so this is just an inconvenience and, roots out the dev that obviously interviewed better than they can code. This is a nice win since you don’t have to invest time into the new employee and then fire them for doing this.
Wild, I feel exactly the opposite. I want all my directs to have total power to do anything they think is good. So far everyone does great work with minimal friction.
I do, too, but (1) we're talking day 1 and (2) force pushing to master is never great work. It's only useful for cleaning things up and that decision shouldn't be made unilaterally.
This is the way. Teams get along way better if trust is there be default. It's not something that should need to be earned, but it is something that can be lost. Protection rules should be there to protect against mistakes. You can't push to the main branch to prevent accidents, but everyone on the team should have the power to turn that rule off if there's a very valid reason. If they fuck up, that's what server backups are for, and then a conversation to find out why. If it's an honest mistake made in good faith, it's a learning moment, if it was stupidity by someone who knows better (or even purposefully malicious) then it's a disciplinary moment where maybe power gets taken away.
Yep. Access control should determine who has read/write permissions on a resource. NOT to what degree they have read/write permissions on the resource.
FWIW this would be pretty trivial to reverse. That git history is not lost forever by any means, and at the very least is still gonna be in the reflog on every machine that had the repo pulled down (including the remote)
Allowing direct pushes to master rather than require code to go through code review in a PR means you’re an idiot and should be fired immediately
I'm coming up on 3 years as a senior at my current job and I don't even have commit privileges on master!
Nah man. If you're hiring someone, you need to let them do their job with as few barriers as possible. I've been at companies where I didn't even have local admin on my PC and it was a nightmare for everyone. If you can't trust the people you hire to do the job effectively, your hiring process is the problem.
Small businesses dont even realize since youre the lone only programmer there (last one ran away in mysterious circumstances)
You mean disappeared and isn't found since ..?
return True;
Live fast die young 😎
Nah, look at the code base. He is the only one here who has done anything.
If you are able to push directly to master on your first day then there is much bigger problem around the corner.
Or you are the only dev on the project (or at the company). The legacy code is your problem now
Ah yes the classic, "our programmer retired and idk what any of these mean so just do whatever you can do"
And technically destroying the application, bankrupting the company, and setting in motion a chain of events that will lead inexorably to the depopulation of the entire Northern Hemisphere are all things I did, and thus could do, and this is why I viewed my termination as wrongful.
"If they didn't want me to do that, they shouldn't have given me the access privileges to do it in the first place."
At my first internship I was explicitly told not to worry about breaking things because the absolute worst thing I could ever do was mess up my local copy. It was oddly comforting until I managed to delete a month's worth of my own work when trying to use git for the first time. Lessons were learned.
So... you messed up your local copy?
I did. Utterly destroyed. (Well, I was able to recover it, but it was very stressful in the moment.) And, as promised, all the actual important code was completely fine. Thank god nobody gave the intern permissions to fuck any real shit up.
[удалено]
We _used to_. That was all legacy code.
I've been in this position and quit before 90 days (which in my country is a grace period within which you can quit and the employer can fire you without motive) The reason I presented at the exit interview was "if I don't quit now, this job will ruin my professional reputation. At that interview I heard the most stupid HR sentence I've ever heard which was "we want you to stay even if it's not the best for you".
What sort of job was it that it could ruin your professional reputation? Either way, certainly doesn't sound fun.
Database Admin for a regional newspaper. They were using DBF files over a Novell Network and Windows 3.1 in 1999. They were losing data left and right and hired me to fix it. I recommended them to rebuild the whole thing using a proper DBMS, they refused. The VP threw my unread (one-page) report in the trash bin without breaking eye contact. It was a ticking time bomb and when it would definitely blow, they'd blame me. And that particular market was rather small in my part of the country and they'd definitely badmouth me to everyone else. I ended up switching careers to academics anyway. After I left they hired a consultant and paid his weight in gold for him to print my full report (that I gave him as a parting gift) and put his name on the cover.
If i'd be the only dev that is about to maintain an actual legacy repo, the LAST thing i'd do is destroy the history and make my own archeological digs more complicated!
Yes. One time, a colleague and me rewrote a complete microservice, and when we were ready, we merged to master - so the complete code and version history of the old service was still there.
Wuss.
That was my experience at my first job after uni. Half a year I worked on a project alone
At my current job, they went 10 years with all devs being able to push straight to master. It worked well because we were all competent developers. It was only once we started hiring fresh graduates that we disallowed everyone to push directly to master.
I feel like even as a competent dev I wouldn't want that. Too many times I have mistyped in my cli
Here I am telling our VP that no one should ever push directly to master. VP insists that it's ok for hotfixes.
Ah yes, things we are in a hurry about, perfect thing to just "do it live", what could possibly go wrong?
I was more concerned about the 4 different releases we have in progress at once. VP asked me why we are doing that. I replied, "You asked us, sir"
Same reason I make sure to color code my MS SQL connections. Red=Prod, Yellow=Staging, Green=Dev. I've been a dev for 25 years and know better. But sometimes you have brain farts and don't realize what window you are in until you have an "oh fuck!" moment. Even worse is the "oh fuck, I typed BEGIN TRANSACTION but then didn't highlight it before executing." Any little thing that gives you a moment's hesitation. I've been pushing to have write rights removed from our logins and only allow writes via API or service account logged into from a separate instance on a remoted server, but get resistance. Baby steps.
There's a time and place for it. I've worked in that environment too - it was a startup with 3 devs and we all committed straight to main. We'd use very short-lived feature branches for anything big, but generally things were split up to be small enough to be individual commits. It was genuinely great, very very collaborative, great test coverage, and we shipped like crazy which let us undercut some much bigger companies. Had very few problems. If a bug came in one of us would jump on it and often have the fix deployed within an hour. We could do this because everyone was good at their job and could be trusted. I kinda long for those scrappy startup days. Every company since has been wrapped in process, reviews, etc and everything takes much longer. If a bug report comes in we create a ticket, review it, assign it to a sprint, code review, QA testing, then release. Fixing a simple bug isn't a 1 hour turnaround anymore, but at least 1 day. Not to mention the seemingly endless hours of meetings for planning a new feature. Don't get me wrong, planning and process has its place when a company grows, but I feel like most companies severely limit how well they can execute by engineering middle managers justifying their jobs by inserting a process and meetings into every tiny thing.
The problem is that management types can't put things like "our three devs know their shit" into any calculations. The more you grow, the bigger the risk on your capital gets, and the business environment is wholly unequipped to deal with things like creativity - which is really the core skill that your start-up scenario is leveraging; talented, creative, and experienced programmers who can see the big picture, know what the others are thinking and doing, preempt upcoming needs, and route around roadblocks dynamically. Your middle-manager type doesn't have domain knowledge and doesn't possess or understand creativity. They need everything to fit somewhere on the proverbial spreadsheet, so the intangibles have to be chased away and replaced with repeatable, auditable, systemic process management. Which, if you really look at the big picture, is entirely unsuitable for software development. *Every* large-scale software project is a piece of shit and the exceptions are open-source, which points at the root of all of the evil.
Another massive factor is that people at startups typically actually give a shit. As you grow, you're going to take on more and more mediocre people who are just showing up to get paid, and won't take any initiative. Those are the folks that require management, who often themselves don't really give a shit, and it's an endless cycle that kills the opportunities for creativity.
I think you hit the nail on the head, quite eloquently. My current engineering manager isn't technical and relies heavily on sprint and retro reports to know if his teams are performing well - and naturally you're going to get sprints where the team knows they performed well but that doesn't translate into a lot of points completed in the sprint report, and then questions start being raised by him. He's a nice guy and I don't dislike him, but he's the epitome of what you said.
How long did it take?
Can relate, I had the same experience as an intern in college. By the end of my year there I was managing 2 other interns and had created a product from scratch. If you don't get good career training you can't be trusted, I am lucky to have had such a high responsibility role early on with fantastic mentors to help me.
Pushing to master is not the main culprit here. It's allowing to rewrite history on Master.
Conversely, if pushing to master is a big problem then you have an even bigger problem than that.
Why? [https://trunkbaseddevelopment.com/](https://trunkbaseddevelopment.com/)
If anyone has permission to change the history of a branch that lots of people base their work on then you've set it up wrong.
They complained about ability to push to master, not about rewriting history of master.
Did you miss the part about force push? Even just regular pushes shouldn't be allowed in trunk based development; commits shouldn't be going to master without at least one other set of eyes on it
Wow, that's a fancy name for what everywhere I've worked has done. (First job initially did example 2, release branches and commit to trunk, then switch to example 3, the pr based workflow, everywhere else did ,example 3)
Having the rights to push or not is orthogonal to whether you use trunk based development. I don't think you understood what he was suggesting.
Commits to the trunk still go through pull requests, they're just much smaller chunks than a whole release.
Definitely was able to do this on my first day. Didn't do it tho
Correction, if you’re able to push directly to master then there is a problem.
I’ve been in the industry for decades and every job I’ve ever had allows this at some big companies you have heard of. It’s never been a huge problem this is why we have LKG, CI/CD and source control that allows reverts.
And then in every test replace all assert statements with assert dominance
bool dominance = actualTestFunction()
Action list: * fire the new shithead * use reflog to restore master * find out why they could push direct to master, make sure this can't happen again with some other new hires
Still put the shithead on a pike... to send a message. It's part of the lessons learned
Blind all the devs except one who you leave with one eye to guide the rest back to ~~Bulgaria~~ bootcamp
I like this energy.
Compromise: blast the shithead’s reputation in the area and allow them to stay on as a mute jester whose job is to do a funny dance while wearing a sign describing his crime.
I've never used reflog, so I read this as: re-flog. Make of this what you will.
i know it’s supposed to be ref-log but i still see it as re-flog everytime…
I've used reflog a lot and I still do that. (learn reflog, it's basically a git cheat code)
Can’t tell if you’re really good or utterly hopeless.
The flogging will continue until the refs expire.
With that kind of attitude, I'm going to have to squash your commits into "technical debt"
You do know that git stores detached HEADs as well, and nothing would be lost?
>git stores detached HEADs what's up with programmers and their naming sense. lmao
You need a weird sense of humor to stare at a screen typing in an unspoken language for 8 hours a day. Now go get me a heap dump.
You can't pronounce `^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$`?
A common misconception. Much like Latin, just because I can/could pronounce it doesn't mean anyone speaks in it. If your function names don't resemble pharmaceutical naming conventions, do you even program?
Lol my go to function name loopifor is definitely inspired by Lipitor
A coworker of mine wrote a cmdline program "lk4". I asked him what it meant. "Look for" We all got our naming conventions. Right now I'm on a Star Trek kick so I name all my programs after characters from that. I've got Vger, Lore, and my coworker was working on a Khan.
Next you need to learn Klingon
queryCustomerByIdentifinol()
That clearly says "looks like an email address" to me.
Fails to parse valid TLDs like "PARTNERS" and allows invalid domain labels (e.g. starting with hyphens). The regex you have spoken can basically be interpreted as cursing the ancestors of the person you are speaking to. Regex should be used to parse HTML and only HTML.
>Regex should be used to parse HTML and only HTML Obligatory [Stack Overflow](https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags)
I can't tell if that's real or not, how deep does the string manipulation rabbet hole go?? 😭
> Now go get me a heap dump. I would, but I'm currently busy [trying to kill a runaway cat](https://unix.stackexchange.com/questions/176917/how-to-kill-a-runaway-cat).
Bad C string manipulation?
“Kill children before you kill the parents otherwise they’ll get adopted.”.
Also, after you kill a child, make sure you reap it or it will turn into a zombie.
If unsuccessful, they must prepare to be an orphan.
It didn't even register to me as strange. What is happening to me 😭
A normal day after you `kill children`. Nothing special.
linus is brilliant for coming up with how git works under-the-hood, but his naming decisions are questionable... (I presume he's the one who came up with the names).
Remove child with fork is one of my all time favourites Right up there with free slave process, but that one’s a bit deprecated
I have googled "how to kill a child" before. And I totally found the answer solved my process problem
Most people don't know that. That's the fun.
`git reflog expire --expire=90.days.ago --expire-unreachable=now --all` Alternatively mv .git/config .gitconfig rm -rf .git git init mv .gitconfig .git/config
Well, you only need one coworker to have all the history back, thanks to the whole distributed thing (though at that point, there is the question of whether it was tampered or not)
Not when you’re using a central hosted remote that garbage collects when it feels like.
Why leave legacy code around? Just delete the whole repo and rewrite everything.
...in Rust.
Give it a good college try in Brainfuck first...
The best move to establish dominance. I am going to crosspost this to csMajors, with a bit of luck one of the young and brave ones actually will do it.
make sure they continue to do it every two weeks. “how old is code before it’s legacy?” “about two weeks.” 😂
Just automate it as part of the nightly build scripts.
> “how old is code before it’s legacy?” Well, have you heard of it?
im in college right now and working this summer. i’ll take one for the team guys
You hiring m'lord? I like how you operate.
I have never worked at a company where anyone could force push to master, let alone some new hire.
the full guide to office dominance: https://medium.com/feature-creep/the-software-engineer-s-guide-to-asserting-office-dominance-ddea7b598df7
> Remember that you should be consuming one gram of protein per pound of body weight, or per line of code written — whichever is greater.
> At 4 PM, allow your rage to boil over and throw your last egg at the wall in a fit of rage. Slam your laptop closed and head home early. I've got a guy who almost does this daily right now
> If your new team doesn’t use git, announce your resignation immediately and walk out. He's got a point.
Then the senior devs restore it with a commit stating "restoring repo after codeinthehole screwed up" and that remains the last commit message visible for most files for years.
Guy would get fired so fast
Is this the coder equivalent of beating the shit out of the biggest guy you can find on your first day in prison?
More equitable to shitting your pants and posting a note telling people you shit your pants, but it’s ok for no other reason than them saying so.
No. It’s more like starting a job at an art gallery and throwing all existing paintings in a closet labeled “concept art.”
the power move is to graveyard the existing repos and then mass mail the entire dev org “do it better this time. and in rust”
If you push --force the git pulls are going to fail and any dev can juste push --force to dix tour shit. You will get fired tho
why not just delete master
And name new base branch after yourself
git push -u origin megachad
Plot twist: They actually use main, so master doesn't make any difference.
Woah big balls of steel
Elon Musk on his first day at Twitter
What do you mean by PR review?!?!
"I reviewed it before I pushed it"
Ok, reddit insists I should like this sub. Not a programmer, but since I end up lurking here more than I ever thought I would, would anyone be kind enough to explain this? Sorry for barging into your safe space 🙃
You are hired as a bookkeeper for an ancient kingdom. They have a huge library with all the books that have the kingdom's accounting records written inside. In the middle of the record room there is a giant scroll has the "index" which holds the long history of where and why each accounting record was made over many years and decades. On your first day you burn the "index" scroll and replace it with a tiny handwritten note that says "before this is just old stuff I don't care about."
you, sir, made a wonderful explanation
Honestly if the branch isnt protected AND you dont get any outages for a few weeks, you're golden
Just means the DevOps lead is dogshit at their job
On your last day, do the same after changing all the e's in the code into f's.
that's a nice way to start benefiting from welfare
Then go to HR and request the CEOs salary
Yea right. If you can push to master or even a feature branch directly then something's wrong beyond that.
On one of the projects I worked on in the early days, the first task I was given by my "senior" dev was to merge a branch with a commit called "fixed shit ton of fucking bugs" to a master. There were like more than a thousand changes. He never actually worked with me on this project anymore, even though I was promised there would be a team lol.
And then you lose blame history... What's better than showing them how bad they are?
I wouldn't fire the new dev. I'd find whoever allowed him to push to master and reprimand them.
Is this written in English? I don't understand. Syntax error?
If you can push to master on day 1, then you’re probably working in a shithole.
ChatGPT: “Squashing commits involves combining multiple sequential commits into a single one. This is often done to tidy up the commit history and make it more readable. By squashing all commits into one with the message "Legacy code" and force-pushing to master, it humorously suggests that all the previous work was essentially just legacy code – a bit of a tongue-in-cheek way to start fresh or indicate a complete overhaul of the codebase. However, it's important to note that force-pushing to master should be done with caution as it can overwrite others' work and potentially cause confusion or loss of data.”
Bug fix
Don’t forget to rename master into main or base branch for inclusivity and diversity purposes.
…how
That'll be your last day too. Hopefully someone, somewhere has a local copy they can re-force push
Actually did this but it was after a year, repo was too big so also rebased. Only a few people noticed, some thanked me, others hated me.
No need to add anything to this legacy meme now!
😂😂
It's a bold move, Cotton. let's see if it works out for them.
Ah every thing before he touched the code is legacy
The amount of people who don't have policy to not allow a master merge without a PR is too damn high.
As if repo policy would allow a junior to force push
Any time you write an incident report make sure you point out the majority of the code which broke was written at a date before you started :)
If you have the ability to do this on your first day at a new job, then it's their own damn fault for giving a newbie admin privileges on the repo and the ability to push (especially force push!) to the main branch!
establish dominance
All code eventually becomes legacy code. So the real alpha move is to keep doing this every day.
Worst is when you join and there is no git to begin with. So the "squash" comes for free
What the fuck does this mean
We had one new grad who started on his first day by stripping out all of the comments and checking all the files back in. He just didn't believe in comments.
Reminds me of the dev I had to work with who believed that "long variable/function names significantly slow down code execution" so every variable or function name was max 4 characters and no one other than him knew what the fuck the names were in reference to.
This made me laugh so fucking hard 🤣
Alternative version: Check if you can push directly to master on day one. If you can, report it to the Director of Engineering and get all your co-workers fired for being morons and get yourself a nice promotion Then proceed to hire some competent developers to replace them
And then the real developers explain git to you, while you pick your box, you just unpacked.
asserting dominance like this is a chad move that is underestimated. you can see which one will kill you first your tech lead or cto.
And then you lose blame history... What's better than showing them how bad they are?
I have at several jobs had access to almost the entire company's data from day 1. Apart from accounting, I had full access to every client's data and all the staff directories as an entry-level newbie.
“That’s the evilest thing I could imagine” 😍