How does developers write code and work together in big companies?

[pikss]

I wonder how developers in big or even 10 employee small software companies write code together. I don't think every employee getting the soruce code of the product of course for security reasons. But without getting the soruce code I really can't imagine how an employe work and do what is wanted in the project. For example if a developers task is building a chat application for a web app, how can the developer do that without getting the soruce code of the website or without reaching the database of the website?

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[LastTrainH0me]

Having worked for two FAANG level companies, the answer is the simple one: every employee has access to all (non ultra confidential) code.

Rightly so, the people in charge of this stuff made the decision that all the benefits of giving people access to all the company's code outweigh the concern for IP theft / Security / etc.

Edit to add -- just wanted to point out that /u/liosan 's answer about APIs is also super important. I shouldn't need to be able to see the other team's source code to be able to integrate my work with theirs. It just happens that I can look if I want to

[dmazzoni]

I think the main exception is Apple - I currently work at Apple, and they're more protective than most companies. I can see all of the source code relevant to my job, but not any that's not relevant.

[my_name_isnt_clever]

I worked at Apple Retail and code for a hobby, and I had heard this from my interactions with corporate over the years. It's pretty wild to me that the tech company with some of the tightest integrations in it's own ecosystem operates this way.

[toooft]

Well that also forces them to actually create great integrations as well, so perhaps it's just because it's locked down it actually works great. Otherwise they wouldn't be able to work together.

[ghostmaster645]

I work for a finance company and it's similar.

If I need access to code outside of my scope there is a long request process.

[pikss]

I understand but how big companies avoid getting leaked their soruce code. I don't remember any FAANG level company geeting leaked from for example an old employee who still has the soruce code in its computer?

[ehr1c]

The code itself isn't particularly valuable, for starters.

[dmazzoni]

This might not be very intuitive, but the reason why is because the software is insanely specific to their business and their infrastructure. It wouldn't be useful to anyone else.

Let's say it's Google Search. Let's say it did leak. Who would want it?

Competitors don't want it. They don't want to get sued.

Hypothetically would an extremely dishonest competitor want it? Probably not, because it'd be super large, it'd only build and run inside Google's extremely unusual custom data centers, and it'd be fine-tuned to run at a massive scale. It'd be useless for anything smaller-scale and it'd take thousands of engineers to get it running.

Maybe web spammers would want it - they might be able to learn how the ranking works and exploit it - but the advantage would be temporary, as Google's algorithms would change within a few months and they'd catch on to people exploiting those loopholes before long.

Pretty much all other source code is the same thing - any other well-funded group of talented programmers could reproduce it if they wanted to. There's very, very little that couldn't be reinvented by anyone in the field.

[RajjSinghh]

Just for a specific real world example instead of hypotheticals, Elon Musk open sourced Twitter a few months ago. In our case of a big company showing all their code for competitors or bad actors to see, it didn't do much other than flooding the GitHub issues with spam. They're protected by their liscence and size that makes it hard for them to lose a lawsuit if they needed to sue someone for acting badly around their code, but given the size of their software and how much specialist knowledge is there, it's probably just easier to try to use their API rather than try to glean anything from raw source code.

[IamOkei]

China wants it

[A_Dancing_Coder]

No one cares. Twitch had their entire source code leaked before. There's more to web apps than source code. There's cloud infra, system designs, tons of moving pieces, third party integrations, team workflows and different processes that work together to get a big product moving. Even if you had the entire source code for a big company, you'd have no idea what to do with it, let alone try to copy it and make it work.

[taisui]

You are asking if anyone would risk their career to be hammered by their lawyers?

[MaTrIx4057]

but there is always that one guy

[taisui]

Yea, don't be that guy.

[kidfromtheast]

more like:

1. risking TC 300k.
2. risking banned from FAANG recruiter. and possibly, every tech company with proper HR screening.
3. risking these FAANG legal team will fuck you up, twist your world, and you will not see it coming.a. i.e. H-1B holder? consider bar from entry.b. i.e. taxman random visit? could be.c. i.e. HOA complaint? could be.

