I have worked at an org where team members were not allowed to create tickets because that was the scrum master's job and the product owner had to approve all tickets etc. Who can even think that is a good idea??

Not sure what the solution is. There might not be any.

Side note: Looking at their job listings I don't see any engineering positions (with the exception of a security engineer which is a grey area in a bank IMO), only managers and business roles.

Large parts of the theory focus on lock-free and wait-free data structures. Which, while interesting, are not necessary for beginners.

And reading this it seems a lot of people agree. Hope that can be fixed at some point. Tracing should be simple.

See for example this project: https://github.com/jmorrell/minimal-nodejs-otel-tracer

I think it is more a POC but it shows that all this complexity is not needed IMO.

I like the cloud but it is overused and misused a lot imo.

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.

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

Points: 3

# Comments: 0

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

Points: 389

# Comments: 461