It depends on the problem. If it's something algorithmic that fits into a given data structure, I go through a bunch of mental visual representations; graphs, t

It depends on the problem. If it's something algorithmic that fits into a given data structure, I go through a bunch of mental visual representations; graphs, trees, etc. If the model fits, I usually imagine the code in the language I used the structure the most in. If it's about something I don't know much, I'll go through pseudo-code and/or a list of tasks the code has to perform and then imagine it in the best-suited language for it. If it's more about organizing concerns or how should a larger problem be split up, I'll take a sheet of paper and draw components and tasks, then linking them with arrows until it makes sense and it's clean. I then try to fit that in the language best suited for it; usually for that kind of splitting, actor-based languages do the best job. It's probably why I like Erlang/OTP so much; they provided actual design patterns for higher-level representations such as Client-Server relationships, Finite State Machines, Event handlers (such as loggers and whatnot) that make it really easy to turn a visual representation into an actual application with minimal boilerplate code.