[jameshart]

I suspect a lot of your issues could be solved by talking to someone before you start coding to make sure your approach is valid.

When PRs are getting outright rejected it is because you are making incorrect assumptions or decisions in your code that don’t match with what the rest of the team knows or wants.

Before you make a decision, get another perspective.

One common pattern I see in not-quite-yet-senior devs is that they don’t necessarily recognize the moments when there is more than one option, and they are making a choice. This happens all the time in programming. You are constantly making decisions and committing to particular solutions. If you are not aware of the choices you are making - you are picking the first idea that comes to mind (or the first stackoverflow answer) - there’s a really good chance you are picking wrong.

Also try to develop your instinct for the assumptions you are bringing to the table. Did you assume this code was just one-off stuff for a simple offline process? Do others on the team expect it to be reused as a library later in an online service call path? That difference of perspective will lead to vastly different expectations for how that code should be written.

So: Take more time before you start coding to talk through the approach you were thinking of taking with someone. Then, as you start coding, watch out for moments when you can make a choice and again, get some input.

Doesn’t need to be a long design session. Just a five minute pull-aside to get a consult on an approach.

This is why pairing is so effective, by the way - you get constant access to a second perspective.

[MattyRad]

This is an excellent suggestion.

I think an important question to ask before getting review is can other people understand and manipulate my code as easily as I can? Engineers who submit PRs without critiquing their own work (usually the moment they complete the ticket/task) are a liability, and can introduce some uncomfortable situations when it falls on peers to approve/criticize. Speaking from experience, my boss was very terse in code review sometimes, but it was the kick in the pants I needed to understand that my buggy, brittle code was unacceptable.

If you're looking for good resources, Clean Code by Bob Martin is a classic.

[fooblitzky]

+1 Clean Code is a fantastic resource.

Uncle Bob also has a video series that provides a good introduction to a bunch of design issues in an understandable format (but it's not cheap at $14/video): https://cleancoders.com/ . I've seen these videos transform the way teams code.

My other suggestion is to start paying attention to how your code "feels". If something is painful/boring/fiddly it's often the case that the design isn't a good fit for what you're trying to do. TDD is excellent for this because it will move the pain front and center where you can't ignore it.

Clean code and other resources will give you tools to use when the design isn't a good fit (I could use this technique here etc...), but recognizing when you need to step back and change the design will be up to you.

[virgil_disgr4ce]

Along these lines, I wonder a lot about understandings of and appreciations for systematicity among developers. In my career I've seen a disturbing number of engineers who either don't or can't seem to think in terms of systems, and make decisions with short-term solutions that don't consider the chain of consequences in the rest of the project.

Being able to take 100 steps back from the question at hand is critical to making the best possible decisions. Ask yourself: what are we really trying to do here? What is really the problem being solved? This perspective is going to affect your work even if it seems like your current task is just a small cog. You might just be able to make your small cog improve the effectiveness of all the other cogs.

[chris11]

> I suspect a lot of your issues could be solved by talking to someone before you start coding to make sure your approach is valid.

I'm not sure what kind of incorrect assumptions you are getting. But one thing that could signal you should ask about your approach is working in another team's codebase. Some of your problem could be making a technically valid choice that doesn't align with the codebase. Working on unfamiliar code can cause this.

Personally I had a previous job where I got into a few longer discussion about my approach after submitting a couple PRs with another team's tech lead. I was able to be more productive by talking with that lead about my task before starting the coding.

[namibj]

I think I'm quite good at detecting when my experience isn't able to suggest a specific choice with statistical significance. I have a generally good overview on whatever I'm designing, but it's hard to find a place where I can make good use of these capabilities (limited, escalation-allowing solo design).

Are there any lesser-known types of positions that require these skills? Preferably backend/core systems, not embedded or fronted.