Hacker News Reader

> 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.

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)

> 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.

> * 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.

My closest experience was working with SDK of CCTV system. Which, after six months of waiting for legal, ended up being the ugliest and most obtuse codebase I've ever seen.

Thankfully, it was an optional side project at work, so I was able to step away and make more progress elsewhere.

But it also substantially reinforced my opinion that... if you need to keep a codebase secret... it's probably not a good thing.

And yes, I realize it is sadly endemic in the embedded world, for reasons both good (firmware secrets) and bad (artificial moats and controlling integration and compatibility).

The real reason is that the manager doesn't care at all, and it takes a lot less effort to say no than yes.

Or having worked on a platform team - you still need resources to at the very least review the change.

And it is on you and not these folks if something breaks in production.

> 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?

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.

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.

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?)

The full explanation is on the inner source patterns website: https://patterns.innersourcecommons.org/p/30-day-warranty

Heaven forbid someone introduce a popular feature into an internal tool. I do know the concern here, but it seems to miss the forest for the leaves on the trees.

At scale, if you let everyone do this, suddenly you're maintaining 50 features that were contributed and are each used by...two teams. Ownership with contributions requires really strong culture. (this is the same reason that you don't always see a PR just approved to an open source library.)

You mean just like when someone thought it was a cool feature to have JNDI lookups in Log4J ?

Are you going to assume ownership of that change if it breaks in production at any point and the team needs to provide support? Because I surely don't like owning pieces of critical code that wasn't implemented/explicitly maintained by my team, doing code archeology while putting out fires caused by 3rd parties' code is in the not-so-much-fun category of work.

> 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.

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.

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.

> 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.

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

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.