I need to write a front-end tech spec but have no front-end experience here. How can I do this without looking stupid?
I learned that my whole team is kind of new (Salesforce acquired this product), and they have just started contributing to the core platform. There are currently a lot of approvals necessary to merge front-end code into the system. This is rough as there's many epics connected to front-end work, and there is not a single senior person in the team which can take charge of looking into the high level architecture, following best practices, and doing better planning to release the code to prod.
I am the only full-stack Staff engineer here, and this is why my EM wants me to create a master front-end tech spec for the team. As an example of something this doc can cover: At Salesforce, there are multiple ways to communicate with the back-end API, each of which has their pros and cons but that information is scattered - We can consolidate that info into this doc.
Given that I haven't written any front-end code here at Salesforce, this task seems hard and I'm unsure how to do this without looking stupid.
Discussion
(1 comment)- 12 years agoTech Lead @ Robinhood, Meta, Course Hero
- Work with your manager to make the value prop of this doc a lot clearer. From what I'm guessing, the goal of this document is to act as a directly applicable, actionable resource to make it easier for front-end devs to ship their code. You can run this hypothesis by your EM, and if it is correct, drill down and figure out exactly what pillars they think are weak and could use more clarity around them.
- Don't get too hung up on the code. I've seen a lot of senior/staff engineers behave in the way illustrated by this project: They don't write that much code, and they spend a lot of time bringing other engineers together and aggregating their insights/work. As a Staff engineer, you have to act as a force multiplier, and efforts like these are a core way to do it.
- In terms of how to proceed, view it as a data gathering exercise. Find the relevant POCs for each section your document needs to talk about and talk to them. And if there's existing scattered documentation like for the front-end -> back-end API communication example you mentioned, you just have to aggregate it.
- Use this as an opportunity to build social capital. Once you launch this document, make sure to really thank the people who helped you along the way to create this shared, aggregated master resource. Make it clear to their managers how much they helped you, so they can get full credit.
Related resources:
