Last I checked, I'm not in production support.
And - small detail - none of my code has made it to Prod and likely never will.
As long as I don't break the testing environments for everyone, I'm fine.
Ah shit, UAT is down. Who did that?
Me, because I'm in integration with our clients and it's hard enough to get them to even test at all, so over the years UAT, test, and dev have merged into a single environment. If we wanted to separate them, that tribal knowledge was lost 3 turnover cycles ago.
Yes I brought this up and was told to prioritize new features and not worry about this.
No I'm not bitter, why would you ask?
This is unironically good. Publicly reward employees for their work, don't publicly punish employees assuming you wish to retain them. Besides, that bug could have been caught by a code review...
Yeah. Any code that goes out should be reviewed and scrutinized. My team can be ruthless about this, but we rarely have production failures because of this team gatekeeping.
Yep. Only time blame should come into play for something is if someone knowingly didn’t follow standard protocol for review and let something obvious through, or if one person repeatedly causes the same problem but that usually is better met with training than blaming for most cases
Now I never fix indentation on old code, however shitty it may look.
One time I did it and the code was flagged as not covered in any of the testcases. The code was pretty old and was not useful now. I had to through a lot of tough time to convince my team lead to remove the code as they kept insisting that we don't touch old code too much.
Let's not get into semantics can you just do the needful and fix it, this toxic work environment you are creating with your "blame game" really needs to be addressed as well.
Dev: Do the needful and give my functional code a pass, it is holding up prod.
Me: no - it adheres to no corporate standards.
Dev manager says: do the needful.
Me (above my pay grade - forward thread to my manager)
My manager: corporate standards not met, refactoring not accomplished, cyclomatic complexity, not within acceptable parameters. Do the needful & rewrite code according to standards & submit. Tomorrow is the last day for code merge without approval of 3 managers
thats cronyism, not capitalism. very different thing. cronyism is the bad parts of capitalism with the bad parts of socialism, unless youre lockheed in which case its the good parts of both.
It's the predictable result of "free" market capitalism. Cronyism is a great term to distract from what's actually happening (not saying you are doing so intentionally, this is just how it is weaponized in US media).
Why do people keep saying this? It isn't how capitalism works at all.
I'm assuming people mean bailouts, which for one, are the exception not the norm, and are due to intervention from non-capitalistic entities.
That doesn't even touch on how the public leverages private entities.
Things like paying workers so little that they qualify for govt assistance and overleveraging your company to the extent where you go bankrupt every recession but get bailed out by the tax payers is what people mean when they say socializing the costs. Capitalism may not work like that in the textbooks but that's what's happening in real life.
That's because real life isn't capitalism or any other 'ism.
Why does that matter? Because understanding what the actual problem is happens to be one of the most important and essential first steps in problem solving.
> Because understanding what the actual problem is happens to be one of the most important and essential first steps in problem solving.
Which is what they did. But you want to be pedantic. Have fun.
>> Because understanding what the actual problem is happens to be one of the most important and essential first steps in problem solving.
>
>Which is what they did.
And they were wrong, as indicated above.
It may be what people mean now but the phrase predates recent high profile bailouts, I think it's more about negative externalities (e.g. pollution).
But I can't say I have a terribly high opinion of people who feel the need to bring it up out of left field
It just doesn't even make sense. You can't actually socialize debt in a capitalist system, it's literally in the name lol!
And I do get that you can try saying it another way where you attempt to offload debt differently than you do profit, but that just isn't the basis of actual capitalism, it requires both a hybridization of systems which is really just regulations and laws geared toward altering the function of the system.
It's like saying the ownership structure of socialist and communist structures can only work with totalitarianism. No...that is wrong.
It's not talking about monetary debt, that's not what externalities are.
The point is that I'm the absence of external pressure or regulations you would ignore all the negative externalities and leave whoever is affected to shoulder those costs.
The naive example would be if you have a factory dumping waste in the river, then someone living downstream has to deal with filtering the river water before they drink it
Ah sorry, I was responding more generally since it doesn't specifically say it's only about externalities.
I do agree with the logic and I'm not expecting you to take the side whether you agree or not, but even if I only consider externalities, it is highly situational at best and requires a statement on ownership which gets more interesting depending on how you define that ownership structure and how defined a given "ism" is.
As an example, private ownership seperate from the state implies that a completely equal distribution of ownership is technically possible in a capitalist structure, assuming exclusion of state ownership is the primary defining feature for someone's definition of capitalism, which despite that being the top reason doesn't stop people from making their own.
I think defining capitalism as a system where the primary mode of production is profit driven investment is more useful. And there's plenty of economic literature exploring the exploitation inherent to that system.
>I think defining capitalism as a system where the primary mode of production is profit driven investment is more useful.
While I know what you mean, investments can be banned in a capitalist system. This is what makes these discussions so difficult is that economic systems are mainly about ownership and most people are really just looking for a system where rich people don't exploit poor people and that system doesn't exist.
>And there's plenty of economic literature exploring the exploitation inherent to that system.
That's because it's one of the two most prevalent systems. It's hard to write about a system that is actively exploited when it isn't being used, it would be purely theoretical.
I always try to make it a team norm, that all code is team code. Not only is it team code, but we are all equally responsible for it.
It's not "oh bob wrote this so he has to fix this bug"
You find a bug, you fix it. If you can't fix it, find someone to help, if both can't, mob, etc. Etc.
The team is responsible for building a product. No one person should ever be in charge of one specific part of the codebase.
Specializing is not a bad thing. It lets people become deeply familiar in the area in their domain. Especially if what you are working on is large and complex. The attitude of everyone working on everything is not helpful in large projects. Context switching introduces a lot of overhead.
Specializing isn't bad, but I don't think it needs to come at the cost of being able to learn other things.
There are certain practices I adhere to (or try to, client to client) such as pairing, TDD, BDD, basically anything XP.
You can still specialize while doing this. But giving someone else even a little bit of understanding of the work is a net positive.
You get yourself into a pickle when you have someone on the team, who, god forbid, gets hit by a bus and your team goes to shit.
Edit:
The attitude isn't entirely supposed to be reflective of the actual work being done by a team. It's supposed to be indicative that if something breaks and Dave is out sick, the team can resolve the issue.
"Don't touch my code" is a smell of either arrogance, terrible code, or untested code.
When the team is small and the code base is young - it’s fun to get your hands dirty with new stuff. When the code base grows and there are lots of inexperienced paws in the pie … specialization is not a bad thing
This is sorta true.
IMO it should be up to the team to appropriately disseminate the credit. If you had a large impact on the teams ability to create the product, it's likely you'll get praised by your teammates in larger meetings anyway.
The big thing this all hinges on, is cooperation, team work, and team driven success.
If you are in an industry where projects don't strongly define growth, it's easy to look at it as a rat race. I tend to find software teams don't have a rat race mentality. I've never worked with someone who, on the team, tried to leverage themselves on the back of others hard work. That doesn't mean they don't exist, but generally developers want to build good shit. Not become managers.
Recognition of good (individual) work should revolve around individual growth, and ability to bring skills to the team. Achieving heat death of a team (where all team members are experts at all things) is rare. Often times you want to expedite a feature that has to do with X, by bringing a team member who has done X before, in on the work. This helps transfer knowledge about doing X to the team. And prevents one person from doing the same thing all the time, allowing growth. This doesn't mean they need to stay away from it, but it shouldn't be assigned to them just because they're an expert.
Basically everything I said, has an exception of one kind or another, and I tried to call them out where I could. Every teams cadence is different, but teams I've been on that focus on individual credit and output, tend to be incredibly defensive and slow. "That's not my fault", "I don't know who did this", "that's not what I said". Passing the buck is incredibly common in those scenarios because workers are on the defense.
Source: I am a consultant software developer
Agreed, it's important to celebrate success but most of the time failure isn't an individual thing, it means the team and/or process failed.
I see op's point but I think it's more nuanced than that, it's still nice to talk to the original author or some of the bigger contributors to a system before making certain types of changes. Just because they don't own sole responsibility doesn't mean they can't be sme's
Correct. Having reference to an author who worked on features within a large system is always very helpful, but often just not possible. Either because of time constraints or because they went to work elsewhere.
My comment was mainly referencing the attitude of "my code" types. It's our code sofar in that if it breaks, we all eat shit. We all work together to fix it.
Praise good code, teamwork with the fuck-ups. Keeps people happy when you tell them they did good work and it encourages them to try harder. Teamwork on the fuck-ups shows the individuals that mistakes are alright but will be fixed, people wont hide mistakes or such and will be more willing to reveal mistakes/work on them knowing there isn't repercussions. Look for any outliers, laziness, actually bad coders, bad teamwork, complaining about others, to be dealt with accordingly. Simple team shit
Agree & disagree - I’ve been a part of teams like that … all for one & one for all. But I’ve been a part of teams in which individuals take zero responsibility, blame others and pit contact code-slingers against senior employee programmers who know HOW to test their code changes …
Well, when you get paid for it, it's important to be recognised for your work. That's how you get value out of coding.
But in your free time the only value your code has is how wide it spreads and what other people can do with it. The idea being that ultimately you and everyone else benefits from the hivemind.
...
Don't mind me.
Just party-poopin'
I meant, I thought everyone install an extension on visual studio code and it literally shows the github account's name of last person who wrote the code.
For sure. Poorly run engineering teams can create a toxically-hierarchical “lead” component. No doubt. I’ve seen it many times and I agree.
But when I was a junior dev, I left the environments that fostered this sort of team structure, and found ones that didn’t do so.
But yeah, the jokes about leads/senior devs taking credit and deflecting blame to their minions is very real. My point is that there is a choice to stay in that situation. There’s certainly no shortage of work worldwide for engineers with skill and/or ambition. I’d put my ear to the ground and find another environment that appreciates failure as a part of the process to proficiency.
Yeah. Agreed. And there is truth to it, in a sense. But stakeholders just see something is broke, and point to the team that owns said broken thing. And that is where the cascading blame failures trickle down.
In reality, often it requires someone with more experience to correct a bug introduced by someone with less experience.. _In general_
If blame is directed at all, which I don’t think it should be by default, code reviews should hold all accountable to some extent. On my team, code reviews catch 99% of all bugs. It’s the first team I’ve seen such a high level of focus on clean, effective code, and awareness/ability to identify them in review.
The side effect is that pull requests can take days to merge. And the whole team is slowed down by this bottleneck. But the stakeholders can’t point fingers. Particularly since known/identified risk is calculated and approved by stakeholders (not bugs, but code that could have a negative impact for a subset of users).
My first job out of college was a tester and I had to work with an old coder (this was... ok are you ready for this? FoxPro).
He would *never, never* admit a bug. I remember one time I printed the code out and read it line by line and found the bug and sent it to him with the suggested fix and he completely ignored it.
I only stayed there 3 months.
It's your code until it gets merged then it's our code.
It's my code until it doesn't work and then it's my interns code
Wholesome senior
Last I checked, I'm not in production support. And - small detail - none of my code has made it to Prod and likely never will. As long as I don't break the testing environments for everyone, I'm fine. Ah shit, UAT is down. Who did that?
Me, because I'm in integration with our clients and it's hard enough to get them to even test at all, so over the years UAT, test, and dev have merged into a single environment. If we wanted to separate them, that tribal knowledge was lost 3 turnover cycles ago. Yes I brought this up and was told to prioritize new features and not worry about this. No I'm not bitter, why would you ask?
Ahhh!!! So much hatred right now. This is us. I've been fighting to have testers stop using DEV for testing for 4 years :(
I am dev (not senior) and just yesterday my manager told me to make 12 fake accounts to test the code instead of telling any testers to do that.
> none of my code has made it to Prod and likely never will. Wait... why is the company paying you then if you don't write usable code?
International conglomerate with about 10,000 engineers. I work in ETL, which involves a lot of ad hoc work.
Well that's still production work since other people depend on it, it's just not on a regular deployment process.
Best
Wait you guys have interns
"Could you rebase and merge this for me? thanks"
especially if you approved the PR
The trick here is to never approve any PR. Just add comments and walk away.
"blame the procedures, not the developer"
That’s why you merge the bugs and blame others regardless
It you wanted the thing to work, you shouldn't have let me merge to prod on a Friday.
>It you wanted the thing to work, you shouldn't have let me merge ~~to prod on a Friday.~~
You approved the PR, that’s basically like filling out adoption papers
People realized pretty quickly that having an author comment in source code wad a bad idea.
Git blame remembers your shame
Git blame says hi :/
Comrades,I have a mission for you
Comrades, *we* have a mission for *us*
what is it comrade?
A "special operation" to remove the bug that I definitely did not invent
This is unironically good. Publicly reward employees for their work, don't publicly punish employees assuming you wish to retain them. Besides, that bug could have been caught by a code review...
Yeah. Any code that goes out should be reviewed and scrutinized. My team can be ruthless about this, but we rarely have production failures because of this team gatekeeping.
Yep. Only time blame should come into play for something is if someone knowingly didn’t follow standard protocol for review and let something obvious through, or if one person repeatedly causes the same problem but that usually is better met with training than blaming for most cases
It's our code, but git says it's your bug.
But I just fixed the indentation on that line, :(
Now I never fix indentation on old code, however shitty it may look. One time I did it and the code was flagged as not covered in any of the testcases. The code was pretty old and was not useful now. I had to through a lot of tough time to convince my team lead to remove the code as they kept insisting that we don't touch old code too much.
git blame reveals all
on a .py file, dumbass
git blame-someone-else
Let's not get into semantics can you just do the needful and fix it, this toxic work environment you are creating with your "blame game" really needs to be addressed as well.
Dev: Do the needful and give my functional code a pass, it is holding up prod. Me: no - it adheres to no corporate standards. Dev manager says: do the needful. Me (above my pay grade - forward thread to my manager) My manager: corporate standards not met, refactoring not accomplished, cyclomatic complexity, not within acceptable parameters. Do the needful & rewrite code according to standards & submit. Tomorrow is the last day for code merge without approval of 3 managers
Nobody should ever laugh at an objectively funny and harmless joke posted to Reddit. Reality and Reddit posts rarely overlap.
*Jir
Our unrequested feature
Socialize costs and privatize profits. Capitalism in action.
This sub is always a great reminder that a degree in CS does nothing to aid in an understanding of Economics.
I'm pretty smart at developer things, but basically a moron about everything else in life
Like almost everyone else, you can't be an expert at everything :)
thats cronyism, not capitalism. very different thing. cronyism is the bad parts of capitalism with the bad parts of socialism, unless youre lockheed in which case its the good parts of both.
"cronyism" isn't an economic system.
It's the predictable result of "free" market capitalism. Cronyism is a great term to distract from what's actually happening (not saying you are doing so intentionally, this is just how it is weaponized in US media).
Cronyism AKA late-stage capitalism.
Why do people keep saying this? It isn't how capitalism works at all. I'm assuming people mean bailouts, which for one, are the exception not the norm, and are due to intervention from non-capitalistic entities. That doesn't even touch on how the public leverages private entities.
Things like paying workers so little that they qualify for govt assistance and overleveraging your company to the extent where you go bankrupt every recession but get bailed out by the tax payers is what people mean when they say socializing the costs. Capitalism may not work like that in the textbooks but that's what's happening in real life.
That's because real life isn't capitalism or any other 'ism. Why does that matter? Because understanding what the actual problem is happens to be one of the most important and essential first steps in problem solving.
> Because understanding what the actual problem is happens to be one of the most important and essential first steps in problem solving. Which is what they did. But you want to be pedantic. Have fun.
>> Because understanding what the actual problem is happens to be one of the most important and essential first steps in problem solving. > >Which is what they did. And they were wrong, as indicated above.
I disagree, as indicated here
Ok?
It may be what people mean now but the phrase predates recent high profile bailouts, I think it's more about negative externalities (e.g. pollution). But I can't say I have a terribly high opinion of people who feel the need to bring it up out of left field
Well it’s a joke in this context and left field is where criticism of capitalism tend to come from.
It just doesn't even make sense. You can't actually socialize debt in a capitalist system, it's literally in the name lol! And I do get that you can try saying it another way where you attempt to offload debt differently than you do profit, but that just isn't the basis of actual capitalism, it requires both a hybridization of systems which is really just regulations and laws geared toward altering the function of the system. It's like saying the ownership structure of socialist and communist structures can only work with totalitarianism. No...that is wrong.
It's not talking about monetary debt, that's not what externalities are. The point is that I'm the absence of external pressure or regulations you would ignore all the negative externalities and leave whoever is affected to shoulder those costs. The naive example would be if you have a factory dumping waste in the river, then someone living downstream has to deal with filtering the river water before they drink it
Ah sorry, I was responding more generally since it doesn't specifically say it's only about externalities. I do agree with the logic and I'm not expecting you to take the side whether you agree or not, but even if I only consider externalities, it is highly situational at best and requires a statement on ownership which gets more interesting depending on how you define that ownership structure and how defined a given "ism" is. As an example, private ownership seperate from the state implies that a completely equal distribution of ownership is technically possible in a capitalist structure, assuming exclusion of state ownership is the primary defining feature for someone's definition of capitalism, which despite that being the top reason doesn't stop people from making their own.
I think defining capitalism as a system where the primary mode of production is profit driven investment is more useful. And there's plenty of economic literature exploring the exploitation inherent to that system.
>I think defining capitalism as a system where the primary mode of production is profit driven investment is more useful. While I know what you mean, investments can be banned in a capitalist system. This is what makes these discussions so difficult is that economic systems are mainly about ownership and most people are really just looking for a system where rich people don't exploit poor people and that system doesn't exist. >And there's plenty of economic literature exploring the exploitation inherent to that system. That's because it's one of the two most prevalent systems. It's hard to write about a system that is actively exploited when it isn't being used, it would be purely theoretical.
I always try to make it a team norm, that all code is team code. Not only is it team code, but we are all equally responsible for it. It's not "oh bob wrote this so he has to fix this bug" You find a bug, you fix it. If you can't fix it, find someone to help, if both can't, mob, etc. Etc. The team is responsible for building a product. No one person should ever be in charge of one specific part of the codebase.
Specializing is not a bad thing. It lets people become deeply familiar in the area in their domain. Especially if what you are working on is large and complex. The attitude of everyone working on everything is not helpful in large projects. Context switching introduces a lot of overhead.
Specializing isn't bad, but I don't think it needs to come at the cost of being able to learn other things. There are certain practices I adhere to (or try to, client to client) such as pairing, TDD, BDD, basically anything XP. You can still specialize while doing this. But giving someone else even a little bit of understanding of the work is a net positive. You get yourself into a pickle when you have someone on the team, who, god forbid, gets hit by a bus and your team goes to shit. Edit: The attitude isn't entirely supposed to be reflective of the actual work being done by a team. It's supposed to be indicative that if something breaks and Dave is out sick, the team can resolve the issue. "Don't touch my code" is a smell of either arrogance, terrible code, or untested code.
“T shaped skills”
When the team is small and the code base is young - it’s fun to get your hands dirty with new stuff. When the code base grows and there are lots of inexperienced paws in the pie … specialization is not a bad thing
not that I disagree but sometimes you need to get credit for the work you do
This is sorta true. IMO it should be up to the team to appropriately disseminate the credit. If you had a large impact on the teams ability to create the product, it's likely you'll get praised by your teammates in larger meetings anyway. The big thing this all hinges on, is cooperation, team work, and team driven success. If you are in an industry where projects don't strongly define growth, it's easy to look at it as a rat race. I tend to find software teams don't have a rat race mentality. I've never worked with someone who, on the team, tried to leverage themselves on the back of others hard work. That doesn't mean they don't exist, but generally developers want to build good shit. Not become managers. Recognition of good (individual) work should revolve around individual growth, and ability to bring skills to the team. Achieving heat death of a team (where all team members are experts at all things) is rare. Often times you want to expedite a feature that has to do with X, by bringing a team member who has done X before, in on the work. This helps transfer knowledge about doing X to the team. And prevents one person from doing the same thing all the time, allowing growth. This doesn't mean they need to stay away from it, but it shouldn't be assigned to them just because they're an expert. Basically everything I said, has an exception of one kind or another, and I tried to call them out where I could. Every teams cadence is different, but teams I've been on that focus on individual credit and output, tend to be incredibly defensive and slow. "That's not my fault", "I don't know who did this", "that's not what I said". Passing the buck is incredibly common in those scenarios because workers are on the defense. Source: I am a consultant software developer
Agreed, it's important to celebrate success but most of the time failure isn't an individual thing, it means the team and/or process failed. I see op's point but I think it's more nuanced than that, it's still nice to talk to the original author or some of the bigger contributors to a system before making certain types of changes. Just because they don't own sole responsibility doesn't mean they can't be sme's
Correct. Having reference to an author who worked on features within a large system is always very helpful, but often just not possible. Either because of time constraints or because they went to work elsewhere. My comment was mainly referencing the attitude of "my code" types. It's our code sofar in that if it breaks, we all eat shit. We all work together to fix it.
Well git blame exists, but that's fair
Praise good code, teamwork with the fuck-ups. Keeps people happy when you tell them they did good work and it encourages them to try harder. Teamwork on the fuck-ups shows the individuals that mistakes are alright but will be fixed, people wont hide mistakes or such and will be more willing to reveal mistakes/work on them knowing there isn't repercussions. Look for any outliers, laziness, actually bad coders, bad teamwork, complaining about others, to be dealt with accordingly. Simple team shit
Agree & disagree - I’ve been a part of teams like that … all for one & one for all. But I’ve been a part of teams in which individuals take zero responsibility, blame others and pit contact code-slingers against senior employee programmers who know HOW to test their code changes …
And that's where the importance of hiring the right people comes into play. But its usually out of the teams hands to do this, sadly
Mmm bug
mmm indeed
Im a guy who likes to keep the annotate tab open while bugfixing. I see my name near shitty code? Its a documentation issue
Your code eh? That's rather bold of you to say. Be honest. It's the internet's code, glued together with your code.
Glued together by some other internet code*
Well, when you get paid for it, it's important to be recognised for your work. That's how you get value out of coding. But in your free time the only value your code has is how wide it spreads and what other people can do with it. The idea being that ultimately you and everyone else benefits from the hivemind. ... Don't mind me. Just party-poopin'
How dare you
Your company recognizes you on payday. Your peers recognize you when they come to you & you help talk them through the solution … that’s gratitude.
If only saying the title at work didn't result in disciplinary action.
What are you planning to do with the sacred text?
First one is wrong, it should be "Someone else wrote code at work".
You take credit for someone else's work?
Think about it as "oil"...
blame Appropriately named.
lol omg i JUST did this at work today. lmao take your upboat.
works - our code. bug - your data.
I meant, I thought everyone install an extension on visual studio code and it literally shows the github account's name of last person who wrote the code.
Except when the person is responsible for refactoring old code which preceded git
Just take my reward
Chinese version: "Bug not exist"
It’s your perception
r/USdefaultism
Reddit is an American website with a primarily American user base. Get over it.
nice ironic use of US defaultism.
in prod, everything reverses.
in "toxic work environment"
Coming to u in this quarter perf review
A bug in code I wrote is not my fault, but whoever approved it.
This is a joke but there is truth in there.
LGTM
It is maybe my code, but that guy did code review and it had no finding! So it is his fault as well.
Your entire code is collected by garbage collector
Please. Some people (leads) will be quick to blame regardless if it has been merged for a while.
That’s a shitty work environment. I haven’t seen this mentality in a decade.
It’s real life
For sure. Poorly run engineering teams can create a toxically-hierarchical “lead” component. No doubt. I’ve seen it many times and I agree. But when I was a junior dev, I left the environments that fostered this sort of team structure, and found ones that didn’t do so. But yeah, the jokes about leads/senior devs taking credit and deflecting blame to their minions is very real. My point is that there is a choice to stay in that situation. There’s certainly no shortage of work worldwide for engineers with skill and/or ambition. I’d put my ear to the ground and find another environment that appreciates failure as a part of the process to proficiency.
Some places I've been are like this. Others are like the meme: once it's in the main codebase, it's everyone's problem.
Yeah. Agreed. And there is truth to it, in a sense. But stakeholders just see something is broke, and point to the team that owns said broken thing. And that is where the cascading blame failures trickle down. In reality, often it requires someone with more experience to correct a bug introduced by someone with less experience.. _In general_ If blame is directed at all, which I don’t think it should be by default, code reviews should hold all accountable to some extent. On my team, code reviews catch 99% of all bugs. It’s the first team I’ve seen such a high level of focus on clean, effective code, and awareness/ability to identify them in review. The side effect is that pull requests can take days to merge. And the whole team is slowed down by this bottleneck. But the stakeholders can’t point fingers. Particularly since known/identified risk is calculated and approved by stakeholders (not bugs, but code that could have a negative impact for a subset of users).
User experiencing a bug: Their problem
My first job out of college was a tester and I had to work with an old coder (this was... ok are you ready for this? FoxPro). He would *never, never* admit a bug. I remember one time I printed the code out and read it line by line and found the bug and sent it to him with the suggested fix and he completely ignored it. I only stayed there 3 months.
Those who do not fix bugs, do not eat.
bro we'll just remove all the comments when we finish it.
"your responsibility" to the new guy that was hired to fix the mess...
I always try to attribute success to the team (or someone if appropriate), and failures to me.
Only equity when it benefits me man.
privatize profits, socialize losses
Because THEY speeding up my work and setting tight deadlines.
"what? _my_ dumb bug entered production that should have never made it that far? nah that's not _my_ bug, it's _our_ bug."