Ask HN: I'm 40 and feel my mental ability declining. Programming seems harder.

There’s not enough context of you here. Our ability to think clearly is predicated on a lot of stuff, almost all of it psychological and lifestyle but some health and genetics.

Are you depressed? are you burning out? Are you eating well? Are you exercising? Are you disengaged? Are you socially engaged? Are you anxious?

You need to step back from the tasks you’re finding difficult and look at yourself not as a programming machine but as a biological entity with a complex giant dna mutation brain that can easily get thrown off track due to any number of factors. Most likely unless you’re developing some sort of early onset brain disease you are depressed, anxious, burning out, or simply aren’t interested in what you’re doing. By 40 things get complex because the newness of “OMG IM AN ADULT” wears off and just simply working isn’t enough, especially in a task that requires “flow” of intentful mindful engagement.

I suspect you need to step back for a bit and look inside yourself very critically and examine what’s going on. To me it sounds like probably a mixture of all of the above, leading to a growing burnout. My suggestion that worked for my burnout is take up a rigorous practice of vipassana meditation, regular exercise, managed diet, and rigorously constraining work focus to when it’s appropriate and otherwise entirely letting go of the pressure to perform. Then when working not engaging in second guessing your output - we have ups and downs, the important part is enjoying the process of programming. But YMMV, I would start with taking those questions above and asking the people closest to you them and take their answers seriously, see a doctor and explain your challenge, and see a psychologist and explain your challenge, and spend time seeing yourself for who you are not who you think you are.

Good luck!

> I can't seem to hold more than about 2 levels of call stack in my head...several layers deep...call stack in my head.

This describes me (early 40s but I was always like this) so I just write it down in a notebook. There's no advantage in trying to keep everything in head when we can use well tested tools.

As such, do know that porting API is tough in best of times. It's not easy to just walk into it and understand, let alone replicating the functionalities in other language. You are trying to pull off several things at once.

I'll also repo my earlier comment verbatim[1] where I offered my suggestion to someone in similar situation.

It's beneficial to approach learning about an API top-down and bottoms-up. The context in which the API operates and then the working of the API in itself. Imagine if you were in charge of maintaining a hardware tool. I first want to know how this tool is used by various customers before learning how the tool works.

1. Begin by learning all the end-to-end product flows this API is going to be invoked within. This is the context in which your API is operating in. It also sets the stage for non-functional requirements such as latency, and availability requirements. How will end customer and business be impacted if this API were to misbehave?

2. Next speak to all the customers of this API. How do they produce the data for your API's inputs and how do they consume your API's output. You will be surprised by all sorts of creative ways in which an API gets used, not necessarily what the API was intended to begin with. But you need to support all those clients so better get to know their use cases. Also, understand how they handle your API failures. The consumers tend to make unstated assumptions about input/output validations and invariants. It's not documented anywhere but floats around as tribal knowledge. Extract that knowledge and document it somewhere. Make sure you are very clear about every single input parameter, how it's produced and its expected values as well as every single output parameter and how it's consumed. Don't forget about exceptions. Often times customers treat exceptions as just one of the expected output parameters and so actually depend on the API throwing that exception.

3. Finally, take a look at the API's implementation. Don't get frustrated if you don't understand more than 50% of the code. It's perfectly fine. Make notes of the parts that make sense and also note down those questions. Ask around. Often some parts makes absolutely no sense to you. But it is there for a reason, someone as competent as you put it in the first place. Again, ask around both within your team and the API's clients. Pay attention to the API's downstream dependencies and how their failures are handled and bubbled up to your clients. Your API's SLA depends on your downstream APIs, learn about them and ensure that it matches the expectations.

4. You also have indirect consumers of your API who depend on the side effects produced by it. Make sure you learn about them. If this API causes a side effect (such as DB update, publish a message to Kafka) then learn how those side effects are consumed. Does someone depend on it? If yes, how? Though I've described these steps in sequence I find it useful to approach all of them in parallel and over multiple iterations. At first everything is blurry and after first pass you penetrate through about 10% of cloud cover. After 4th or 5th pass you will have a reasonable understanding (~85%) to make small bug fixes.

[1] https://news.ycombinator.com/item?id=25944265

I mean we have good evidence that athleticism at the competitive level has a drop off at a certain age, and even that is mostly only a factor at elite levels. There’s nothing stopping you from being a great basketball player in casual terms at any age.

But cognition constantly being under ageist assault has little to no basis when you consider so many knowledge driven professions employ people well past middle age (academia, doctor, lawyers, scientists, writers, artists). They also do their best work much later in life.

Does it though? I often find it's fun to find new and novel ways to create things that are both clear and efficient. Creative problem solving can be leveraged anytime.

Burnout happens when you're forced to work without motivation. For me (same age as you), two kids and a "life" often soak up most of the motivation. I look at challenging problems in a different way: time travel. When I get fully absorbed into a tech/coding challenge I find that the entire day will slip away. For me, this used to be fun and now it's frightening because I know that a challenge will eat days of my life. For what upside? We already live comfortably. So maybe there's a part of you that doesn't want to go too deep because it's feeling like a waste of precious time.

My recommendation? Focus on tooling. See if you can create a better test infrastructure, a better developer experience for the others. Do you see another way the code can be organized to make it easier to reason about? Is documentation/code-comments lacking? Perhaps your time can be leveraged to help the others. Maybe that perspective shift can unlock your super-powers.