64BitChris

After many conversations with different development teams, along with my own experiences, I realized that a lot of the barriers to team growth is caused by working with people like this.

These people make other team members feel like impostors, like they aren't good enough, etc.

If you replace this person with a senior person who encourages learning, it can really help uplevel your entire team.

> Another issue I ran into is Parcel insisted on running "npm install",...

We use Parcel 2 with yarn 2 pnp builds - it never runs "npm install", nor does it ever create a node_modules directory.

On Saturdays, I wake and get to the office by 4am, just like a regular workday. The only difference is I'll leave around 9-10 am (vs 5-6 pm M-F) when the family is awake. Let's me catch up on things I missed during the week.

Sundays I'll try to keep my mind off work but still find myself thinking of things.

While I commend the author for taking the time to write this article and sharing their experience with the community, I can't help but think that this is a solution to a problem that was created by the very team that solved it. Or maybe another way to think about it is that this accelerator is attacking a symptom of a larger, more systemic problem.

The real problem I see is a system composed of over 3500 frequently changing modules, all with the concept of repeatability (ie release versions) removed. The issues with snapshots only aside, the core issue is the massive number of modules involved.

I mean what is the ratio of modules to engineers? I don't know the size of their engineering team but assuming it's around 100, that ends up with 35 modules per engineer!

Looking at it from another perspective, what's the ratio of modules to features in HubSpot and their internal tools. My guess is HubSpot has less than 3500 features...so now you have more modules than features?! That implies that functionality for a single feature spans multiple modules and isn't organized properly. Again, a fundamental architecture problem that should be solved rather than patching maven to work around it.

Even with a magic build tool to handle this at build time, the system is so complex just with modules alone that it's fundamentally unmanageable in any holistic way, which is probably why they stopped bothering with releases and went to a snapshot only approach.

My unsolicited suggestion to them would be to focus on reducing the complexity of the modules and their interdependencies along quantitative metrics like modules:engineers or modules:features ratios. It varies by org of course but in general, worst case should be no more than one module per engineer and definitely less than one or equal to one module per feature.

It's great that they've open sourced the tool but if they don't solve the underlying complexity problem of their system they're going to spend most of their time solving problems that they've created. This time would be better spent moving their product forward which would benefit all stakeholders at HubSpot.