What I'm pointing out it that since Conway's law says they are always the same you can't just change the code you have to change the organization too or it will pull the code back to itself. Pointing out the need for a methodology that is in line with your software design tools of choice is perfectly aligned with Conway.

With this and your other post on sovereign methods I think you are getting to a more general point that may be helpful to you. Conway's Law (not game of life Conway) states that the design of a system recapitulates the communication structure of the organization that produces that design. Or to put it in the most polemical terms possible all software not produced by an organization designed by software engineers is going to be badly designed. Because the needs of human workers and the needs of well designed algorithms have no known relationship and you have to solve both problems simultaneously to get greatness lots of stuff that attacks the problem from one side only fails.

Better advice on how much you need to know about tech, everything or nothing. If your IT isn't critical outsource it or buy services, your business is something else do that instead. Also if IT isn't critical to your business be aware that at some point someone has or will solve the fundamental technical problem of your business and will out compete you so thoroughly that it will be like you aren't even there, hope this happens not in your lifetime. If your business revolves around tech the minimum amount you need to know is everything. Otherwise its not your business it belongs to your IT, they leave then you're boned, they're incompetent you're boned, they decide to go into business for themselves you're boned. Figure out which category you are in and then embrace it.

Write a programming language. Try to make it do the stuff you don;t finish in your projects.

Yes, programming is a process. Pick something interesting enough that you want to do it all the time and try not to be too ambitious so you can make visible progress. In that vein while the quick and dirty languages will give you all sorts of bad habits the advantages of actually getting something done can be critical on keeping you on the path. If you are truly into pure abstraction something like The Little Schemer is a way to go. On the other hand if you want to set up a web app Rails or PHP would be better. Pick the venue first and then ask for advice again.

for a more serious list:

• saved: deleting a prior copy and replacing it with the contents of volatile memory.
• constant: a critical value stored in a single place so it can be changed easily
• scope: a hunk of syntax over which a single semantic element has a consistent meaning
• type: a property of a semantic element that determines what sorts of syntactical constructions in which it may participate

• non-trivial: impossible but not provably impossible. If a problem is non-trivial its probably easier to abandon whatever you are doing and try something else
• I don't know: no one knows, this is the age of google if a prepped expert is at a loss it's because mankind hasn't advanced that far yet.
• quadratic: your system is a toy, unless you are printing money capacity costs of your current infrastructure will eat you alive
• no problem: either the code is already written, tested, and shipped or the programmer is lying
• tricky, complex, hmm...: impossible many things in programming are impossible, very few programmers will admit this thus many euphemisms
• impossible, useless, stupid: I am lazy and don't want to do that, except when accompanied by a mathematical proof
• business needs: the user of this phase has no rational arguments however that doesn't mean they are wrong

I've never really had problems with regex, but I think that's because I treat them as a simple tool. I've seen people get in trouble trying to create pretend grammars or embed application logic in regex and that can range from headache to mathematical impossibility. Thinking of them as the arithmetic of strings clarifies most situations. If you are the kind of person that takes a float and runs it through a couple of pages of algebra to make web pages then someone needs to take you in hand and show you a better way. Similarly with regex cutting down ambition usually cuts complexity very quickly.

Still code generators are cool tech and regex's computational simplicity could make a good stepping stone to more generally useful tools.

bogosort is a great place to start with stuff like this try this pseudocode alloc all unassigned disk fill it with binary garbage one bit at a time by randomly picking a bit location and then running an iterative checksum on the TB image where your iterator is 0 to free mem of the system choose a random number between 0 free mem size fill up the buffer by picking random offsets into you disk image. toss the disk image and write the mem pool to disk. compare your new disk image to hello world by asking a human if this is what they're looking for. if not recurse.

You can also take the human step out with intentionally super-slow comparisons.