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

Systems grow over time. At the beginning, they are simple, which means that they are forgiving. If you make a mistake, it is easy to see and correct. As the software grows, it gets progressively more complex. Problems hide for a long time and when they present themselves it is often very difficult to see the actual problem.

What I'd like to do is challenge you to look at it a bit differently. Think about the number of lines of code in the OS, system libraries, language, libraries, frameworks, etc that actually go into your code. Even if you only write 2 lines of code, there are probably hundreds of thousands of lines that your 2 lines are sitting on top of. Why are your 2 lines easy to understand?

Obviously because there is a great separation between the complexity of the underlying systems and your code. What you need to be able to do is to provide that same separation in your own code.

As you mentioned that you don't work with others, I will recommend some other approaches. However, if they don't work, I recommend that you change to an office job where you can get the mentorship you require before you leave the field altogether. 15 years is a lot of learning to give up.

#1: Read good code. One of the biggest problems that programmers have is that they rely on their own code for examples of "good code". You are at a huge advantage because you recognise that you need to improve your code. What should you be reading? Read library code from whatever libraries you are using. As you are doing "web development", I would advise you to shy away from reading the source code of frameworks like Rails, but rather read the underlying class libraries for the languages you use. If you are not using languages that are open source, then it will make your life much more difficult, but try your best to find open source and free software on the internet to study.

#2. TDD. Every time. All the time. Not BDD (although BDD is an excellent practice in its own right). You want to do TDD. This will force you to think about your interfaces and to decompose. There are many books about TDD. Some of them are good and some of them are bad. Read Test Driven Development: By Example by Kent Beck. It is probably not the best book on TDD, but it will give you the basics without confusing you.

If you are working with legacy systems and don't know how to TDD with those legacy systems, read: Working Effectively With Legacy Code by Michael Feathers. It is a very, very difficult book. Learn it all.

You may hate TDD. Many people do, but using it will make you a better programmer. Personally, I don't think it's bad if you abandon it eventually, but master it before you do. This will simplify the process for you and break it down so that you can consider things in more manageable pieces. It will move you away from "Just Works" because it is god awfully slow (or at least it feels that way). Just pay attention to the effect it has on your code.

From where you seem to be now, to where you want to be, I estimate you've got 2-5 years of effort. Don't get discouraged if it doesn't come right away. This is a discipline where you can get orders of magnitude better over time. Try to be as patient as possible.

I hope this helps.

You just need a jolt. If it's feasible take vacation and build something fun in a brand new language that is really different from anything else you've ever used. Set goals like I'll work on this no longer than X hours a day where X is small. Don't set deadlines for completion. The goal here isn't a finished product it's to have fun tinkering with something that will break you out of your block. And pick a language with a welcoming but passionate community that can give your feedback on your code.

I do this all the time to keep myself fresh working on open source projects or playing with new things. It expands my toolbox and gives my brain a break from the constant legacy enterprise spaghetti-ware we so often work on.

And when it comes to your money earning work don't discount the Just Works outcome. When you are glueing together legacy systems sometimes there is no "beautiful and elegant" solution. Sometimes due to time and legacy constraints your only option is duct-tape and bailing wire. Having an outlet to write more elegant stuff in your spare time can be a valuable sanity saver.

Side Note: I wonder if there are any good places online to have virtual design reviews done? Somewhere where the high level goals and constraints are listed and people comment on the best way to achieve them? Language and platform agnostic preferrably although some suggestions will inevitably work better in some languages than others.

[1]: http://www.martinfowler.com/articles/enterprisePatterns.html

[2]: http://www.amazon.co.uk/Enterprise-Integration-Patterns/dp/8...

[edit: beefed up]

Any recommendations? The PHP community (where my commercial work is done) is not that. And far too fad driven.

> And when it comes to your money earning work don't discount the Just Works outcome.

You're not the first person to say that to me. I should start listening!

> Having an outlet to write more elegant stuff in your spare time can be a valuable sanity saver.

Agree - if I despise what I write every day, it wears me down. I haven't worked on anything fun (or open source) for years, focusing on making money.

Thanks mate!