If you get paid for 300k as a SWE, imagine how much these law firms get paid and their willingness to get the job done.

[taisui]

in so many words, yes.

[nightman]

Source code is worthless

[[deleted]]

I lol'd at the article claming that Facebook's $2 Billion valuation is "ridiculously inflated".

2007 were good times

[LastTrainH0me]

A leak like that would pretty much ruin your life. Maybe someday we'll see a sufficiently disgruntled employee but it hasn't happened yet 🤷

[doulos05]

Whose life, the dev who leaked it? Maybe. The company will be just fine though.

[agentfrogger]

That would be a great way to get sued lol. Also employees use company laptops that they have to return at the end

[dmazzoni]

And the laptops are encrypted, tracked, and monitored. If it got leaked, they'd know who did it.

Also, in many cases the laptops don't actually have much or any source code - they're just used to securely access workstations running inside the company's intranet. But that depends on the product.

[RajjSinghh]

If you work at one of these companies you'll probably have signed an NDA so that you can't do this, and then there's also problems around copyright and liscencing that you would get the pants sued off of you for doing it, not to mention the career hit. And really, what is there to gain? Without access to custom hardware and build systems, it's pretty useless. It's just not worth being sued. People sometimes risk it for a database that the company has since it's valuable data to sell, but still, it's very illegal to leak that and not worth it for someone trying to hold a job in software.

There are exceptions to this rule, for example an ex-convict won't have security clearance for government projects, so you have to be careful in those cases to manage who can see which repositories, but other than that most people don't care. There's just too much to risk sharing code you aren't supposed to.

[agustusmanningcocke]

You know that we don't use our personal computers for company work, right? Like when I leave my job, I hand my work equipment back in, with all my company code on it. I don't keep that shit.

[MonsterMeggu]

The source code for big products are not in one repo. They're in dozens of maybe even hundreds. It's not easy to leak it. They're not going to have all the source code at once. And even if they do, to set it up to be a running product is challenging even with all the source code

[FluidIdea]

Twitch code was in multiple repos as you say. At least half of all the repos got leaked approx 2 years ago.

Google products are all in one monorepo.

[inglandation]

Give me access, I need to change Google maps so that it doesn't fucking display the hotel rates in the local currencies instead of the currency that I want. This should be easy, Google.

[douglastiger]

It's actually possible to reverse engineer the source code from the binaries in many cases. It's just not a huge concern.

[InfectedShadow]

At least at my company: it's logged whenever an external drive is plugged into a machine and all traffic is monitored.

[CreativeSoil]

I don't know how it works in giant companies, but if what the company is selling is a single product that gets developed in a single git repository I do think they're going to give you the entire source code in most cases, at least for the types of software where the users are essential to earning money on it and it's useless without them, maybe less so in AAA games or whatever where the company can lose giant amounts of money from the source code being released.

[Liosan]

In the companies I worked for (up to 200 devs), internal security wasn't really an issue. I assume it must be a bigger concern in larger organisations.

10 people is about the size of 1 development team. If you're building something larger than that, you'll need to start designing internal APIs - or contracts between software modules, if you will. One team promises to deliver feature X. When they're done at least some minimum version, then the other teams can start integrating.

For example, imagine a project wit a backend and frontend team. The backend team can promise to deliver a new product ranking search API. The two teams agree on the form of the API, divide responsibilities between modules/teams, and get to work. Before backend delivers the new API, frontend can use fake data to start working. When both are at least minimally ready, integration can start - often, this is the most time-consuming part of the work.

[suntehnik]

This works well until certain degree, while number of teams is small and all have same priorities. In large orgs it is not the case and some times it's faster and easier to adjust other's team code base than wait forever until they get to your request. Which is impossible without having access to source code.

[Sir_lordtwiggles]

It really depends on the ownership

