You're moving onto the new project!

Inheriting a project is always hard. You have to learn to think in the way that the predecessors worked and thought. Especially with code and especially when it is third or fourth hand, your predecessors have moved on to new companies and you didn’t work closely with those predecessors.

Structuring your code is similar to note taking. Very few people take notes the same and it is always hard to come back, process and completely understand exactly what you meant earlier.

As projects evolve without documentation because of rushed timeframes and chnaging requirements, it is so easy to lose track of how to make this code easy to handover. Particularly when a project feels like it is never going to end. In the world of startups and early stage companies, the preference is to get the prototype quickly built for the next round of funding. Hacks quickly get included, a few requirements get changed and pretty soon things have grown wild.

In a previous role, I was handed over such a project. Here are four problems I encountered and what I learned that about what not to do to handover to the next person.

Mix and Match front end frameworks I am not really sure why anyone would mix Svelte and React. But that is what I inherited. Maybe it made sense at the time, but as someone not entirely comfortable in either framework, the project became a murky hybrid of the two so that neither framework was completely recognisable. What happened? Svelte's reactivity binding's were broken by the implementation of React style custom hooks meaning that there was consistent application logic.
Mix and match CSS implementation I have no idea why start mixing CSS in JS and then also have custom CSS files to use on different elements. But trying to fix janky animations or identifying what root element triggered an inheritance problem was a absolute nightmare.
Have unclear deliverables When I joined the project we had a few pages to deliver with most of the functionality designed. However due to sickness, turnover and changing product requreiments, not a single person was aware of the exact functionality required such as mobile responsiveness, design fidelity, onboarding user flows etc.
Do extra maintainance the night before it is due and break everything When everything is ready to be delivered and what feels like hanging together by a thread, do not look to improve extra functionality. Especially when it is additional to the statement of work. Things break and those threads won't just get tangled in places, they get cut. At the very least do not make 20+ commits for a group of changes and not test each change individually the night before something is due.

What would I do differently?

Stick with a single framework either Svelte or React and stick to the documentation. Any senior dev will remind you that dumb code is the best code.
Stick with a single CSS implementation so again debugging and maintenance is much simpler.
Once I ran into issues with debugging the inconsistent logic, upward manage the senior developer to re-write the stores as per the single framework.
Upwardly manage other team members to ensure that if things get broken the night before, they can also be more easily fixed before merging into the main branch.

As painful as these projects can be, it was such a great reminder that communciation is critical on technical projects. And as obvious as the lessons seem, they were another reminder why keeping things simple is by far the best approach.

Thanks for following along!