Working with Shopify is an example of something where a good mental model of how it works under the hood is often required. This type of mistake, not realising that the tag is added by an app after an order is created and won't be available when sending the confirmation email, is an easy one to make, both for a human or an LLM just reading the docs. This is where AI that just reads the available docs is going to struggle, and won't replace actual experience with the platform.
Would Stripe's Connect work for you? They have all the tools for setting up a platform that onboards merchants, takes payments on their behalf and pays them out. You can sign up and use the sandbox for free, and only pay when you process transactions.
This is how our team does it as well. We are 5 engineers at a startup, so inbound support tickets that need to be turned around fairly urgently are common. Having one person dedicated to on call and dealing with support saves everyone else from constant context switching and leaves them to focus on planned work.
I think type checking helps with that both directly and indirectly.
It helps directly by making it much easier to know what type or shape everything is. Without types, all you have are variable names and tracing the code back up the stack yourself. Sometimes good naming conventions are enough. More often than not, a variable called `product` can be one of 3 different types and you have no idea why unless you go up the call stack to figure it out.
I find it also helps indirectly by making clever code harder to write. The dynamic nature of JavaScript encourages a degree of cleverness and meta-programming that makes things harder to understand. While you can do the same in TypeScript, making the complier happy makes it much harder to do so, which encourages more straightforward code.
Of course, you can write clever type definitions that are impossible to follow. Sometimes you do want to do some meta-programming without fighting the compiler. But in my experience, the path of least resistance when writing TypeScript is fairly straightforward OOP that tends to lead to clearer code.
> I find it also helps indirectly by making clever code harder to write. The dynamic nature of JavaScript encourages a degree of cleverness and meta-programming that makes things harder to understand. While you can do the same in TypeScript, making the complier happy makes it much harder to do so, which encourages more straightforward code.
Interesting.
Not having to define types makes JS feel very fluid to me when using it to jump into a problem and quickly test out ideas.
You can figure out solutions fast, and I suppose with that power comes irresponsibility for those who don't care to clear up the chaos they are able to leave behind in the fast iterations towards discovering the implementation they seek. In short - it takes discipline, and your argument it seems is that typescript enforces a certain degree of discipline... pros and cons to both.
It's not necessarily about the time it takes to type the type definitions.
static typing leads to developers trying to represent the "real" world in a bunch of categories and arbitrary boxes. Thats not necessarily a good thing because you can loose much time in bike shedding discussions like "Is a person class still a valid person class if it has no Surname" which do not provide actual value to your product.
Recommended watch: https://www.youtube.com/watch?v=YR5WdGrpoug
You say 30 mins isn't enough for deep dives. Can you change from 30 mins every week to 60 mins every two weeks to allow more time for in-depth discussions?
What makes Daspoll different from to the many other existing survey products? It's not clear from the website how it's better compared to e.g. Typeform.
Good advice. But instead of having an entitlements _system_ and API calls passing through multiple different services returning lists of features a customer is entitled to, you can follow basic OOP principles and write
Not everywhere is like that. Smart small companies will eschew this unnecessary complexity to get more done with less.
For example, we have deliberately stuck with a single Node.js/Next app in a single repo using Postgres running on Heroku. We are 5 engineers now and plan to keep it that way for the foreseeable future, even as the team grows.
There is some complexity we probably don't need – the JavaScript ecosystem is notorious for this – but what we use is all reasonably boring tech at this point, and it allows us to stay productive as a team, focusing on delivering value instead of just maintaining things or chasing trends.
I started my career in a startup and had a similar FOMO, always thinking that the big corps have figured out all these problems we were struggling with, hoping I can one day learn to how.
Then I joined one and had an eye opening experience - it's not true at all. They might have better tooling (although that's not even always the case), and they might have better established ways to do things, but the engineers aren't any better than at a startup and they deal with the same problems as you.
A lot of work at large corps is "patchworking", and a lot of code is pretty awful and won't teach you "the right way" to do anything. Like anywhere else, there's a lot of v1 code that doesn't get substantially improved after it's shipped because the team has moved on to something else. There can be a lot of churn where code gets moved between teams, rewritten and discarded as priorities change and people come and go. Only a minority of core systems get the benefit of being iterated on and evolved over a long period of time.
I believe that the best way to learn how to do things right is to make mistakes yourself and learn from them. Work on a single project long enough so that you don't just write the v1, but also the v2 and v3 and v4 that make you see the mistakes you previously made and let you figure out how to fix them.
Startups can be a good place to do that, because unlike in a bigger place, you might actually be given the scope and responsibility to do that even as a junior engineer.
You are right that maintaining things is a good way to learn, but you could equally spend 3 years moving on from one new micro service to another as the roadmap priorities change every 6 months, with very little opportunity to spend some time with your own code and learn from it.
If you've worked at 3 different places in 3 years, you might not have seen the benefits yet, but if you try to stay and work on something for long enough, you'll learn a ton.
