Ask HN: Strategies for Working on Large Projects | Hacker News Reader

Ask HN: Strategies for Working on Large Projects

13 pointsbigtimesink6 comments

I'm used to working on smaller projects--ones where I can hold the entire project structure and framework in my head. It makes me incredibly effective since I know my way around the project, how any magic works, and the cleanest way to do things. I also find my work is better because I feel more invested in the project and have more control in its direction.

I recently joined a large team with a large project that involves some cross-functional work. What are some strategies people have for working in this sort of environment?

More context: I'm an experienced (10+ years) engineer who's worked at several big names you've heard of. It's not that I'm not comfortable wading through a megarepo to fix a bug or reaching out to other teams for help. My issue is with ambiguity, vision, ownership, and having the big picture of the project in my head.

View on HN

- Make an effort to get to know all the people who are involved in the project, especially the decision makers. Learn from my mistake - It's easier to do this when you're new to the project, than when you're in the middle of the project.

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

This is a great question, and useful to many others as well!

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

1. Start with a single idea that does a single thing and build it. If you don’t have a working product then none of this matters.

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.

I don't think the issue is one of big repo versus small repos. IMO, the crux of the issue lies in your last sentence:

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

Last time I was in the same boat, I tried to identify the major components of the project and then fixed small bugs and/or implemented a small feature in each of them. You get basic exposure to everything and you can explore from there.

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.

It can be overwhelming. What I tend to do is find a vertical that I can understand and master, and then expand out from there.

Reply on news.ycombinator.com