Ask HN: Strategies for Working on Large Projects

- Communications and coordination will be a huge part of your work. Get used to the reality that coding is going to take a backseat to meetings, emails, Jira, Slack and all that.

- Along the same lines, writing good documentation is going to be much more impactful than writing good code. It's not enough that you understand how stuff works - you need to make sure your team understands it as well. If your team doesn't have a good way to document stuff, that should be your first contribution to the team.

In my experience (25+ years), the first step is to realize what your main objective is if you had the big picture in your head. Then you can apply what you want to learn and work backward from there. Effective integration work might be best served by focusing on software contracts. Performance improvements might force you to think about which parts are better or worse than the required capabilities.

I sometimes take on bug fixes, UAT to force myself down paths which I would normally not encounter. This helps me dive in deeper to new areas as well as avoid those that aren’t my cup o’ tea.

I used to be able to keep a lot in my head, now I prefer only to keep the index in my head, but do the actual look updirectly in code. :-)

2. Use it and really think about it. As it works and you use it you will likely change goals because you will realize visions of possibilities you could not envision before.

3. Write things down and refactor the existing product. The code can get substantially faster and smaller. Formal documentation begins to shake out. The written documentation is the first step of an evolving plan. Custom types, interfaces, lint rules and such should also shake out as a part of the refactoring and documentation process.

4. Before expanding to the next idea introduce test automation. This is how you can expand at lightning speed in the future or refactor the entire future large app in 2 hours or less. If done right your test automation will be lightning fast and expose gaps in your architecture.

5. Employ ambition. Pick one idea at a time and build it. Add supporting tests to your test automation. Use it and think about. Before moving onto the next idea there will be an opportunity to refactor again. Refactoring eliminates duplication and allows superior scale into the future. It’s one of those do things that don’t scale rules that unintentionally results in exponential scale.

6. Measure things. You will never know just how right or wrong you are until you have numbers. Everything else is pretend and imagination. The test automation will help a lot with this.

>My issue is with ambiguity, vision, ownership, and having the big picture of the project in my head.

One could make the argument that the above are issues of leadership and the systems in place(or lack thereof), which could help navigate ambiguity, ownership and clarity of vision. If that is so, perhaps a system would create high quality onboarding plans for new people to grok that structure quickly enough to make a difference, or have adequate cross-squad synchronization and knowledge sharing, busting of siloes etc.

I don't think this one is about individuals but more about the system. Although, if the motivation and incentives are encouraging for you personally, you could try creating a system of record so that subsequent new folks can have similar questions answered as you did when you joined.

I’ve also asked to be notified of every code review for the project. It’s hit and miss, but you get some exposure to different parts of the project, what’s done where, and how they interact when your colleagues add functionality / fix bugs.

And use the project like a customer to get an idea of how it works and what you can do with it, what problem is solves, what works well and what doesn’t.