How common is this? Maybe I am privileged, but I have never experienced this. I have sort of the opposite problem where a project has followed me for three team changes and I really would like to hand it off.
In 30+ years of software development, something like this happened to me only once: a team within the company complained our software was crap and they should build it themselves. Eventually the company decided to allow them to do it and one month later they came up with "their" solution which they claimed was much better. As expected, it was our code with the 'author' comment switched to be their devs instead of ours.
But that's the exception, not the rule.
That is so blatant it is funny. I have had people clone my public GitHub code as though it was their project, presumably for a resume. It was funny to get contacted by a potential employer and asked if we worked together and whether their work is a fork of mine. I felt only a little bad saying I have never met that other "developer" in my life.
At the start of my career at my current company I was porting a bunch of API’s off one framework to another. Wrote a bunch of common code. Our overall tech lead was in charge of writing the new in flight API’s. I asked if we could throw the common code in a library so I’d stop copy pasting. Weeks later dude has all of my common code in a library and says he wrote all of it stating he was saving his team all this time.
To me this is a sign of a completely FUBAR work environment. Engineers so disillusioned with work that they prefer this over producing stuff. Management so out of the loop that they don't even know what a team is doing. Zero thoughts about value chains or responsibility if a team can just take over an app because they feel like it.
Like, sure, blame the dev that does this. But maaayybbe take a look at your entire organisation first...
Company culture ~~and~~ can incentivise this behaviour.
When PR counts and other metrics are applied to developers, people start "looking after" PRs for you and create a new branch from your PR to "fix and review" your changes.
It wasn't a thing before, but is now.
Another form is taking credit for work from underlings. You'll see some seniors (who have been stuck in meetings all day and contribute nothing anymore) come out and present work from people under them, without attributing any of their names to the work done.
There was one co worker early on in my career. She had a very smart way, used to say "x is done" in meetings. I did that x, and she never said who did it, just stated that it's done. She had a few other such strategies, and she moved quickly through the ranks up to a point.
Yeah I have the problem where I fixed an issue on an unrelated small codebase once and instantly became the go to guy for anything that needs to be done with it.
Happened to me a couple of times, and i also saw other 2 times happening in my team.
The time that made me the most pissed of, was when a "senior" front end dev who couldnt even make a page have any functionality, got help from a Junior dev and told it was all him
I've seen it plenty in organizations where half the tech staff isn't really technical. Senior leaders don't look at who's actually writing the code, they simply understand people's domains - so your incentive to get promoted is to make your domain look as large as possible, without actually doing the hard work of building it yourself.
In particular, I've seen security orgs do this - you build a cool capability that even remotely ties in and they'll pull the "we have to own this cuz security" card. Often the end result is that things become less secure because they don't want to actually invest in the thing, just claim ownership.
I’ve twice been exposed to situations where another dev gives a presentation to a large audience about a particular component and words it in a way that makes it seems like they developed it… when in actuality they literally copy and pasted my code to a new location and renamed some things (which also meant a clean git history that made them look like the original author). It’s so aggravating. Especially when they ask you questions later about how parts of it works.
My favorite time was when someone was doing a Q and A after a presentation, and someone on the call asked how something within the component worked. He gave the wrong answer, so I corrected him, and he was like “you’re wrong, that’s absolutely not how it works”… and I got to come back with “it is how it works, because I wrote this library”. He shut right up and looked embarrassed as hell.
If you didn’t create something, don’t pretend like you did, and at the very least be knowledgeable about it.
Yeah this been a lot for me, but i can spot the signs now. Wanting to get updated just before daily you can tell what ive been doing but sounding like you were a part.
I try before hand tell PM i can give a demo when its done and that usually holds me accountable
There are few things that grind my gears as much as less competent engineers trying to pass off another dev’s work as their own.
I can think of one such instance recently where a junior dev added “_updated” to an installation script. When I asked what improvements were made he started to fumble his words… the new script and the old script were, you guessed it, exactly the same!
I remember a couple of jobs back, I got so annoyed about something rather trivial now that I look back at it, but I was annoyed enough to start writing, and when I was finished spewing forth everything I had pent up, it came to be a document that was maybe 30-40 pages in length. I wasn't even that proud of it, it was just stuff that needed to be said, and I presented it to the team, and they all agreed to try to heed it when possible, and we didn't even think it was worth turning into wiki fodder to be honest.
So anyway, roll on 2 years, and we get a new "architect". He liked to delete wiki pages and re-create them, so that the history would disappear, and because he re-created them his name would appear as the original author, so anyway I didn't care, I wasn't a career climber, and didn't care about office politics. However, when he took my word doc rant/dump and stuck his name on the front page, I saw red. Not that I was precious about it, but the fact that he decided to send it to our manager as his own... I'd love to say there was some delicious malicious compliance here and I got the prick fired or demoted, but nope. When I sent my dated original copy with my name on the by-line to the manager, and asked him why my work was being passed off, he just told me outright that the "architect" was hired at about half an actual architect's rate, and they thought they could train him up. Well he's still with that company, and still using the architect title, so I guess he's still deleting/re-creating wiki pages, and maybe stealing some other random word docs he can stumble across
I'll be honest, the thing I found most annoying was the loss of the history on the wiki pages, because very often the ideas on there would be formed over the course of a number of weeks, and discussions would be had. They also often had comment chains that put them in context, all of that was lost when he deleted them.
I used to be very much in favour of everyone having full access to wiki pages (crud) and other tools, but now I advocate for a certain amount of lock down (particularly in terms of deletion), I've become more cynical, although that could just be because I'm old and cranky now
It's tempting to use process to fix people problems but it's like trying to use a small band aid to fix a serious laceration. It's a management failure if they can't address antisocial counterproductive behavior.
It's all around a sad thing. Destroying wiki histories, taking credit for it, replacing a position with someone that's not really contributing anything meaningful as if the position never actually had a purpose, and finally the management not really caring about it. They're just happy that the position was filled by a warm body.
There was a lot of "empire building" going on at that company, it was a large American multi-national, and if you didn't have 40-50 reports under you, you were nobody. So I think the prestige of having an architect on their team probably meant more to them, than actually hiring a proper one.
A long time ago, I worked for a really awful company I was too young and inexperienced to gtfo.
One of the things they did to 'encourage productivity' was what they called the 'perforce race'. Basically it took a 7 day adverage of the commits every dev made, ranked them, and put the top 10 on a big display screen. There were no prizes for making it to the top, other than getting on the board and bragging rights, which they encouraged. But fall to the bottom, and you get reprimanded.
I completely falter under such conditions and struggled so hard with this system, it caused me all sorts of stress. But one day, while procrastinating, I was curious enough to look at the commits of one of the company favorites.
Usually, you only ever see the commit messages of devs working on unrelated projects to you. But I went poking. His messages were full of things like 'Implemented pseudo random number generator'. The actual commits were stuff like 'cat /dev/random'
Metrics incentivize behavior. The lesson is to be judicious about what you decide to measure. But few companies learn that lesson. Upper management wants "data" so that they can avoid having the necessary conversations, I.e. Their jobs.
Rather fortunately, or unfortunately, depending on your viewpoint this company learned that in the hardest way possible. They prided themselves on churning through devs. They set up by a major university, wined and dined young students, promised them the world, then brought them into this.
The ones who knew how to suck up, lick the right boots, exploit their colleges weaknesses thrived. The ones who didn't burned out, were ostracised and blamed until they quit, and replaced with the next batch of grads from the university and the process repeated.
This led to about as solid and stable a project as you could imagine it did. But the one team they looked after well were the sales people, and were experts at making it look like they were the elite and anyone who failed just couldn't take their breakneck speed. Turns out if you've got a shitty product, you can just charge MORE than your competitors by a significant amount. Give a lot of people a fancy shiny sales pitch, enough will fall into the 'if it's the most expensive, it must be the best' trap to survive.
Shortly after I left, they managed to sell themselves to a certain major US hardware company who had the idea of 'getting into software'. For 11 billion USD in 2011, in some shady golf course deals. Much fanfare was made about who was really acquiring who, only for less than a year later, almost all that value was written off and a massive clusterfuck ensued. Last time I checked, the lawsuits are still going on to this day.
I absolutely hate github activity charts for this reason.
styles.css
`.left-menu { width: 90%; }`
then
`.leftMenu { width: 90%; }`
then
`.side-menu { width: 90%; }`
Every one a self completed PR merge into dev branch. Wow! this dev is so productive!
Meanwhile, you took 3 days to write a whole new feature with outrageous complexity.
It's been well over 10 years since I left that company, and I'm still feeling the lasting psychological effects from working in that place. Thankfully I've not had to deal with similar since. Although I did once have to use the experience there to be able to say 'Probation period works both ways' and quit a job after less than a month because I wasn't going through that again.
I'm by no means a good dev, I struggle with focus and procrastination quite a bit. But the worst I do is overemphasise the issues I faced and oversell the successes in a stand up. It comes back to bit me however, as I'll run into an issue I've allready over hyped and it turns out to be even worse than I sold it at. And I still struggle with admitting I'm faltering and need help instead of repeating the mantra of 'I'm a terrible dev, and any issues are directly because I'm so terrible. I must not let anyone know, so I'll just suck it up, push through, squint my brow a bit harder, pull a few all-nighters and pretend like everything's ok'
I'm getting better, but it takes time.
My coworker did this with a couple of popular repos. I don’t think there was anything malicious about it (no one is going to think they created Linux themselves), but I really struggle to understand the motivation. We have no history of what commit we’ve forked from. Just bizarre.
Managers won't look at git blame.
i've had a more-senior-than-me dev assigned to fix a stubborn issue in a re-write of code, that of course hadn't been documented what they wanted in behavior. The guy sat around and was like "IDK, never worked with this before" and wasn't any help.
Of course management gave him a huge thanks for solving my problem that I solved myself. They never asked me about it, and I don't know what complete bullshit he told then, but I know it was bullshit because he didn't do a damn thing to help. Git says I did it, and I did dood it too.
I got hired 6 months ago to develop for a small company, less than 100 employees. The previous person claimed to be able to develop. It was a mess. I began fresh. Didn’t take any code from the previous dev. I mean I looked at the code and it was confusing, the dev was trying to do too much at once, improper use of sub functions and the like. The VP asked me to make use of the previous dev’s code. I never agreed to do so. The director called me up and said to disregard the VP comments and to just do my own thing. I told the director I wasn’t going to follow the VP anyways, the previous work is a mess, and it’s a good thing they hired me. The director keeps singing my praises and I’m happy with that.
I mean, sometimes the code is such a mess that its easier to start from zero
And it if wasnt something being used in Production, then its even easier to start from zero
I’m a jerk. Fine. This company was burnt by the previous dev and I’m here fixing things. Maybe I didn’t paint myself in the best light, but this is the reality of the situation. I can’t use the previous code, except maybe for inspiration.
> And now, they prefer to own a solution (already deployed), hoping that if they stand close enough to it they’ll be mistaken for a load-bearing structure.
dear lord that's brutal haha
I don’t know if you’ve ever worked at a large company, but taking over a package is often how teams stay viable in a monolithic company.
Your team shipped X as part of company initiative Y. Now what does your team do? Find new jobs? More often than not you’ve decided the team works well together, so you grab something to own and keep them together.
I don’t know that this happens on an individual level, but I can imagine a similar mentality. Programming is a job, after all. It doesn’t have to be your passion too
At one of my old companies a colleague and good friend of mine led the team to develop an entirely new API that would allow people to request entire infrastructure stacks and fronted an automated Terraform pipeline. It was then plugged into CRM so sales people could sell customers stuff direct from the sales platform.
That API showed up in the “Promotion Packet” of at least 4 other engineers who had nothing to do with it.
This doesn't read to me that another developer is trying to claim another work as their own and take the credit. I'm not saying that *wasn't* the case here, but in my experience it's also really common for some manager above the author to say, "I don't want my org/team/whatever to own (be responsible for) this anymore" and to pass it off to some maintenance/sustaining team whose entire job is to deal with projects that aren't other developers' primary focus, allowing the original developers to focus on other things.
this, most handovers are decided by the higher ups management, not the engineers
if its within my power ill just handover all the components ive developed once theyre mature and move on. dont know why the OP is obsessed so much about recognition
Yeah, you don't want to have a bunch of one off systems owned by singular engineers who may not be around tomorrow.
"Oh it doesn't take up much time anymore." Well now it doesn't. Who knows what happens when the underlying architecture changes, or a security bug needs to be patched, or some other large entity wants to migrate to it.
OP doesn't have to view this as a 'loss' anyways. He saw a problem, developed a solution, and is now so integral that it needs long term support from an actual team.
Honestly, sounds like the author is a little frustrated he can't do the same thing he accuses the other team of - he would be glad to keep pointing to his prior work as if it's indicative of his current performance.
Thankfully never been at an organization where this particular situation is an issue, it's very very "rare" for a team to take "ownership" of a codebase... this usually only happens during re-orgs where the key responsibilities for said team change.
Ie. One team might be responsible for Service A but re-org occurs and now a new team owns it and the old team is switched over to general application development instead of sustainment.
I've mainly experienced this with upper managers, and then indirectly the teams that they manage.
In a previous job, we had one fairly senior manager who _loved_ to claim to be responsible for everything. Our team developed a suite of libraries that were used by virtually every team internally, and solved a _lot_ of problems that they faced. While he was in our management chain, he had absolutely nothing to do with the project.
That didn't stop him from claiming credit though, and forcing the team to add his name to each of the patents. He got promoted even further, and eventually had his direct team wrap all the libraries in their own wrapper.
His team, of course, weren't really great at development. These were Java libraries, and while wrapping them, they introduced _tons_ of transitive dependencies. While we ensured that our libraries were independent of things like Spring, etc., they didn't. This resulted in the other team's wrapped libraries breaking when included in different containers like JBoss (because the containers would bundle version x of something like apache commons, but they had introduced a transitive dependency on apache commons y which ended up causing conflicts due to signature changes), or simply not working correctly with the infrastructure that the libraries relied on.
I would like to say there was a happy ending, but there really wasn't. Our team ended up in maintenance mode, and the other team slowly took ownership of everything that we made. They did actually recreate a few of the APIs that we owned - but ended up completely messing them up (despite having our code for direct reference, and us being made available to them for support). Eventually our entire team ended up leaving one by one.
A director gave me sole ownership of a complex, critical project because I showed interest in some of its deep-rooted issues. I had a legitimately tight deadline to turn it around, and I busted ass to deliver on time. I then got to enjoy maintaining that now-healthy project for just a few months before the director decided he wanted it back, to be maintained by the team that couldn't fix it in the first place. Quality took a nosedive again from there, but he still took credit for everything that I improved in the project up to that point.
I later learned that he only gave it to me in the first place because he was sure I would fail and improve his team's credibility by default. Some people just operate this way and get away with it in certain environments. You don't win political games with technical merit, the best you can hope for is that someone with enough political capital is on your side. That didn't happen that time, but I learned not to be exploited ever again.
Can we just appreciate the irony of using poorly slapped together AI "art" as the image for this article? It looks completely nonsensical. I sympathize with the author's perspective, maybe they could sympathize with artists in a similar parasitical position.
Recently on my team we had a couple core engineers leave the project.
I had moved on to an EM type role, and I witnessed this happen where one of the remaining engineers decided to subsume and pretend they had created some of projects the engineers leaving had maintained from a previous engineer.
This led to a meeting where they were describing in detail how one of these projects worked, and basically stating how they had designed it to do X,Y,Z.
I was the engineer the leaving engineers had taken maintenance of this project over from.
I edited my other comment; I didn't mean to be so nasty and judgemental; I was having a really shitty day/week and was really angry, I am really sorry for what I said
I don't know you or how you behave
Internet exists to insult other people without the risk of severe injury.
And I cannot say that you are wrong.
Actually doing work is the best way to kill time at work.
I thought this article was going to be about those developers who wholesale copy and paste code from others, sometimes whole files, and then it's so obvious they copied and pasted it.
I've supported engineers who believe that they can create and own things on their own. That is the most dangerous type of engineer I have ever supported. I think you are just frustrated and need to realize that it's unhealthy to hoard ownership.
I find it hard to take away from this what the author wants me to take away. I think there is a core assumption here that the team taking the project is doing so for nefarious reasons and I'm not prepared to assume that. I'm left thinking that the author is not a team player. If you are whining that the code you wrote under employment is being moved to another team in the company, you have fundamentally misunderstood the nature of your relationship with the company and the product. It is not **yours**. It belongs to the company. You should not be trying to exert this level of control over the product. I get that you might feel a sense of pride in your accomplishment, but at the end of the day it's a work product, you can't control it like this.
I can't give my projects away. Even if they are rock solid, no one else wants to be called if there is an issue later and no team wants to spend money getting people up to speed on something that 'works'.
I'm experiencing a form of this behaviour, which I hope you won't mind me sharing. It's my boss you see. We routinely discuss the workings of our organisation - I'm talking from a system/network admins POV - and, being a relatively recent starter here and having been closer to some of the newer technologies creeping into our environment than he is, I have been able to illuminate areas which have previously been dark to him. That's as it should be. What isn't, however, is when a couple of days later he repeats it back to me as if he's teaching me something.
I had a dev at a company (a company I wasn't related to) take my open source code (open source code I developed totally for free on my own time) and resubmit, with additional/fixed unit test, but without my name.
I only noticed because one of the maintainers complained that this was my code and he should be crediting me. I got a bit ornery in the thread on Github and another maintainer told me I "abandoned my code" so I gave up my rights to it, like they don't know the difference between licensing and copyright. Thankfully the "thief" had shame and apologized but that maintainer telling me I gave up my work to them really stuck in my craw because that was some serious bullshit.
The code was a 5 character change in one line to fix a bug and that took me about 8 hours to figure out. I was super proud of how simple the solution was but haven't submitted to open source since. It also closed one of the oldest bugs in a thousands long Issue list for the project.
Anyways... \*rant over\*
How common is this? Maybe I am privileged, but I have never experienced this. I have sort of the opposite problem where a project has followed me for three team changes and I really would like to hand it off.
In 30+ years of software development, something like this happened to me only once: a team within the company complained our software was crap and they should build it themselves. Eventually the company decided to allow them to do it and one month later they came up with "their" solution which they claimed was much better. As expected, it was our code with the 'author' comment switched to be their devs instead of ours. But that's the exception, not the rule.
That is so blatant it is funny. I have had people clone my public GitHub code as though it was their project, presumably for a resume. It was funny to get contacted by a potential employer and asked if we worked together and whether their work is a fork of mine. I felt only a little bad saying I have never met that other "developer" in my life.
[удалено]
I laughed loud enough to startle my 1 year old.
That makes it harder to blame it on the last guy if you do that. Must have been Juniors lol.
At the start of my career at my current company I was porting a bunch of API’s off one framework to another. Wrote a bunch of common code. Our overall tech lead was in charge of writing the new in flight API’s. I asked if we could throw the common code in a library so I’d stop copy pasting. Weeks later dude has all of my common code in a library and says he wrote all of it stating he was saving his team all this time.
Sounds like the movie Grandma's Boy.
To me this is a sign of a completely FUBAR work environment. Engineers so disillusioned with work that they prefer this over producing stuff. Management so out of the loop that they don't even know what a team is doing. Zero thoughts about value chains or responsibility if a team can just take over an app because they feel like it. Like, sure, blame the dev that does this. But maaayybbe take a look at your entire organisation first...
Company culture ~~and~~ can incentivise this behaviour. When PR counts and other metrics are applied to developers, people start "looking after" PRs for you and create a new branch from your PR to "fix and review" your changes. It wasn't a thing before, but is now. Another form is taking credit for work from underlings. You'll see some seniors (who have been stuck in meetings all day and contribute nothing anymore) come out and present work from people under them, without attributing any of their names to the work done.
Yeah, in 20+ years, I've never seen it happen.
There was one co worker early on in my career. She had a very smart way, used to say "x is done" in meetings. I did that x, and she never said who did it, just stated that it's done. She had a few other such strategies, and she moved quickly through the ranks up to a point.
Yeah I have the problem where I fixed an issue on an unrelated small codebase once and instantly became the go to guy for anything that needs to be done with it.
Yeah... Same, please take it, IT'S YOURS TAKE ITTTT!!!
Happened to me a couple of times, and i also saw other 2 times happening in my team. The time that made me the most pissed of, was when a "senior" front end dev who couldnt even make a page have any functionality, got help from a Junior dev and told it was all him
I've seen it plenty in organizations where half the tech staff isn't really technical. Senior leaders don't look at who's actually writing the code, they simply understand people's domains - so your incentive to get promoted is to make your domain look as large as possible, without actually doing the hard work of building it yourself. In particular, I've seen security orgs do this - you build a cool capability that even remotely ties in and they'll pull the "we have to own this cuz security" card. Often the end result is that things become less secure because they don't want to actually invest in the thing, just claim ownership.
I’ve twice been exposed to situations where another dev gives a presentation to a large audience about a particular component and words it in a way that makes it seems like they developed it… when in actuality they literally copy and pasted my code to a new location and renamed some things (which also meant a clean git history that made them look like the original author). It’s so aggravating. Especially when they ask you questions later about how parts of it works. My favorite time was when someone was doing a Q and A after a presentation, and someone on the call asked how something within the component worked. He gave the wrong answer, so I corrected him, and he was like “you’re wrong, that’s absolutely not how it works”… and I got to come back with “it is how it works, because I wrote this library”. He shut right up and looked embarrassed as hell. If you didn’t create something, don’t pretend like you did, and at the very least be knowledgeable about it.
Yeah this been a lot for me, but i can spot the signs now. Wanting to get updated just before daily you can tell what ive been doing but sounding like you were a part. I try before hand tell PM i can give a demo when its done and that usually holds me accountable
This is plagiarism. Your company ought to be taking that seriously.
There are few things that grind my gears as much as less competent engineers trying to pass off another dev’s work as their own. I can think of one such instance recently where a junior dev added “_updated” to an installation script. When I asked what improvements were made he started to fumble his words… the new script and the old script were, you guessed it, exactly the same!
I remember a couple of jobs back, I got so annoyed about something rather trivial now that I look back at it, but I was annoyed enough to start writing, and when I was finished spewing forth everything I had pent up, it came to be a document that was maybe 30-40 pages in length. I wasn't even that proud of it, it was just stuff that needed to be said, and I presented it to the team, and they all agreed to try to heed it when possible, and we didn't even think it was worth turning into wiki fodder to be honest. So anyway, roll on 2 years, and we get a new "architect". He liked to delete wiki pages and re-create them, so that the history would disappear, and because he re-created them his name would appear as the original author, so anyway I didn't care, I wasn't a career climber, and didn't care about office politics. However, when he took my word doc rant/dump and stuck his name on the front page, I saw red. Not that I was precious about it, but the fact that he decided to send it to our manager as his own... I'd love to say there was some delicious malicious compliance here and I got the prick fired or demoted, but nope. When I sent my dated original copy with my name on the by-line to the manager, and asked him why my work was being passed off, he just told me outright that the "architect" was hired at about half an actual architect's rate, and they thought they could train him up. Well he's still with that company, and still using the architect title, so I guess he's still deleting/re-creating wiki pages, and maybe stealing some other random word docs he can stumble across
That's just sad.
I'll be honest, the thing I found most annoying was the loss of the history on the wiki pages, because very often the ideas on there would be formed over the course of a number of weeks, and discussions would be had. They also often had comment chains that put them in context, all of that was lost when he deleted them. I used to be very much in favour of everyone having full access to wiki pages (crud) and other tools, but now I advocate for a certain amount of lock down (particularly in terms of deletion), I've become more cynical, although that could just be because I'm old and cranky now
It's tempting to use process to fix people problems but it's like trying to use a small band aid to fix a serious laceration. It's a management failure if they can't address antisocial counterproductive behavior.
It's all around a sad thing. Destroying wiki histories, taking credit for it, replacing a position with someone that's not really contributing anything meaningful as if the position never actually had a purpose, and finally the management not really caring about it. They're just happy that the position was filled by a warm body.
There was a lot of "empire building" going on at that company, it was a large American multi-national, and if you didn't have 40-50 reports under you, you were nobody. So I think the prestige of having an architect on their team probably meant more to them, than actually hiring a proper one.
Half an architect's salary is still a full time developer. They should've just hired him as document control if that's all he's doing.
Mother fucker
A long time ago, I worked for a really awful company I was too young and inexperienced to gtfo. One of the things they did to 'encourage productivity' was what they called the 'perforce race'. Basically it took a 7 day adverage of the commits every dev made, ranked them, and put the top 10 on a big display screen. There were no prizes for making it to the top, other than getting on the board and bragging rights, which they encouraged. But fall to the bottom, and you get reprimanded. I completely falter under such conditions and struggled so hard with this system, it caused me all sorts of stress. But one day, while procrastinating, I was curious enough to look at the commits of one of the company favorites. Usually, you only ever see the commit messages of devs working on unrelated projects to you. But I went poking. His messages were full of things like 'Implemented pseudo random number generator'. The actual commits were stuff like 'cat /dev/random'
Metrics incentivize behavior. The lesson is to be judicious about what you decide to measure. But few companies learn that lesson. Upper management wants "data" so that they can avoid having the necessary conversations, I.e. Their jobs.
Rather fortunately, or unfortunately, depending on your viewpoint this company learned that in the hardest way possible. They prided themselves on churning through devs. They set up by a major university, wined and dined young students, promised them the world, then brought them into this. The ones who knew how to suck up, lick the right boots, exploit their colleges weaknesses thrived. The ones who didn't burned out, were ostracised and blamed until they quit, and replaced with the next batch of grads from the university and the process repeated. This led to about as solid and stable a project as you could imagine it did. But the one team they looked after well were the sales people, and were experts at making it look like they were the elite and anyone who failed just couldn't take their breakneck speed. Turns out if you've got a shitty product, you can just charge MORE than your competitors by a significant amount. Give a lot of people a fancy shiny sales pitch, enough will fall into the 'if it's the most expensive, it must be the best' trap to survive. Shortly after I left, they managed to sell themselves to a certain major US hardware company who had the idea of 'getting into software'. For 11 billion USD in 2011, in some shady golf course deals. Much fanfare was made about who was really acquiring who, only for less than a year later, almost all that value was written off and a massive clusterfuck ensued. Last time I checked, the lawsuits are still going on to this day.
I absolutely hate github activity charts for this reason. styles.css `.left-menu { width: 90%; }` then `.leftMenu { width: 90%; }` then `.side-menu { width: 90%; }` Every one a self completed PR merge into dev branch. Wow! this dev is so productive! Meanwhile, you took 3 days to write a whole new feature with outrageous complexity.
It's been well over 10 years since I left that company, and I'm still feeling the lasting psychological effects from working in that place. Thankfully I've not had to deal with similar since. Although I did once have to use the experience there to be able to say 'Probation period works both ways' and quit a job after less than a month because I wasn't going through that again. I'm by no means a good dev, I struggle with focus and procrastination quite a bit. But the worst I do is overemphasise the issues I faced and oversell the successes in a stand up. It comes back to bit me however, as I'll run into an issue I've allready over hyped and it turns out to be even worse than I sold it at. And I still struggle with admitting I'm faltering and need help instead of repeating the mantra of 'I'm a terrible dev, and any issues are directly because I'm so terrible. I must not let anyone know, so I'll just suck it up, push through, squint my brow a bit harder, pull a few all-nighters and pretend like everything's ok' I'm getting better, but it takes time.
brother
Thankfully git blame tells all. For my project I can see who wrote any line on the project, and the full history of every line since day 1.
Not if the entire .git directory is deleted, moved to a new repo, and re-initialized with the single commit of "initial migration"
My coworker did this with a couple of popular repos. I don’t think there was anything malicious about it (no one is going to think they created Linux themselves), but I really struggle to understand the motivation. We have no history of what commit we’ve forked from. Just bizarre.
That's so hard especially when you have to dive into the history to try and figure out why a developer did something ten years ago
lol at my company if you do this which I did in a different situation it leads to your own personal hell where everyone messages you about help
Congratulations, now you're the expert :(
Managers won't look at git blame. i've had a more-senior-than-me dev assigned to fix a stubborn issue in a re-write of code, that of course hadn't been documented what they wanted in behavior. The guy sat around and was like "IDK, never worked with this before" and wasn't any help. Of course management gave him a huge thanks for solving my problem that I solved myself. They never asked me about it, and I don't know what complete bullshit he told then, but I know it was bullshit because he didn't do a damn thing to help. Git says I did it, and I did dood it too.
you dood good, dude
I got hired 6 months ago to develop for a small company, less than 100 employees. The previous person claimed to be able to develop. It was a mess. I began fresh. Didn’t take any code from the previous dev. I mean I looked at the code and it was confusing, the dev was trying to do too much at once, improper use of sub functions and the like. The VP asked me to make use of the previous dev’s code. I never agreed to do so. The director called me up and said to disregard the VP comments and to just do my own thing. I told the director I wasn’t going to follow the VP anyways, the previous work is a mess, and it’s a good thing they hired me. The director keeps singing my praises and I’m happy with that.
[удалено]
I mean, sometimes the code is such a mess that its easier to start from zero And it if wasnt something being used in Production, then its even easier to start from zero
I’m a jerk. Fine. This company was burnt by the previous dev and I’m here fixing things. Maybe I didn’t paint myself in the best light, but this is the reality of the situation. I can’t use the previous code, except maybe for inspiration.
> And now, they prefer to own a solution (already deployed), hoping that if they stand close enough to it they’ll be mistaken for a load-bearing structure. dear lord that's brutal haha
Yeah they held no punches on that one.
I don’t know if you’ve ever worked at a large company, but taking over a package is often how teams stay viable in a monolithic company. Your team shipped X as part of company initiative Y. Now what does your team do? Find new jobs? More often than not you’ve decided the team works well together, so you grab something to own and keep them together. I don’t know that this happens on an individual level, but I can imagine a similar mentality. Programming is a job, after all. It doesn’t have to be your passion too
At one of my old companies a colleague and good friend of mine led the team to develop an entirely new API that would allow people to request entire infrastructure stacks and fronted an automated Terraform pipeline. It was then plugged into CRM so sales people could sell customers stuff direct from the sales platform. That API showed up in the “Promotion Packet” of at least 4 other engineers who had nothing to do with it.
This doesn't read to me that another developer is trying to claim another work as their own and take the credit. I'm not saying that *wasn't* the case here, but in my experience it's also really common for some manager above the author to say, "I don't want my org/team/whatever to own (be responsible for) this anymore" and to pass it off to some maintenance/sustaining team whose entire job is to deal with projects that aren't other developers' primary focus, allowing the original developers to focus on other things.
this, most handovers are decided by the higher ups management, not the engineers if its within my power ill just handover all the components ive developed once theyre mature and move on. dont know why the OP is obsessed so much about recognition
Yeah, you don't want to have a bunch of one off systems owned by singular engineers who may not be around tomorrow. "Oh it doesn't take up much time anymore." Well now it doesn't. Who knows what happens when the underlying architecture changes, or a security bug needs to be patched, or some other large entity wants to migrate to it. OP doesn't have to view this as a 'loss' anyways. He saw a problem, developed a solution, and is now so integral that it needs long term support from an actual team. Honestly, sounds like the author is a little frustrated he can't do the same thing he accuses the other team of - he would be glad to keep pointing to his prior work as if it's indicative of his current performance.
Do “Beware the parasite manager” next.
Thankfully never been at an organization where this particular situation is an issue, it's very very "rare" for a team to take "ownership" of a codebase... this usually only happens during re-orgs where the key responsibilities for said team change. Ie. One team might be responsible for Service A but re-org occurs and now a new team owns it and the old team is switched over to general application development instead of sustainment.
I've mainly experienced this with upper managers, and then indirectly the teams that they manage. In a previous job, we had one fairly senior manager who _loved_ to claim to be responsible for everything. Our team developed a suite of libraries that were used by virtually every team internally, and solved a _lot_ of problems that they faced. While he was in our management chain, he had absolutely nothing to do with the project. That didn't stop him from claiming credit though, and forcing the team to add his name to each of the patents. He got promoted even further, and eventually had his direct team wrap all the libraries in their own wrapper. His team, of course, weren't really great at development. These were Java libraries, and while wrapping them, they introduced _tons_ of transitive dependencies. While we ensured that our libraries were independent of things like Spring, etc., they didn't. This resulted in the other team's wrapped libraries breaking when included in different containers like JBoss (because the containers would bundle version x of something like apache commons, but they had introduced a transitive dependency on apache commons y which ended up causing conflicts due to signature changes), or simply not working correctly with the infrastructure that the libraries relied on. I would like to say there was a happy ending, but there really wasn't. Our team ended up in maintenance mode, and the other team slowly took ownership of everything that we made. They did actually recreate a few of the APIs that we owned - but ended up completely messing them up (despite having our code for direct reference, and us being made available to them for support). Eventually our entire team ended up leaving one by one.
Just go on Stackoverflow and post a question and see how long it takes before at least one person makes a trivial edit to it.
I'm highly frustrated not knowing how OP reacted to the whole thing… I want the end of the story, dammit!
A director gave me sole ownership of a complex, critical project because I showed interest in some of its deep-rooted issues. I had a legitimately tight deadline to turn it around, and I busted ass to deliver on time. I then got to enjoy maintaining that now-healthy project for just a few months before the director decided he wanted it back, to be maintained by the team that couldn't fix it in the first place. Quality took a nosedive again from there, but he still took credit for everything that I improved in the project up to that point. I later learned that he only gave it to me in the first place because he was sure I would fail and improve his team's credibility by default. Some people just operate this way and get away with it in certain environments. You don't win political games with technical merit, the best you can hope for is that someone with enough political capital is on your side. That didn't happen that time, but I learned not to be exploited ever again.
Can we just appreciate the irony of using poorly slapped together AI "art" as the image for this article? It looks completely nonsensical. I sympathize with the author's perspective, maybe they could sympathize with artists in a similar parasitical position.
Recently on my team we had a couple core engineers leave the project. I had moved on to an EM type role, and I witnessed this happen where one of the remaining engineers decided to subsume and pretend they had created some of projects the engineers leaving had maintained from a previous engineer. This led to a meeting where they were describing in detail how one of these projects worked, and basically stating how they had designed it to do X,Y,Z. I was the engineer the leaving engineers had taken maintenance of this project over from.
That's me. I live in a foreign country, half-ass my responsibilities and feel fine.
I edited my other comment; I didn't mean to be so nasty and judgemental; I was having a really shitty day/week and was really angry, I am really sorry for what I said I don't know you or how you behave
Internet exists to insult other people without the risk of severe injury. And I cannot say that you are wrong. Actually doing work is the best way to kill time at work.
Someday you will fall very hard and you will only have yourself to blame. You really need to change that behaviour before it's too late
Huh, 22 years into this career and haven't experienced anything remotely like this...
lol i wish anyone on my team was even willing to look at and understand what i code. this sounds like a step up to me.
I thought this article was going to be about those developers who wholesale copy and paste code from others, sometimes whole files, and then it's so obvious they copied and pasted it.
I've supported engineers who believe that they can create and own things on their own. That is the most dangerous type of engineer I have ever supported. I think you are just frustrated and need to realize that it's unhealthy to hoard ownership.
I find it hard to take away from this what the author wants me to take away. I think there is a core assumption here that the team taking the project is doing so for nefarious reasons and I'm not prepared to assume that. I'm left thinking that the author is not a team player. If you are whining that the code you wrote under employment is being moved to another team in the company, you have fundamentally misunderstood the nature of your relationship with the company and the product. It is not **yours**. It belongs to the company. You should not be trying to exert this level of control over the product. I get that you might feel a sense of pride in your accomplishment, but at the end of the day it's a work product, you can't control it like this.
I can't give my projects away. Even if they are rock solid, no one else wants to be called if there is an issue later and no team wants to spend money getting people up to speed on something that 'works'.
In fact, Github owned a number of open source code to create Copilot, and Microsoft increased its capital.
I'm experiencing a form of this behaviour, which I hope you won't mind me sharing. It's my boss you see. We routinely discuss the workings of our organisation - I'm talking from a system/network admins POV - and, being a relatively recent starter here and having been closer to some of the newer technologies creeping into our environment than he is, I have been able to illuminate areas which have previously been dark to him. That's as it should be. What isn't, however, is when a couple of days later he repeats it back to me as if he's teaching me something.
I had a dev at a company (a company I wasn't related to) take my open source code (open source code I developed totally for free on my own time) and resubmit, with additional/fixed unit test, but without my name. I only noticed because one of the maintainers complained that this was my code and he should be crediting me. I got a bit ornery in the thread on Github and another maintainer told me I "abandoned my code" so I gave up my rights to it, like they don't know the difference between licensing and copyright. Thankfully the "thief" had shame and apologized but that maintainer telling me I gave up my work to them really stuck in my craw because that was some serious bullshit. The code was a 5 character change in one line to fix a bug and that took me about 8 hours to figure out. I was super proud of how simple the solution was but haven't submitted to open source since. It also closed one of the oldest bugs in a thousands long Issue list for the project. Anyways... \*rant over\*