Ask HN: How do you deal with the powerlessness feeling of coding?

If you don't work with someone who seems like gandalf had he gotten into graph theory, consider switching jobs.

Working with talented people really pours gasoline on your career.

Also consider a mindset switch. The choice of the word powerless is interesting here. There are modes of thinking you can get into where you just want to get to "fixed" or "done". In my experience that mindset makes problems harder to solve.

I would encourage instead a kind of eccentric puzzler mindset. Instead of thinking in terms of the dread of explaining to your boss the problem still isn't done, think about it as another day at the puzzle factory.

The way you become gandalf by the way. Is by working really hard on the seemingly impossible puzzles. Always going deeper, reading books, asking experts, developing patience.

What takes weeks today will take seconds tomorrow and some of those lessons will cross apply to problems in future software that does not exist yet.

Problem 1: Your manager isn't giving you the space to diagnose and fix the issue. The solution to this is to explain to them the situation in as much detail as it takes why you need a certain amount of time. If they don't want to listen then it's time to start looking for different employment. It's a great time to be looking, seriously, the market is crazy hot right now.

Problem 2: You are using abstractions that hide details you need to understand when things go wrong. The solution here is to go read the code, write small examples that trigger replicate the problem. Use a debugger. Get really familiar with the code in the abstraction you are using. The answer is in there somewhere and more than likely you can figure it out if you trace through. It's a partial failure of our industry that many times these abstractions make it really difficult to figure out why they went wrong. But it's our reality and sometimes it takes weeks of reading the code and experiementing to identify why it's breaking. The good news is that once you've done that you are just a little bit more of an expert in that abstraction, and that is a very marketable skill.

If you run into an issue with the framework or library in use, see if you can work around the issue with the basics. Inform your manager about the issue, a potential resolution but that the side effect is technical debt in the project that should be revisited later to see if the issue is resolved with a version/patch. Yeah its a crappy decision, make the boss make the decision, note it in the code and file the find-a-fix ticket for later.

In general I really dislike frameworks that emit/transpile/compile into other base (Python/JS in your example) languages. Its like two pairs of handcuffs. A new feature/bug exists in the base and the base+1 (e.g. Django) takes time to include/resolve it and then base+2 (webpack/DRF could be in this category) takes even longer if they are even aware of it. Or it could be a bug in the base+1/base+2 framework/library itself.

Eliminating unnecessary dependencies and sticking to basics helps a lot. I'm not saying ditch Django and write your own framework, just try to limit the libraries used on top of the framework.

Reading 3rd-party code, figuring out how it works, and figuring out how to fix it is a critical skill. It takes time and practice to develop, but the more you do it, the easier it gets.

Perhaps the biggest step is simply believing that you can do this. Remember that all the software you use was created by humans. Yes, much of it is complicated, but not as complicated as you imagine it to be.