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.