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

I'm doing a rewrite of a small project and that seems ideal to give it a go. To me functional testing is much more appealing, testing a simulated user's experience through the website, yet TDD seems more popular - as easier?

> This scenario could be an early warning for burnout too, take care of yourself!

I've been in a burnout cycle for the last few years - a holiday in July was the first time I switched off in 15 years, then a health scare last week and a friend in palliative care have pushed me to reconsider. The lure of money isn't as strong as it once was.

That was the first programming book I ever bought! Sad to say it's sat unread on the shelf for 13 years...

Your lack of inherent motivation from the product domain means you don't get any satisfaction from just getting the requirements met, so you hunger for the satisfaction of making a beautiful architecture. But all architectures have flaws. As a competent engineer, you notice the flaws in whatever you design, so your only source of satisfaction is compromised.

I would try to find work on a problem that excites you. When you get that giddy rush just from seeing your program give a correct answer. I think most software developers have felt this way about some project during their learning process. Look back and try to remember where it happened for you.

You're in trouble if software craftsmanship is your only source of motivation. It's a great motivator, but it is not enough by itself to carry you through a big project.

Now that you're in this project, it may be impossible to quit. I would find a side project to work on that provides more satisfaction. That should make it easier to plug-n-chug away at your current project without becoming depressed at the inevitable small failures in elegance and design.

I've never understood how developers can be happy writing CRUD apps or wiring together a bunch of pieces made by someone else. You gotta search for meaning. Even if you take a pay cut, it's worth it to find work that you care about.

I don't think there's a silver bullet for you; you probably aren't incapable, but you may need to suffer through sub-optimal organization to hone this skill. What I will say is that, if you haven't worked on an existing project with highly complex organization (ideally one that has problems), doing so might help you. While I envision working directly on the project when I say this, there are cases where working with complex dependencies you need to get custom results out of can also be useful.

The point is that you want to be working with complex software (not simple interfaces) that requires a strong understanding of its internals to accomplish what you need. You'll know you're working on something on roughly the right magnitude of complexity when you regularly realize that your understanding of how the project or dependencies work is wrong, and your solution doesn't account for some hitch in how they work. The meta-point is that you're working with sub-optimal decisions other people made, and you either just have to deal with them and simmer to yourself about how _you_ would reorganize this mess if it was within scope, or you have to start refactoring their code (or building your own interface with it) that solves the problems with their design. The meta-meta point is that we're better at seeing problems in work other people have done than our own, but with effort we can train our eye on other people's work and (eventually) learn to focus it on our own.

At it's core, I think this is really about the cognitive overhead associated with working on and understanding a given implementation, so working on things that are cognitively overwhelming provides you an opportunity to learn about how to manage cognitive overhead. The result is hopefully that you learn to wrangle that complexity into an understanding that helps you do what you need without doing surgery, you build an interface that reduces the cognitive overhead enough that you can do what you need, or you refactor to accomplish the same.

Make 3 scripts

1. get-content

2. get-emails

3. send-content-to-emails

call this in a cronjob. Have logs.

The second day you will realize, you'll send the same content to the same people, so you'll need to add a filter. A simple file or database-based filter will be sufficient. You should be able to generate this filter from the logs.

Add this steps before sending emails:

* filter-emails

* filter-content

* generate-email-to-content-relation