What Max/MSP tips help you solve problems faster

These days, i bet the 'Max' Discord channel might give you more answers right away on this particular type of question since it can get general and run a large gamut of user-personality and style(here's an invite in case you need: https://discord.gg/hk3d9HtZ )

But i'll try and list two 'styles' of approach i use here:

1) For improvised max patching in general, i purposefully stay away from pre-made abstractions and i try to just go for it: i'll make everything from scratch and often start from a point of simply experimenting with a feature of a specific object, or i'll fall back on my synthesis knowledge to create various timbres and drum sounds, then simply choose a method i'm familiar with in sequencing(but these are often discovered by past experiments, too). This is also useful for learning new things about the Max environment, because i end up experimenting more with every little part of the patching(i find this most fun to do with Jitter patching because i'm not a video artist persay so this keeps that part of the environment more fun to research and experiment with).

2) For prepared instrument/patches that i want to reuse over and over, or for making anything that i might share with others, i'll try to keep it as organized as possible. I'll make abstractions to allow for easier editing and modular recombination of patches, and i'll be more strict about making sure i implement some form of 'pattr'-based preset/parameter-storage-and-changes system(basically making sure everything has a scripting name to register it with pattrstorage via autopattr). I'll also use 'patcherargs' object to setup abstractions with appropriate parameter-control by arguments(this makes it even faster to implement reusable patching). Last but not least, i'll include comments(often just to myself) to outline where everything is and explain to my future self or anyone else who might look through the patches what functionalities were intended by the various parts of the patch(this can even help with debugging even though it's not really a form of debugging by itself).

also, for this question:

Do you focus on specific objects, structuring your patches, debugging methods, or something else?

if there's something new i haven't played with, then i'll focus on specific objects, otherwise, as i become familiar with different techniques of sampling, sequencing, synthesis, and effect processing, i'll incorporate all these different elements into the patch, structuring the patch around these parts to create a cohesive whole that involves both sound-design and composition techniques.

i think in general, when everyone makes max patches, they eventually settle on structuring patches based on how they want something to sound as well as how they compose those sounds over time. These two basic parts of the creative process: content-creation and composition, naturally lead us all to learn various techniques and styles to create(not that they are mutually exclusive: creating sounds can often involve how they can be composed over time, but i'm just meaning to say that going for these basic aims of the creative process, naturally guide everyone to a particular style they have for structuring their work in Max and planning it over time). Also, although i mention 'sound', this same basic idea applies to 'video' as well: creating the content you'll use as well as structuring it over time involves learning many techniques to do both over time, and then it eventually becomes natural.

also, one last thing i'll note about 'debugging' since you asked: that's always been weird for me in Max, since Max is a visual environ, the 'feel' of debugging is different than in coding(even though we have 'watchpoints' i haven't really needed them as much in Max for whatever reason, whereas, when i've written code before in other environs, using 'breakpoints' seemed essential there)... therefore, i'll tend to just use whatever debugging technique can help me readily view the data in the easiest/quickest way at first, until i need something more complex(at which point i'll try to learn that more complex debugging technique).

i realize my methods don't sound the most professional, but i've never been one to get excited about 'products' made within the Max or M4L space. so i just tend to find that my joy at creating within Max is better fostered by keeping free and open. but that's not to say that when i get deeply involved, it won't get deeply organized, just to say that most of the time, i have the most fun in max, keeping it light and experimental until i want to pin it down to a reusable abstraction.

basically, if you're not desperate to make money off of a reusable and reliable product in Max, in my opinion, it's best to start out free and open to experimentation, not worrying too much about how understandable it is to others, nor how organized it is, and with time, some of the techniques of reusable organization become more natural, anyways(having said that, leaving 'comments' for yourself are always useful whether experimenting or creating something like a reliable product, because they always get you to understand what you did before, and this can help both learning and creation go much more smoothly over time).

a strange thing happens near the end of my work on a patch, i start to move things around simply to make it look nice(segmented and tidy patch chords, objects performing similar sets of functionality all placed within abstractions or confined to a specified space within the patch, etc.), at which point, it starts to organize and debug itself even further, as well. this is a nice point to end with, because at some point, you want to take some time to enjoy the curiosity or pride you have over the creation you've made, and tidying things up can help you scan over things to get a more well-rounded idea of how the patch might be better designed, organized, or even broken apart, reduced and then reused in completely different ways.