In my current position, it is a very fast paced environment where the only thing that matters is speed of feature delivery, and architecture decisions and actual engineering or learning is really secondary. Learning on the job is often talked about, and collaboration is as well, but very often it seems like few of it is happening around me.
At any rate, I feel severely under qualified for my current role, and it is severely taxing on me emotionally. I had issues overcoming procrastination (perfectionist syndrome, fixed mindset, my worth is equal to my output, etc) and when I find that I am getting my head down to work, I am working 10 hours just to keep par for a good solid 5 hours of work. I have been in this career field for a little over 3 years now, and I feel as if I haven't learned much of anything in terms of being an actual better software engineer. I feel as the past 3 years have been a constant rat race of "just get it done" mode. I often look at others envious of code reviews, pair programming sessions, and actual engineering discussions where everyone provides feedback. I understand this may be more rare than I am thinking, but I know its out there, and I have been in that situation for a couple months under an amazing Iteration manager, and that 3 months I learned more about being a software developer than the rest of the time.
I would like to take a step down, and maybe slide back into an associate or "normal" developer position (whatever that is called at some companies), and spend time humbling myself and really building my work related experience, but I am not sure how to go about doing this. I welcome all opinions and answers, harsh and encouraging alike, as I am in need of both. I have the ability to learn things, see abstractions, and stay focused, I just haven't had a lot of practice actually doing that in my career, and I am looking to find a way to do that after already "faking it until you make it" for 3 years.
Different stages of a project's lifecycle require very different engineering tactics, and micro-optimizing for one has an opportunity cost for the others. It sounds like you've been working at a startup (presumably before product/market fit), where an ability to crank out features quickly is necessary. Working at a fast-grower that's already attained product/market fit requires a different skillset, largely centered around being able to scale quickly and make wise technology choices. Working at a big company requires still other skillsets, mostly around reading and understanding legacy code and learning how to write maintainable, easily-understood code.
Most of the discourse around "being a good engineer" actually comes from consultants, whose business model is to find companies with failing software projects (there are many of these), say "I can do this the right way", and get them to pay out handsomely for this privilege. Most of the blog articles you read hyping new development practices are sales pitches; their goal is to make you feel insecure about your development team's prowess, and so hire someone who clearly knows better or buy a product that will fix everything. It works on a lot of companies, which is why these consultants continue to get business, but unless your goal is to become one of these consultants, you should take them with the appropriately-sized grain of salt.
Personally, I gave up my first startup because I wanted to be a "good engineer" more than I wanted to build that company, and joined Google. (Usually, opportunities for "good engineering" are more common at big established companies like Google or Facebook.) And then after 5 years there, my desires changed, and I wanted to innovate more than to be a good engineer. The type of programs I write now, and the coding style I use, are dramatically different from what I did at Google, because my goals are different. It's worth clarifying what your goal is before you invest time in developing the skillset for it.