6 ms·

> Take this as a learning experience: don't assume that you are at a startup where people will drop everything to handle a request from you right away. This do

> Take this as a learning experience: don't assume that you are at a startup where people will drop everything to handle a request from you right away. This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I've been in the same situation multiple times. Sometimes I've been allowed to do the work and sometimes not. In the cases where I was allowed to do the work, I certainly took longer than they would have taken, but the work was complete much earlier (months) than they would have done it, the quality was just as high, and the other group didn't really have to put effort into it. It was actually a win-win for everyone and resulted in products actually shipping on time. On the other hand, the organizations that didn't allow this were all basically operational disasters. This sort of thing was just one red flag of many. I'd recommend /u/lopkeny12ko to either stop caring and just put in minimal effort or find somewhere new to work. It doesn't sound to me like they're taking advantage of your skills.

Sevii 5y ago
Away team work is standard at Amazon. Of course you still may have to go to office hours and sign up for busy teams.
- kuraudo 5y ago
  I was going to say the same thing here. It amazes me that the company I always assumed was massive, slow, and bloated actually moves at the speed of light compared to op's acquiring company.
tyre 5y ago
> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I believe the manager explains it right after that. They have compliance reasons that not just anyone can access this codebase. It's also possible that the manager has acquiesced to types of requests before and it was a mess — new engineer doesn't understand they system, requirements of its scale (note that this is a new engineer from a startup so the world that they are familiar with is not this one), and either 1) needs hand-holding 2) has code that doesn't meet their standards and requires extensive code review back-and-forth. There are many reasons why, "let me into your codebase" isn't a priority for the team you're talking to. Many legitimate, reasonable reasons. > It doesn't sound to me like they're taking advantage of your skills. Working as part of a large organization _is_ a skill. One that the OP doesn't seem to have. Which is understandable; they themselves said that they have always worked at startups. You can't walk into an entirely different context with challenges you're not familiar with, then expect to behave the same way and get the results you're used to.
- ethbr0 5y ago
  There is no compliance reason why OP couldn't have read access to look at the source. If there is a compliance issue with someone looking at source, then either (a) their source control is misconfigured, (b) their source control is being misused, or (c) they have no policy to guarantee appropriate use and detect improper use. Any organization that uses compliance as an excuse for opaqueness, creating silos, and guarding projects like treasure is toxic, especially if people there are so institutionalized that they think that's a valid reason, and OP should begin looking for another job ASAP. (Said having worked at both companies with global read visibility & access scoped to team only)
  - staticassertion 5y ago
    > There is no compliance reason why OP couldn't have read access to look at the source. Companies can have whatever compliance terms they like, whether they map to ISO27001 controls or not. > Any organization that uses compliance as an excuse for opaqueness, creating silos, and guarding projects like treasure is toxic, especially if people there are so institutionalized that they think that's a valid reason, and OP should begin looking for another job ASAP. Or they believe it's a reasonable control. Let's imagine this is a company working on self driving cars. Your source code is probably something you want to protect very carefully.
  - bostik 5y ago
    > * There is no compliance reason why OP couldn't have read access to look at the source.* At a guess, I would say you have never worked with DRM integration. Getting access even to the binary SDK's can take months, and if you ever need the special license to work with the thing on source code level, prepare for a delay of several quarters. Long time ago, Nokia was integrating Microsoft's DRM. I got to witness first hand the red tape needed to allow a new person to even see the source code the team worked with. And this was thanks to requirement MS imposes on their licensees. The other code I know of that was heavily siloed were Nokia's DSP codecs. Pretty sure there were other corners with similarly absurd external restrictions but at least I was never exposed to them.
pavel_lishin 5y ago
> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I know of at least two teams who would kindly ask me to refrain from doing this; me doing the work doesn't mean they don't have to do any. They still have to take the time to review my code, provide feedback, possibly explain to me their standards and conventions. Afterward, they have to maintain and own my changes - what if I introduce a bug? What if the feature is popular enough that they now have to add additional functionality onto it?
- piyh 5y ago
  Plus the ability to jump into another repo with zero assistance to implement a change is not common. Aside from the technical skills needed, other stuff like filling out change control forms or making sure the build passes CI isn't something you can do with repo access alone. To go down all those possible roads with anyone who asks can turn into a full time job when you multiply it in a large org. Then after supporting those requests and cleaning up after those people, you job becomes lumpy and irregular with tons of people owning your time. Getting out of a role like that either takes years or quitting.
- Joeri 5y ago
  Setting up teams for inner source work can be done and tends to earn itself back, but most teams aren’t set up for this. Typical solutions for the issues you mention: trusted committers to review and merge work without having that role burden the whole team, contribution guidelines to set standards, 30 day warranty to avoid getting code dumped in their lap that’s broken but also avoid having too many owners of parts of the codebase. Anyway, I would recommend going to the inner source commons website and reading a few of the success stories like paypal’s.
  - sokoloff 5y ago
    Interesting and I’d love to hear more about this “30-day warranty” concept. How’s that work in practice and how do you use it to avoid having too many owners? (Does it revert to the original system owners after 30 days?)