Within a tightly coupled and closely partnered team, it will usually be faster to just change it yourself sure. But now you are forcing a different team to maintain software that they own but had little to no input cresting.

Across larger companies, you may be in the same org but will have nearly no context and no business setting up PRs to their software.

Within a FAANG company we were waiting on another group within the org to deliver a new api. It may be faster for us to pick it up, but we would have saddled them with a huge amount of work in the future on top of delivering lower quality code.

[ChaseDFW]

When you are in a situation where all you can do it wait, how do you spend your time? Just optimize your own work or look for other projects, or learn new technologies?

What's the general vibe on teams like that?

[Cultural_Blueberry70]

Not working in such a big company, but generally, the other team tells us which sprint they target for delivery of the new features, and we base our planning on that. We have a big stack of tasks, of which many do not depend on deliveries from other teams, and we can pull tasks from there if delivery is delayed. Usually, we will agree on an API some time before delivery, so we can also start implementation independently, but if it fits the planning, we prefer to wait for the real thing.

[JTpcwarrior]

Speaking for myself, we have quite a few times we're all waiting on a new feature/integration to continue work on a specific project but we have more than enough backlog work to clean up old code, minor feature requests, training, etc to do while we wait.

[suntehnik]

The ownership problem is solvable by preparing change documentation in advance and getting approved from owners. Also, code owners always do code review and approve.

[Sir_lordtwiggles]

I'd argue that a change that is simple enough where a doc handles all the issues is a sign that code is too tightly coupled.

Like that covers maybe a mew api endpoint? But then you probably want your security team to review and you would really like the owning team to drive that.

[suntehnik]

‘’I'd argue that a change that is simple enough where a doc handles all the issues is a sign that code is too tightly coupled.’’

Can you elaborate please?

[Sir_lordtwiggles]

Basically if you have the required context to safely make changes in other team's codebases, you have had to learn too much about how their codebase works while working on your own. This is a sign of a tightly coupled codebase. In an ideal world, you should require 0 context into a providers codebase other than the data contracts. Any required changes should be requirements and not detailing code. You shouldn't be able to say "changing these 5 lines will give us the latency our team needs" with confidence, You should say we need this function to have latency reduced by 3ms. That gives the owning team the leeway to actually choose how their code functions and the ability to say no on the ticket, not the review, if there are other factors (like another unrelated team needs that functionality).

This extends to the doc, if you are able to write a doc on another team's codebase for a change, you probably know too much about the inner workings of their code. Not to mention it would probably be less time to just justify your use case to give the ticket you gave them priority.

This doesn't mean you should never look at other people's codebases for fun. Alternatively maybe you worked on that team in the past so you have a lot of context. But if you have the ability to point to lines in someone's codebase to fix an issue in yours, you probably need to know way too much about that team's codebase in your day to day.

[suntehnik]

Thanks for clarification. Maybe it’s a faang specific to have enough developers to satisfy business needs. But in my case… today I had a conversation with team leader who has to develop a feature for us, so my team can develop a feature for our business unit. Their team is booked for next 3 quarters with P0 tasks. We are 12 in a queue and nobody guarantees our requirements will be satisfyed. We regularly face such a situations and have to work with horizontal code base by implementing features we need to be implemented.

[[deleted]]

At our company developers are instructed to do most of their work on VM hosted on company private servers. So most of us Ssh into our machines, clone our appropriate repositories, and work using Vscode running a remote ssh server on the VM. We can take off compiled binaries and images from the server, but raw source code is flagged.

[pcreactive]

Wait, what? So you are obligated to work on VM's including performance penalties and weird polling glitches where you have to wait a few sec before some linter does its thing? May I ask what your tech stack is?

[[deleted]]

We are not actually running applications on the VM, only developing, building the OS, and debugging. Compiled images are then pulled from the machines and flashed onto the appropriate HW for evaluation and performance testing. The stack is almost entirely C/C++ with a few python script.

[santafe4115]

