domk

One of our interviews is a technical design question that asks the candidate to design a web-based system for public libraries. It explicitly tests for how simple they can keep it, starting at "a single small town library" scale and then changing the requirements to "every library in the country". The top ever performance was someone who answered that by estimating that even at max theoretical scale, all you need a medium sized server and Postgres.

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.

https://domk.website/blog.html

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.

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

  customer.is_entitled_to("feature")

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.

Don't.

Use a PaaS like Heroku, hook it up to your GitHub and a CI platform. Get your database hosted on Heroku or somewhere similar - plenty exists for anything you might need (Postgres, MySQL, Redis, Mongo...).

Don't do things that increase your operational overhead like using microservices or running unusual databases for which a good hosted solution doesn't exist. Stay away from anything k8s.

It will be a bit more expensive but well worth the extra money, compared to the time you'd spend on operations.

Yes, kind of like training, except it doesn't have a set agenda like a training session would, but is instead rooted in the circumstances of what's going on at that time. Any questions your report has? Anything they are struggling with? Any feedback you have for them? What are they working on longer term and how that's going?

I've never managed senior people, but for junior to mid engineers there is plenty to talk about most weeks. Occasionally there isn't, in which case it's just a 10 min checkin, but the weekly opportunity to raise anything is quite important.

1:1s that are status updates or things that could be resolved over email are definitely an anti-pattern.

In practise, doesn't increasing the coverage highly correlate with increasing the test suite size, therefore proving the effectiveness?

Conversely, I struggle to think how coverage could be increased significantly without increasing the test suite size in reality.

I don't think 1:1s have to be weekly as a hard rule, but it's a good starting point.

If bi-weekly works for you and your reports, do that. However I would argue that 1:1 is the one area you shouldn't try to minimise - as a manager, spending time coaching and developing your reports is a large part of your job. The time you spend on them should be highly valuable. If you or your reports think 1:1s are a waste of time, something is going wrong and you need to change how you do that.

A lot of this seems like things that could be cut. 1.5h every day on post-mortem meetings stands out as the obvious time sink – does the organisation really have that many production issues to debrief every day? Also a fair amount of ceremony, planning and pro-bono. Webinar for distributed ledgers in enterprise??

The things that truly matter – 1:1s, own team stand-ups... - only take about 8 hours per week.

Shared Slack channels.

We're an early stage e-commerce startup selling mainly to medium sizes companies, and one thing that's worked incredibly well is setting up a shared Slack channel with each customer's org. They can get hold of us quickly, we can both pull relevant people into any conversation, and it makes the relationship feel so much more collaborative because it's almost like you're a part of their team.

We've gotten a lot of positive feedback about this, and being available to fix any issues is a great way to get over some rough edges in the platform you are bound to have early on.

You should absolutely do it. Chances are the startup won't be successful, but it's a life experience you won't regret having.

Start building something on the side, and make sure you have enough savings to maintain your life without getting paid for a while. Once you have some traction, you should be able to raise money and hopefully pay yourself a reasonable salary.

If you do fail, you shouldn't have any problems getting re-hired. Sounds like you've been successful in your career so far, and the skills you learn as a founder will only make you more valuable.

At Purple Dot (waitlisting platform for e-commerce), we use Stripe.

Not sure which Stripe product you are using exactly, but with Stripe Connect it is possible to pay out people in quite a few countries now, not just the US. If you only have a UK registered business, you should be able to cover EU at least.

This essay feels really dishonest. It tries to simplify the vastly complex problem of income inequality, on which there is a sea of existing, detailed research, into a simple "it's easier to start companies now" argument. And it doesn't even explore that argument in that much depth.

What about bottom incomes? Why have those barely increased in real terms in the last 30 years, while the top 1% of incomes has been shooting steadily up? Surely that's nothing to do with people starting companies.

Being a good manager is a skill like any other, something you have to learn.

In the industry, being someone's line manager and looking after their wellbeing and professional development is often considered a job in itself, and people in that career track get selected, rewarded and promoted on the basis of being a good manager.

In academia, lab leaders are leaders because of their academic qualities, and whether they are good managers is completely secondary. They probably receive very little to no training and aren't evaluated on their management skills. Understandably, they focus on growing as researches, not as managers.

That is why so many supervisors in academia are very bad managers.

What about the argument that programming entire large systems (e.g. non-trivial applications as opposed to only algorithms) is way too complex to be described rigorously? At least with our current tools?

It's the price we pay for the amount we can do with software. It's very powerful but also orders of magnitude more complex than anything we can reason about formally.

I think there's a difference between "getting up and running quickly" and "presenting something as a silver bullet", which is the problem with some best practices.

You can (and should!) make getting started simple and easy, but there should be next steps that gradually explore the nuances and the background.

In Czech, unlike other Slavic languages, "robota" refers specifically to the forced labour done by serfs (not slaves).

legacy OSes like Linux and Windows

Since when did the most advanced and widely used OSes in the world become legacy?

legacy Ones ... more and more irrelevant as it matures

And what will Kubernetes run on, bare metal? Thin air?

I use org-mode in Emacs to keep daily notes, with the majority in one big file with an entry per day. The content is quite diverse - a mix of TODOs for the day (especially when I need to get through multiple smaller things that day), things to do or think about later, small notes to self about the code I'm working on, and sometimes quite extensive notes when thinking through the design/architecture of something new.

The last technique especially helps me a lot. When thinking through a hard problem, type out your thoughts in a semi-structured way, never deleting anything. Makes it easier to deal with problems that can be too large to hold in your head at once, to think about the aspects of something step by step, or to retrace your thought process and see why you made certain decisions earlier and maybe explore a different route when you get stuck. When finished, it can be used as a foundation for a design doc I share with the rest of the team.

Definitely interested