yongjik 5y ago
> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. Probably because $BIG_CORP was also a nimble startup ages ago, and people had written important APIs as fast as possible because they had to, and they were successful, and the company grew, and three years later the core team realized they're supporting three different sets of APIs which all overlap but do things slightly differently, and because 70% of the company revenue depended on it, it took five more years and the souls of a few dozen developers to finally get it cleaned up. Understandably they don't want to open their codebase to someone thinking "It's just one feature that takes a few days to add! What's the issue?" - they're probably thinking "Will this make sense five years from now? What if $ACRUIRED_PROJECT gets deprecated later? Honestly I bet this project won't last two years..." ...or maybe they are just power-tripping lazy-asses. That also happens.
bastijn 5y ago
Author mentioned compliance. He likely is an untrained engineer in the eyes of the organization owning the codebase. Working in a medical company I recognize this. You can get write access after you followed all necessary trainings. Part of those are for regulatory reasons, part of those are added by the company to make sure new people don't make a holy mess of a (central) platform codebase. Most of time people coming from outside the platform group can't oversee the impact of their changes. They think of implementing the feature but don't know the history of the codebase, forget to add tests (or add at the wrong place in test pyramid, do not check execution times, etc), requirements, design reviews, FMEA, SW BOM updates in case 3rd party is used, fix quality tool reorted issues, link tests to the requirements, update design documents and portals, communicate breaking changes, if any, etc. That is assuming the extension is actually desired. If everybody would start adding their little extension to a central platform before too long your platform is gone and instead you end up with a mono-archive that has no clear owner, a variation for every business unit, and so many possible configurations it can no longer be maintained. Probably it is not that contributions aren't welcome but the author must be trained, given access and the team owning the code must be made available to support. After design discussions the author should implement end2end but likely is not allowed to modify requirements and access some of the other tools to make the updates. So owning team must be made available to do that work. The owning team is likely not paid to smoke cigars with their feet up so Q1 2022 is their proposal. I've seen worse.
obstacle1 5y ago
> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko It sounds like OP is moving a bunch of the startup's systems onto bigcorp's infrastructure. Usually you can't "just do" stuff like that in a public company since there are laws and regulations surrounding access control, change management, data security, etc. For example PCI, SOC2, SOX, GDPR, ... It's usually not the case that the bigcorp people just want to prevent the fast-moving Startup Superstar! from moving quickly. Bigcorp operates in an entirely different context from startup, and needs to protect itself from employees with incomplete information making reckless decisions. I agree that OP should find a job that's better suited to their preferred style of working.
izacus 5y ago
If the other team lets you do the work, who's going to review it, explain the codebase to you and, by FAR the most important thing: who's going to maintain it when it breaks? Are you commiting your team and your time to a response when a bug appears with your code or when it needs to be migrated? That's pretty much the same issue as FOSS maintainers have with random drive-by patches - someone needs to still maintain that stuff in the future and in 99% the original owner fscks off by that time leaving the original team to deal with their artsy hacky creation.

Sevii 5y ago

Away team work is standard at Amazon. Of course you still may have to go to office hours and sign up for busy teams.

kuraudo 5y ago
I was going to say the same thing here. It amazes me that the company I always assumed was massive, slow, and bloated actually moves at the speed of light compared to op's acquiring company.

tyre 5y ago

> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I believe the manager explains it right after that. They have compliance reasons that not just anyone can access this codebase. It's also possible that the manager has acquiesced to types of requests before and it was a mess — new engineer doesn't understand they system, requirements of its scale (note that this is a new engineer from a startup so the world that they are familiar with is not this one), and either 1) needs hand-holding 2) has code that doesn't meet their standards and requires extensive code review back-and-forth. There are many reasons why, "let me into your codebase" isn't a priority for the team you're talking to. Many legitimate, reasonable reasons. > It doesn't sound to me like they're taking advantage of your skills. Working as part of a large organization _is_ a skill. One that the OP doesn't seem to have. Which is understandable; they themselves said that they have always worked at startups. You can't walk into an entirely different context with challenges you're not familiar with, then expect to behave the same way and get the results you're used to.

ethbr0 5y ago
There is no compliance reason why OP couldn't have read access to look at the source. If there is a compliance issue with someone looking at source, then either (a) their source control is misconfigured, (b) their source control is being misused, or (c) they have no policy to guarantee appropriate use and detect improper use. Any organization that uses compliance as an excuse for opaqueness, creating silos, and guarding projects like treasure is toxic, especially if people there are so institutionalized that they think that's a valid reason, and OP should begin looking for another job ASAP. (Said having worked at both companies with global read visibility & access scoped to team only)
- staticassertion 5y ago
  > There is no compliance reason why OP couldn't have read access to look at the source. Companies can have whatever compliance terms they like, whether they map to ISO27001 controls or not. > Any organization that uses compliance as an excuse for opaqueness, creating silos, and guarding projects like treasure is toxic, especially if people there are so institutionalized that they think that's a valid reason, and OP should begin looking for another job ASAP. Or they believe it's a reasonable control. Let's imagine this is a company working on self driving cars. Your source code is probably something you want to protect very carefully.
