Location: San Diego, CA
    Remote: Yes
    Willing to relocate: Possible within CA
    Résumé: https://msaspence.com
    Email: [email protected]
    Technologies: Node.js, Typescript, JavaScript, react, Python, Rails, Ruby, Postgres

Are you a small growing team looking for a hands-on leader who can comfortably operate tactically and strategically simultaneously?

I love to straddle IC and management roles. If you need someone who can lead your product software team and still churn out feature after feature with clean, maintainable code I'm your man.

What makes you think that AI is going to produce leaner codebases? They are trained on human codebases. They are going to end up emulating that human code. It's not hard to imagine some improvement here, but my gut is there just isn't enough good code out there to train a significant shift on this.

Good question and I have no strong answer today. But I think we'll find a way to tune models to achieve this very soon.

I see such a difference between what is built today and codebases from 10 years ago with indirections everywhere, unnecessary complexity,.. I interviewed for a company with a 13yo RoR codebase recently after a few mins looking at the code decided I didn't want to work there.

Or more simply, the one key question all leaders should judge themselves by.

> "move stuff around and complexity will magically go away" fallacy

This is a great description of microservices

I love the idea of "managing junior level programmers who don't know how to make loosely coupling architecture" as describing engineering leadership, regardless of how cynical it is.

I do question how microservices manage that, though? Tightly coupled microservices ie "the distributed monolith", are a still real danger for teams that don't have enough engineers that know "know how to make loosely coupling architecture"

Yes, we have a term for that: Technical debts!

The reality is like this: You have a critical system that ran for ages, and now what will you do to scale the features ? By allowing/teaching junior devs to understand how to contribute to the codebase ?

There's a simpler way to do that efficiently: Extract a subdomain into its own microservice and you control the interface. Then even that microservice has bad code quality (tech debt), your business is still running fine!

Problem solved.

Why the monolith should remain the default choice for new, small, and medium-sized engineering teams. Considering how we can leverage the monolith to realize the benefits that microservices claim for themselves.

> This translates in extremely high customer acquisition costs

So you've just traded in marketing cost for server costs...

Its easy to see how you can calculate segments, retention and trends using user sets, but how do you calculate funnels.

How do you decide what sets of users you pre aggregate?

It seems like without some limits in place you could end up with huge number of sets, especially if you are calculating these based on event properties.

That's a great observation. Somewhere along the spectrum of query flexibility you reach a point where pre-aggregation doesn't work anymore. We have a separate column-store based system in place for certain types of queries which we'll almost certainly blog about in the future!

How does that then affect your cost efficiency. What clever things are you doing with this to keep your costs so low?

I guess we'll find out in a future post.

What are you studying? Could it not be argued to be part of your studies if you are doing a computer science course of some description?