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.

Comments URL: https://news.ycombinator.com/item?id=33804523

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=33772276

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=31643157

Points: 3

# Comments: 0

  customer.is_entitled_to("feature")

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.

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.

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.

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.

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

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.

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

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.