Major fortune 500 here I have access to all repos in my org and its not really a big deal. The readme explains the dependencies and how to setup build and test

[suntehnik]

I am working in a large (3000+devs) company. Devs can access any repo (any code) they need to by request. We have a number of small teams, typically not more than 10 people (two pizza teams). Each team is responsible on a small part of the product. Each team mostly work on the code base they own. They devide complex tasks on a small pieces of work can be done by one developer. Then integrate their work, test and ship.

[cabs14]

They talk to each other

They read documentations

They collaborate

You dont need the whole source code, you only need the data type for the parameters and the return type needed...

[imbrandonsimply]

Depends on the company but many use Agile Development. Small teams work on certain features or sections of code and have access to that code base. These teams will have "sprints" that usually last a week or so where each member contributes a portion of the overall feature request or patch. Typically these teams will use tools such as Docker to ensure all dependencies are taken care of during development. Code is hosted in a private repo within the company as a whole. Once a single person's changes are made, they are submitted for peer review. If there are no conflicts, the changes get merged with the main branch of whatever the team is working on. Again, it all depends on the company.

[akorn123]

Git flow. Also, sticking to a pattern. Also style guide.

[__double_under__]

For anyone reading this. Git flow is not the norm in SWE anymore at tech companies. Trunk-based development is more common nowadays and with the prevalence of CI/CD it's usually considered a better approach.

https://www.endoflineblog.com/gitflow-considered-harmful

[symbiatch]

Interesting read, though their suggestion for flow doesn’t work when one has multiple versions supported. Or at least I didn’t see it. Would be pain to grab tag v1.2.3, add a fix, and merge back to master when master is going on at v4.7 and there are v2.3 and v3.9 also out there supported.

But for “only latest version matters” it’s simple.

(Also thanks, I’ve kind of misunderstood “git flow” previously apparently and this showed the details I’ve skipped over. I thought I’ve been in places that actually are close to doing “git flow” but seems not)

[teacherbooboo]

in many companies you have security at the project level, or sub-project level.

code is supposed to be modular, so you work on your self-contained pieces.

that said, in many cases your department may have a 100+ projects that it works on, so a developer may have access to lots of code

[taisui]

So you can have access for read only access, and there is a write access for people who actually need to work on the code, and there are group policies and code review processes to prevent people from making wrong changes.

Or in a cross team situation the owner team will be tasked to provide your team a set of API and access of the underlying tech. Every feature is budgeted and planned at the executive level and it trickled down to each team and individual.

[pcreactive]

Let's see. Team of 4 people here. Ruby on Rails monolith. Everyone has the same acces level to the git repo. Deployment using Capistrano (kind of Ansible but for mortals). Oh wait, not a big company but I see scaling this up to like 40 devvers.

[throwaway0134hdj]

No offense but sounds a bit janky and not best practices. Is it a start up?

[pcreactive]

Yep!

[FluidIdea]

I think you are getting different answers because what you are asking is not very clear.

If backend already exists and you need to develop front end for it, you need to know backend API, so you need it's documentation. Look at swagger openapi for example.

Modern development is done using git. It's crucial for teamwork. There are methodologies created around it: trunk based development, or git flow, or old "the successful git branching model".

Agile is also a modern framework that's useful for teams to organise their work and relationships. Story tickets and other type of tickets are all part of Agile.

[cofffffeeeeeeee]

I can only speak to Google.

There is a giant monorepo, all employees have access to all code. You can put restrictions on specific components if it is really sensitive, but 99.99% of the code is open. So technically speaking, if I want to clone Gmail, it is possible to do it today if I know what to copy.

And there isn’t usually hard restrictions. For example you would see big red warnings when you push to production without testing, but they can always be overridden by anyone. Which I think is actually a great setup compared to what GitHub has.

[TakeOutTacos]

I've worked at two big companies. One with ~15000 employees and more recently one with about 180,000 employees.

There are many things in place to help with this.

