For me, as a rookie developer, I find I often have little to no clue what needs to be done until I've started coding and figured out through trial and error how to implement it and what the requirements even should have been up front.

Just because I feel more people should hear this early in their career, that’s perfectly normal. I fairly routinely answer questions about how long a piece of work is going to take by saying I’m going to need n days to work out what needs to be done, after which I’ll be able to give an estimate.

That sort of exploratory work is really good because you’ll end up reading relevant documentation, then actually trying to use whatever it is you’re learning about. Often I’ll throw together a hacky version of what we’re aiming for, but ignore anything but the happy path. No error handling, no UI beyond the bare minimum, just the very core of what’s being done.

And on that note the ”trick” to being more experienced is being able to anticipate what’s coming up next and already have a mental model for how to solve that.

Easier said than done though

Heh, I don't think that will ever really change. What changes in my experience is your knowledge and confidence when it comes to translating requirements into maintainable technology. The real world stuff seems to be always messy. My attitude is to try to locate areas of potential unknown risk, plan how to deal with the known risk and then hack away, knowing that no matter how much time spent, the plan will be flawed. During this whole process, communication is really important (i.e. 30% feedback, where I just write comments of what I would change in the codebase and then talk about it with a collegue)

* * *

Definitely, exploratory coding can be very useful. It’s essentially writing code to help identify the requirements or design instead of to help implement them. As long as management understands that you might be writing different code for each case and you can’t necessarily turn one into the other…

For me it’s the main step. Decision making up front would require literally 40+ people, none of whom claim they have authority but all of whom say they MUST be involved in planning.

Or, I could deploy something to QA and ask for feedback and forgiveness. Then a 3 week discussion becomes a 30 minute demo + a few small notes.

On this theme I can heartily recommend SovietWomble’s essay on the game the Forest (Soviet was a QA specialist in a former capacity)

https://www.youtube.com/watch?v=PUWg905fGTA

Both funny and insightful for anyone starting a project.