msaspence

    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.

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"

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

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.

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?

"Shut up and take my money!"

PLEASE CHARGE MONEY for this, as great as the stuff you have up looks already I can't help think how much more time and energy you could devote to this if your were charging a small subscription service. I'm thinking similar to RailsCasts at $9/month

As a web developer who is trying to do more and more sysadmin stuff I can say that this kind of resource is just what I need. Syadmin seems to be trailing way behind development in terms of resources for people looking to get started.

The key word (that is admittedly missed from the title) is "blindly": 'blindly applying "agile shock therapy" or introducing Kanban will only suck you further into the abyss'.

Which is a bit of truism: do anything blindly and your chances of succeeding are based entirely on luck.

Depending on the specific circumstances Kanban, or any other agile methodology, may or may not be part of the solution to the so called "death spiral".

Your stack should be whatever will allow you to test your assumptions the quickest.

For a lot of cases this will be whatever you are most familiar with. There will be some cases where a piece of tech you haven't used before simply offers enough benefits to make it worth climbing the learning curve. However you want to use the best tool for the job, for startups the job isn't to build an amazing, scalable and maintainable code base, or even a great product. It's to find a "repeatable and scalable business model" before you run out of money.

This means speed is of the essence, choose what ever technology you can launch your MVP and test your assumptions with in the shortest possible time. At the same time balancing medium term scalability and maintainability concerns.

I'm confused by the necessity for this?

If you use the integration code demonstrated in their docs here: https://mixpanel.com/help/reference/javascript, Mixpanel already has an event queue natively.

It sets the `mixpanel` variable to an array which which holds the event queue. It then defines functions on this array with the same names as those in the full library. When any of them are called the call is added to the event queue array.

When the full library loads, the array of queued events is placed in a temporary variable. The full library is loaded into the `mixpanel` variable and then the the queue is replayed by the full library.

analytics.js also works in this way