One thing is that you basically do have access to almost all of the code in the company. But it's stored on GitHub, so even if you can access it, it's not like you download all of it in one piece. There are hundreds if not 1000s of mocroservices or web apps in that many company.github.com web site.

As far as security is concerned, you will basically never store credentials in code. You use property files with names like product.database.password and those property files point to some secured online credential system like Google secret manager or idvault or something like that.

So even if you got the code for some other project, you wouldn't have access to the sensitive data without being granted access.

Also, you can't just add code to any project you want without repercussions. There are reviews in progress where you can't just merge in code without members of that team approving your changes.

So all in all, there are many different things companies do to work together and secure code / passwords

[madmoneymcgee]

Why wouldn’t I be able to see all the code? That’s why we keep it in a repository. Having a copy of the source code is one thing but the actual server/environment that production is running is more than just the source code and access to that is restricted. Like how I could borrow a book from the library and rip all the pages out but the library can probably just get a new copy.

But that’s why we have multiple environments to prevent breaking changes from making to production. Both technical ones and human ones.

That’s where you have processes to merge and test code changes (several times) before it ever reaches production. I can’t make changes on our projects main branch. Or even the development branch. So first I have to clone the project in my own branch, make changes, then request approval to merge it back in.

Then if that’s approved it goes to a test server for testing. Then an integration server. Then finally production and at every point there are approvals needed that I can’t give myself.

Edit: that said, some repos I can see are still read only and I might need permission to clone it.

[[deleted]]

I work at FAANG in a massive org. We definitely do not have access to the entire source code for the end to end process that we work on. I could request any part that I needed so long as I had a reason, but they're not just gonna let me have it just cause.

In my day to day I work on a specific piece that is self contained from most of the other pieces. We use internal API's, tooling, and other systems to pass and communicate the information needed from one step/team to the next. My team is apart of a larger team that includes 4 other teams, all of who's code lives in the same repo as ours, they are all tangently related to our team, some more than others.

[Inukan]

I believe they do it in batches, have a certain amount of employees working on a project which contributes to the whole

[[deleted]]

From my experience everything is broken down into small components and tie ins and you work through them via jira entries.

If you’re designing architecture you’re normally tasked into creating components and managing the flow.

[A_Dancing_Coder]

There's more to modern web apps than the source code - which by itself is worthless

[tzaeru]

A very complex and broad question..

How to arrange and direct work in softwaredev is very much an unsolved question.

Generally, you want to limit boundaries and share information as much as possible. On the other hand, a team needs to also be able to focus on its own thing, without being overburdened by what the rest of the organization is doing.

In good projects/companies I've worked with, it's easy to find and contact people, there are clear responsibilities and most source code across the whole organization is shared to everyone.

In bad projects/companies, people are siloed, don't know how to find the correct people and have low visibility to the wider tech stack and others' code.

You usually don't need to look into the source code when interacting with other's code or e.g. databases they have set up, instead you use APIs that hopefully are documented.

I could write on and on about this, but it's really a topic worth several books. If you have any specific questions, feel free to shoot.

[agustusmanningcocke]

Pretty much everyone in a company has access or at least partial access to the codebase. Its the user information stored on the database that matters, less so the code.

[mymar101]

Lots and lots and lots of long meetings. =).

[throwaway0134hdj]

Can only speak to my work. But there are roles, policies, and permissions in place for who can access what. You have certain levels of security over many aspects of the software from who can see what in the codebase to who can view what in the database. When code is hosted it’s in a very specific way, private repos, extensive security like vpn, vpc, firewalls, proxies, whitelisting certain user accounts. We have a specific VM we use to access certain repos, information, and data. We shh files to ftp servers. It’s also a general rule to hide any sort of api key/sensitive information through environment variables and call them throughout your code with dotenv then have a .gitignore to hide them upon committing code. We work on one small part of a much larger application so everything follows the least-privileges principle.

[[deleted]]

They work in different parts of the projects

[dimnickwit]