- bostik 5y ago
  > * There is no compliance reason why OP couldn't have read access to look at the source.* At a guess, I would say you have never worked with DRM integration. Getting access even to the binary SDK's can take months, and if you ever need the special license to work with the thing on source code level, prepare for a delay of several quarters. Long time ago, Nokia was integrating Microsoft's DRM. I got to witness first hand the red tape needed to allow a new person to even see the source code the team worked with. And this was thanks to requirement MS imposes on their licensees. The other code I know of that was heavily siloed were Nokia's DSP codecs. Pretty sure there were other corners with similarly absurd external restrictions but at least I was never exposed to them.

pavel_lishin 5y ago

> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I know of at least two teams who would kindly ask me to refrain from doing this; me doing the work doesn't mean they don't have to do any. They still have to take the time to review my code, provide feedback, possibly explain to me their standards and conventions. Afterward, they have to maintain and own my changes - what if I introduce a bug? What if the feature is popular enough that they now have to add additional functionality onto it?

piyh 5y ago
Plus the ability to jump into another repo with zero assistance to implement a change is not common. Aside from the technical skills needed, other stuff like filling out change control forms or making sure the build passes CI isn't something you can do with repo access alone. To go down all those possible roads with anyone who asks can turn into a full time job when you multiply it in a large org. Then after supporting those requests and cleaning up after those people, you job becomes lumpy and irregular with tons of people owning your time. Getting out of a role like that either takes years or quitting.
Joeri 5y ago
Setting up teams for inner source work can be done and tends to earn itself back, but most teams aren’t set up for this. Typical solutions for the issues you mention: trusted committers to review and merge work without having that role burden the whole team, contribution guidelines to set standards, 30 day warranty to avoid getting code dumped in their lap that’s broken but also avoid having too many owners of parts of the codebase. Anyway, I would recommend going to the inner source commons website and reading a few of the success stories like paypal’s.
- sokoloff 5y ago
  Interesting and I’d love to hear more about this “30-day warranty” concept. How’s that work in practice and how do you use it to avoid having too many owners? (Does it revert to the original system owners after 30 days?)

yongjik 5y ago

> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. Probably because $BIG_CORP was also a nimble startup ages ago, and people had written important APIs as fast as possible because they had to, and they were successful, and the company grew, and three years later the core team realized they're supporting three different sets of APIs which all overlap but do things slightly differently, and because 70% of the company revenue depended on it, it took five more years and the souls of a few dozen developers to finally get it cleaned up. Understandably they don't want to open their codebase to someone thinking "It's just one feature that takes a few days to add! What's the issue?" - they're probably thinking "Will this make sense five years from now? What if $ACRUIRED_PROJECT gets deprecated later? Honestly I bet this project won't last two years..." ...or maybe they are just power-tripping lazy-asses. That also happens.

bastijn 5y ago

Author mentioned compliance. He likely is an untrained engineer in the eyes of the organization owning the codebase. Working in a medical company I recognize this. You can get write access after you followed all necessary trainings. Part of those are for regulatory reasons, part of those are added by the company to make sure new people don't make a holy mess of a (central) platform codebase. Most of time people coming from outside the platform group can't oversee the impact of their changes. They think of implementing the feature but don't know the history of the codebase, forget to add tests (or add at the wrong place in test pyramid, do not check execution times, etc), requirements, design reviews, FMEA, SW BOM updates in case 3rd party is used, fix quality tool reorted issues, link tests to the requirements, update design documents and portals, communicate breaking changes, if any, etc. That is assuming the extension is actually desired. If everybody would start adding their little extension to a central platform before too long your platform is gone and instead you end up with a mono-archive that has no clear owner, a variation for every business unit, and so many possible configurations it can no longer be maintained. Probably it is not that contributions aren't welcome but the author must be trained, given access and the team owning the code must be made available to support. After design discussions the author should implement end2end but likely is not allowed to modify requirements and access some of the other tools to make the updates. So owning team must be made available to do that work. The owning team is likely not paid to smoke cigars with their feet up so Q1 2022 is their proposal. I've seen worse.

obstacle1 5y ago

> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko It sounds like OP is moving a bunch of the startup's systems onto bigcorp's infrastructure. Usually you can't "just do" stuff like that in a public company since there are laws and regulations surrounding access control, change management, data security, etc. For example PCI, SOC2, SOX, GDPR, ... It's usually not the case that the bigcorp people just want to prevent the fast-moving Startup Superstar! from moving quickly. Bigcorp operates in an entirely different context from startup, and needs to protect itself from employees with incomplete information making reckless decisions. I agree that OP should find a job that's better suited to their preferred style of working.

izacus 5y ago

If the other team lets you do the work, who's going to review it, explain the codebase to you and, by FAR the most important thing: who's going to maintain it when it breaks? Are you commiting your team and your time to a response when a bug appears with your code or when it needs to be migrated? That's pretty much the same issue as FOSS maintainers have with random drive-by patches - someone needs to still maintain that stuff in the future and in 99% the original owner fscks off by that time leaving the original team to deal with their artsy hacky creation.