I had a team of about 8 junior people. We would do a daily morning sync where we went over open tickets. The main purpose of the meeting was to see who was struggling with something and needed help.
In my experience junior people often wait too long to ask questions when they are stuck on something out of fear of looking bad. But if you are junior it is totally normal to not know a lot of things and thus get stuck frequently. If it is something that can be Google’d, sure let them learn to look, but often it is something internal to the company and they just need someone to point them in the right direction.
I would take note on who was having problems and call them throughout the day to unblock the situation. Sometimes I would invite 1 other person into the call to share some knowledge and preferably have them explain it to each other.
In general I would try to make these calls educational rather than just telling them the solution. You want to build up the team so they become more and more independent.
When major new topics came up (new feature, completely new use-case) I would organise a team meeting to discuss the topic and work out a design. I usually prepared these meetings to the point I more or less knew the design we wanted to go for because the team was very junior. This allowed me to led the team brainstorm and occasionally guide them or point out issues.
The key is that you want to try to facilitate rather than dictate. If you dictate too much they won’t learn or learn slowly.
Second, junior people often say they understand something without actually understanding it. Have them explain it back to you. But don’t be too critical when they get it slightly wrong, that can be demotivated.
Also try to pull involve individual team members into higher level discussions from time to time. I would sometimes invite someone to the architecture review meeting. This helps them gain perspective.
Finally I would do a meeting twice a year to discuss their progress and ask their feedback and how they are feeling in the team etc.
This mostly applies to a team full of juniors. I bootstrapped two junior teams this way.
> We would do a daily morning sync where we went over open tickets. The main purpose of the meeting was to see who was struggling with something and needed help.
Oh no, don't call it a "daily scrum" or the anti-Agile folks will descend on you like a pack of locusts :)
But that really works, it's easier to get people to ask for help or say they're stuck in person than over chat.
> But that really works, it's easier to get people to ask for help or say they're stuck in person than over chat.
Which is completely different from saying "daily syncs make it easier for people to ask for help or say they're stuck".
What you actually need for people to ask for help or say they are stuck is to make them feel safe and comfortable doing it. As a human, not as an agile guru. If one can't get there, maybe one needs to work on their human skills instead of adding bullshit agile processes.
It was a data domiciling project so just went with sharding in good old postgres. Cockroach would have been perfect but it was going to cost something like $5k/m just to turn it on..
According to Wikipedia, Yugabyte (the company) has taken 290 million dollars of VC money. It's probably a safe assumption that they will follow the same path soon enough.
Data modelling (in databases but I guess that also translates to the application layer to some extent).
A good data model will allow you to get much further with a standard database without requiring horizontal scaling and complex caching solutions. Data models are often also painful and hard to change so good decisions made on the data level are worth their weight in gold if you ask me.
A little like building a good foundation for a house.
Sure, there are downsides.
1. The replay of WAL records becomes somewhat more CPU-expensive. But at the same time, OrioleDB can do that in parallel.
2. Replace becomes not the file-level equivalent of primary. Thus, you, for instance, can't continue file-level incremental backup started taken from the primary with the replica.
Nevertheless, I strongly believe that row-level WAL is a great win on average, and opens brilliant perspectives for further developments.
This was driven by Andres Freund for pg12. Please, check this.
https://anarazel.de/talks/2018-10-25-pgconfeu-pluggable-stor...
However, the current table AM API in many aspects assumes heap-like storage. This is why OrioleDB comes with a patchset we're intended to upstream to PostgreSQL.
I like the cloud but it is overused and misused a lot imo.