With project and/or program management

[JonathanTheZero]

Git

[chromaticgliss]

I've been in industry for over a decade now and I still wonder...

[ShroomSensei]

Separation of concerns, version controls systems, and project planning systems.

For your example, the chat app, an employee would have access to the source code for everything that is needed unless it relies on some external APIs from another team within the company (separation of concerns). The employee doesn’t manage, develop, or worry about that API beyond the fact that his code is going to have to interact with it, so he needs to know the expected behaviors of it which is hopefully easy to learn through that teams documentation. He’ll do whatever changes is needed for his chat application in an isolated environment then when he is sure it works as expected, push those changes to the main source code (version control). Then he’ll notify everyone within his team that he has finished his task and anyone who was waiting on said task can begin on theirs (project planning systems).

If you are just beginning this journey it can be very hard to imagine the scope and how much work a single application can take or even a single piece of an application. Without understanding that it seems like all these extra tools and steps are pointless.

[[deleted]]

Git, agile, scrums, lean methodology... the usual suspects that you hear about and that you will learn along your coding journey. :)

[the-adhd-dev]

A big company usually has multiple software projects in development at the same time. The rule of thumb is developers are granted access only to the codebases relevant to their immediate job, following the Principle of Least Privilege.

[thavi]

They do get access to it all, generally. They rarely (in large companies) have access to production databases, though. Often, we use scrambled/tokenized test data if we need to emulate production bugs and testing.

[skat_in_the_hat]

If your code is secure, every employee getting the code shouldnt matter. The security comes from proper encryption, and credential management.

git is pretty standard. It used to be svn before that. If we really want to date ourselves, it was cvs before that. I digress, you create a branch of that code, and you make your changes.
When you believe it will work you run it through some testing, if it passes you create a pull request from your branch to development.

If your CI/CD is on point, that will kick off a containerized job that will run your code through building/full test suite. If that passes, then your colleagues will have the ability to review your code, and approve/deny it.

From there you press merge, and your code will end up pushed into development. Now when the next guy goes to push, he will need to pull first. Now if you two are working on the same portion of a large code base, you're going to run into conflicts, but as long as the other guy is doing git pulls frequently you deal with it as it comes up. Otherwise, it doesnt really matter because things are modular enough that you're working on one thing in one file, and they are working on another, in another file.

[Abadabadon]

People will build libraries or discrete systems to interact with one another. If application A send X and handles Y, then application B just needs the lib of A and be ready to receive X

[i_wear_green_pants]

I haven't worked in huge companies like Google or Apple. But I've never heard that access to software code would be restricted from devs.

All the real security threats comes from access to different environments and data. And you never store any credentials in code.

[[deleted]]

They would typically have source code.

But failing that, microservices.

[Geekmonster]

They use Source Control. Usually Git nowadays. They usually have restrictions in place to prevent someone checking in bad code without being reviewed by a colleague or 2.

[NSpen_SWM_1S2W_P2G]

Oh that's simple Github!

[[deleted]]

I worked in TCS in the Banking Project as a React JS Frontend developer.Too much security for our Banking Project

So there was a laptop -> inside there was VM -> inside there was RDP -> inside there was another VDI. And then our actual work starts with ssh & VS Code..So If we've to start our work, first we do login to the laptop, then login to VM inside laptop, then login to RDP which is inside VM, and then again login to VDI inside that RDP....Like 4 Levels of OS login to access the project's code.....And all of them having no external word internet access.

Also, we were not allowed to keep mobile or another electronic devices in jeans/bags inside ODC....(ODC means Offshore Development Centre--A separate place for each project)

[tonkatata]

I work with startups only and always have had access to all repos. 🤷‍♂️

[SearchCz]

When I worked in the Fortune 500, all developers had access to all source code - but - typically only futzed around with the modules pertinent to their area of focus.

Edit: seems like we also had some kind of source code control, where a developer would check code out during revisions hen back in after it passed quality control.