Untitled topic

It sounds like a broad topic. You may want to screencast short sessions of yourself coding, and then run them back to see what's taking longer. Here are some more thoughts:

1) Research: Do you find that you don't understand documentation of libraries, or don't understand what makes one library better than another when you're looking through your options (popular / common libraries)? I don't think this is necessarily indicative of slow cognitive skills. I think it's indicative of perhaps not asking the right questions when you go through the libraries to pick one in the first place. As soon as you start trying to decide for yourself whether you prefer one library over another or start seeing strengths / weaknesses in the libraries you do / do not choose, this is a sign you are probably starting to "get it".

2) Implementing the library: Do you read the documentation first? Or do you go straight to examples? Bypassing documentation is not always a good thing. Take the time up front to get familiar with what you're working with so you have a good overview and understand in general how one would perform tasks with the library and how the author intended it to be used. If documentation is sparse, look at the code. Is it a highly popular library and you're still having trouble understanding? If so it's not necessarily indicative of slow cognitive skills. Just spend more time reading others' code. By flexing that muscle (like with other mental exercises) it should improve with time.

3) Specifications. Does the company / client provide specifications? Or are you on your own and need to research the requirements of the project from scratch in order to assess what the project needs. Depending on the specifics and what the company / client's expectations are you may want to consider if cutting corners is appropriate. For example is this a Minimum Viable Product? If so cutting corners is probably ok as long as it meets requirements of the project. That's not necessarily a tip for improving but a practical point in that it's never useful to write code for a project that will never be used, so having a clear idea of requirements for the project is critical in order to know what can or cannot be left out of the implementation.

4) How often do you think abstractly about the problems you're trying to solve? Generally speaking in order to truly harness the power of programming and improve your speed to get common tasks done quickly, you should find ways to write layers of code just beneath your specific implementation to facilitate the implementation of common components (for example, an authentication system).

It's also sometimes a good idea to practice writing the entire component (if not for work then in spare time) from scratch. This way you will have gone through all the agony yourself and understand the real pain points in implementing components for a system and will be better equipped to choose libraries that truly help you to accomplish what you're trying to accomplish. If you've done this a number of times and still wouldn't be able to identify pain points or have ideas for how to abstract common tasks into libraries / classes of their own, then you may just not be thinking critically enough about the problems you're trying to solve.

Maybe the problem is you don't receive enough value for doing things quickly. For example, if you were paid $1 million to do a programming assignment quickly, you probably would.

If you're worried about being "slow", don't introspect, use metrics. First, define "slow". Everything else follows, so this is important. "x" many key strokes per hour? "x" solutions per hour? Since this part is so important, compare your definition to other's definitions. Then measure. Both yourself, and others with the same definition. Don't measure against others that are using a different definition, you'll be measuring different things.

Then, break the problem down into it's constituent parts. One possible breakdown: domain specific software engineering knowledge, technical coding ability, raw mental processing speed, decision making strategies and execution, mental focus, engagement.

Then, go back, define each of those, then measure, then start to hack the ish out of them. Deliberate study and practice can make up for a substantial lack of innate ability.

Also, consider that your hearts just not in it or that this particular line of work doesn't play to your natural strengths.

Supposing you're decidedly committed, realize someone will always be better than you, and worse than you. Find a place in your team where you best contribute to the overall teams needs rather than measuring your performance using a single dimensional metric, and be ready to be flexible should that need to change in the future. Maybe your slow, but maybe the fast person is fast in 9 out of 10 things, and super-slow in 1 thing, which you happen to be medium at. Well, the team is better off if you take care of that 1 thing. Everyone wins.

Finally, your health. This should be priority one. "Keep your shop, and your shop will keep you." You, are your shop. Take care of your shop. Regular and sufficient sleep cycles. Regular exercise. Regular social interaction. Regular mental stimulation. Daily mindfulness meditation. Not because you love yourself and you deserve it, but because this is how you keep your shop, the shop that pays your bills. Regarding pills, adderall actually fits the bill. But, the problem with pills is they are one dimension solutions. Adderall also reduces your ability to think creatively. Prozac increases brain plasticity. Armodafinil is an understated but highly effective smart pill. Guanfacine strengthens executive functions via actions in the prefrontal cortex. Selegiline is another legitimate smart pill, that you need to be super careful administering. Protein and omega fatty acids are super important, on an everyday basis. Intermittent caloric restriction is intellectually beneficial. Basically, define, break it down, measure, repeat. Always take the whole picture into consideration and always play the long game.

OP, do you think you have problems following the logic within the code? Or is it like, i don't understand what the bigger picture is so I can't finish this task?

Does your team do estimates in advance for how long a task should take or is it cowboy coding just creating random features the customer might want? If you have estimates, do you overshoot them or what is it that quantifies you as being slow? I would recommend breaking tasks down and giving each task an estimate that you should try to follow, with clearer goals and clearer deadlines its much easier to keep on track, the unit for estimating should be nr of days, not hours or minutes.