Having your PR rejected in a healthy environment means that your PR is radically far from the reviewer's expectation.
Having your PR rejected in a toxic environment can mean a lot of things, and a company sought after doesn't mean that it MUST be not toxic.
First, you have to make sure if both of YOU and YOU ENVIRONMENT is healthy. If both are healthy, proceed reading.
> The challenge here is to deliver good quality code, while maintaining a decent speed of delivery.
You made it sound like producing good quality code = slowness. FALSE. Seeming slow, good quality code boosts your team's velocity. BUT keep in mind: "quality" is "the standard of something as measured against other things of a similar kind; the degree of excellence of something". Your team has its standards, either is a derivative of other globally acknowledged standards such as https://blog.golang.org/go-fmt-your-code, https://github.com/microsoft/TypeScript/wiki/Coding-guidelin..., https://twitter.com/dan_abramov, etc, or self-made standards. You go follow them, make them happy!
Coding and design skill has a different definition than code quality. It is what punches up to the sky: the overall velocity, the success of the team, the balance of growth and culture retainment of the company, the development experience, the users' thumbs ups, amazements, and "this app is life changing" comments, the number of milestone celebration in All You Can Eat restaurants each years, the number of people rising up from junior to senior each years, etcetera etcetera.
Not only you make your team happy with the quality code based on their standards. You must always exercise to always improve your team, whether your team agrees or not AT THAT TIME. Keep searching for improvements, internally and externally. Occasionally fight with your team if you have to, if you have the right cause. And if it turned to be a wrong cause, accept and move on.
So...
> Are there any good ideas to improve one's coding/design skills significantly?
Yes. These are the tricks to a good code/software/system design and architecture:
1. Know the fundamentals! Go lower than frameworks and libraries! Analyze why existing codes are made that way! Think in strings, C, algorithm, data structure! Always pay attention top-down and bottom-up! Think in terms of time and space complexity! Separate complexity from complications! Be thorough.
2. Know the team! Know what is valuable for the team! Understand how your code impacts your team's velocity! Understand the mood of the team and use it! Contemplate how existing processes help or hinder the team! Consider suggesting to add or remove them if necessary! Make interfaces for others! Learn from the team! Cooperate with your team so that you guys can reach higher! Be critical to your team, conflicts can make you stronger! Be humble.
3. All that glitters is not gold. Some very popular libraries and tools that might not be as good as you think. Learn harder. Make something better if necessary. Think of both the big picture and the details at every step you make. Don't overweigh technicality over business requirement, and vice versa. Be critical.
> Now I'm a little worried that if my situation doesn't change, my career would suffer.
Be strong. Feel strong. But stay thorough, humble, and critical. And you need to care achieve them.
I've been there, laying afraid that my career might suffer. I've been in the reviewer's spot too, being too strict, forcing engineers to change the design, sometimes compromising the engineer's personal feeling.
BUT I've also successfully convinced and lead a rewrite the core of a pretty big project (which people are really afraid of the risk) so that the engineers feel safer when building on top of the core, and in turn make them tens times faster, while at the same time growing some newer engineers to the point of one of them being a lead of a team handling a pretty big project for a customer which is pretty prominent in the gaming industry, IN JUST HALF A YEAR. (sorry, but not sorry for bragging lol :D)
You never know what good things are coming to you when you start caring.
Some random nice stuff to learn that I remember might help you with the design stuff:
Having your PR rejected in a toxic environment can mean a lot of things, and a company sought after doesn't mean that it MUST be not toxic.
First, you have to make sure if both of YOU and YOU ENVIRONMENT is healthy. If both are healthy, proceed reading.
> The challenge here is to deliver good quality code, while maintaining a decent speed of delivery.
You made it sound like producing good quality code = slowness. FALSE. Seeming slow, good quality code boosts your team's velocity. BUT keep in mind: "quality" is "the standard of something as measured against other things of a similar kind; the degree of excellence of something". Your team has its standards, either is a derivative of other globally acknowledged standards such as https://blog.golang.org/go-fmt-your-code, https://github.com/microsoft/TypeScript/wiki/Coding-guidelin..., https://twitter.com/dan_abramov, etc, or self-made standards. You go follow them, make them happy!
Coding and design skill has a different definition than code quality. It is what punches up to the sky: the overall velocity, the success of the team, the balance of growth and culture retainment of the company, the development experience, the users' thumbs ups, amazements, and "this app is life changing" comments, the number of milestone celebration in All You Can Eat restaurants each years, the number of people rising up from junior to senior each years, etcetera etcetera.
Not only you make your team happy with the quality code based on their standards. You must always exercise to always improve your team, whether your team agrees or not AT THAT TIME. Keep searching for improvements, internally and externally. Occasionally fight with your team if you have to, if you have the right cause. And if it turned to be a wrong cause, accept and move on.
So...
> Are there any good ideas to improve one's coding/design skills significantly?
Yes. These are the tricks to a good code/software/system design and architecture:
1. Know the fundamentals! Go lower than frameworks and libraries! Analyze why existing codes are made that way! Think in strings, C, algorithm, data structure! Always pay attention top-down and bottom-up! Think in terms of time and space complexity! Separate complexity from complications! Be thorough.
2. Know the team! Know what is valuable for the team! Understand how your code impacts your team's velocity! Understand the mood of the team and use it! Contemplate how existing processes help or hinder the team! Consider suggesting to add or remove them if necessary! Make interfaces for others! Learn from the team! Cooperate with your team so that you guys can reach higher! Be critical to your team, conflicts can make you stronger! Be humble.
3. All that glitters is not gold. Some very popular libraries and tools that might not be as good as you think. Learn harder. Make something better if necessary. Think of both the big picture and the details at every step you make. Don't overweigh technicality over business requirement, and vice versa. Be critical.
> Now I'm a little worried that if my situation doesn't change, my career would suffer.
Be strong. Feel strong. But stay thorough, humble, and critical. And you need to care achieve them.
I've been there, laying afraid that my career might suffer. I've been in the reviewer's spot too, being too strict, forcing engineers to change the design, sometimes compromising the engineer's personal feeling.
BUT I've also successfully convinced and lead a rewrite the core of a pretty big project (which people are really afraid of the risk) so that the engineers feel safer when building on top of the core, and in turn make them tens times faster, while at the same time growing some newer engineers to the point of one of them being a lead of a team handling a pretty big project for a customer which is pretty prominent in the gaming industry, IN JUST HALF A YEAR. (sorry, but not sorry for bragging lol :D)
You never know what good things are coming to you when you start caring.
Some random nice stuff to learn that I remember might help you with the design stuff:
https://martinfowler.com/
https://medium.com/@thisdotmedia/the-cost-of-premature-abstr...
https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....
https://www.youtube.com/watch?v=yy8jQgmhbAU
https://blog.dropbox.com/topics/work-culture/kim-scott-inter...