Ask HN: I have a mental block designing software. Time to quit?

I know the data inputs; I know the outputs. My prototype works. But my mind freezes when I try to rewrite the prototype into something maintainable that will run for 5+ years.

High level planning is fine, it's getting from what needs to happen to how to decompose into classes/methods/libraries, dependencies (logging everywhere) and organise message passing.

My current project is choreographing 3 enterprise systems to work together. Once past the lack of documentation it's conceptually simple; my code however is tangled.

Related, I have a mental block with drawing flow-charts. I can't isolate tasks, decisions, actions. The chart becomes spaghetti, or too detailed/too sparse to be useful. This is difficult when people want the system described on paper.

Either:

1) I need to learn something 2) It is an innate mental block, and I need to change fields

If I'm going to continue in software this needs to change, as I don't feel I'm delivering quality. The more senior I get the less I can stick with prototyping or "Just Works" as an outcome.

I think paying for code reviews and some mentoring is the only way I can get this feedback.

To take the current project, I have a CMS, Salesforce and ExactTarget. I'm writing the glue to automate taking new content from the CMS, finding SF users with the right permissions to see it, and emailing it to them via ExactTarget.

All good & working until... do I model it as 3 objects? Which object is responsible for creating the DataTable at ExactTarget (populated with SF data)? How is data going to be passed around cleanly between my representations of all 3 services? Or should I represent the system more abstractly as EmailToSend, EmailContent and use all three services within these classes?

Edit: This. One of the things I see a lot of people running into is this mis-conception of "prototype" -> "production". The prototype is your proof of concept, you take this application and you refactor it and optimize it as you move into your production life cycle. You take the bits out and put new bits in that are either un-optimized or don't work for the entire scope of that specific problem.

Working code is better than nice code that doesn't work. Refactor small bits as you progress.

I would heartily recommend learning a new language. You need to shake things up a bit.

Two reasons:

1. https://www.wikiwand.com/en/Linguistic_relativity - Our language shapes our thought. This is true for spoken and programming languages.

2. You cannot properly understand a language unless you learn another. This is partially based on point 1, but it needs to be said otherwise.

Since you're in web, I would recommend learning Elm for the front-end, and Haskell in the back-end. Why? They will force you to design your systems differently? Is it better or worse? That's subjective. The important thing is that it is different.

For data design, have a look at things like datalog. Datomic is a good playground for that.