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

It sounds like you are struggling with two different things.

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.

> It's a great time to be looking, seriously, the market is crazy hot right now.

It still can take several months of dedicated search - full time - to pass through all the filters on the way.

Ask for help. Slack and discord channels are ok. StackOverflow is ok. A senior dev on your team is better.

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.

Go back to basics. Web applications and XHR have been around for ~20 years. Yes the latest framework or library in use today didn't exist but the basics are the same: GET, POST, PUT, DELETE are the calls to the server and you are using JS on the client.

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.

> and only a few people on earth know because webpack is so hard to understand

Absolutely not true.

This isn't a comment about webpack (nor is yours) but looking at this specific example, how to deal with feelings of powerlessness is gain power. In this case, take apart webpack. It's JavaScript, after all. Create a new project using webpack using your default tooling, create a project using webpack with no magic tooling, reproduce the problem with webpack in with your repo in various states/at various points until you really understand the issue. Understand what webpack is doing under the hood until you're not powerless.

Extrapolate and figure out how to debug Python/Django. Bang your head against the code until you get frustrated. Take a break, a breather, some space. Go back to it. Eventually something will give and you'll figure it out.

You're not alone. What you describing is the problem with abstractions. They are fine and dandy when they hide the details and let you produce a greater volume of results than if you had to develop from basic principles. Unfortunately, most abstractions are brittle and often poorly maintained. I have had many experiences comparable to yours.

I think you have two distinct problems. Your manager is obviously ignorant and possibly techno-illiterate (the most common variety of their species). To use an analogy, he is handing you a pair of Nike shoes and expecting you to outrun Usain Bolt - just like that. No training, no warm-up. Just Go!

As for the technical problems, when you are confronted with a problem that is beyond your abilities to fix, you tell your manager that they need to either give you time to debug the issue or they need to hire a specialist to fix it. Another analogy: if your car is not running and you don't have the skills to repair it, you take it to a competent mechanic. Nobody knows how to fix everything all the time. That is simply the price we pay for the ever increasing technological complexity. With cars people understand the issue. Seems like it is less obvious to the average person when it comes to software development.

> What am I suppose to do? Debug it ? I don't event know where to start from.

This is the problem. Know that it's mostly a psychological thing. Start by reading the code of the feature you're trying to use. Go through it with a debugger. Yes, the first time it will be hard and take a long time but you will get used to it.

To the manager just say "it's gonna take a little longer than estimated, there's a bug we didn't expect in the library". Eventually, you will deal with these issues so fast it won't even be worth mentioning.

This.

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.

Not only read the code but read the logging and the error messages thoroughly.

If your manager doesn't understand that everything being broken all the time is a natural part of development, then you might need to find a better place to work. If someone I managed said "I'm blocked because Webpack is broken." My reaction would be to laugh, tell them we've all been there, and ask them to spend an hour or two on it. If they can't fix it after that I'd start helping. They'd be free to keep trying, or work on something else if they wanted a break.

I will say this though, my reaction to things unexpectedly breaking on me is typically "Oh... interesting." Sure, it can be annoying when it happens at the wrong time, but I also get a little excited. If there isn't some part of a person that thrives on the break/fix process, then software development may not be a good emotional fit. This is a normal part of the job, so if you don't have terrible management and you still hate the process after seven years, maybe look at other options. If everyone was an intellectual masochist that enjoyed things breaking on them, the species would probably go extinct.

Well, as soon as you adopt a library it becomes your problem if something is happening.

I tend to simplify things as much as possible and using my own code. Doing PoC's to see if i can adopt a certain "thing".

So my solution for being "powerlessness" is owning the code i use and therefore I know what it does.

I use tools a lot, but also because of that, I'm able to fix issues fast and mostly the error is from my end.

For example, i had some slow query generation in EF a couple of years ago and this led to the EF team implementing a Like operator. - https://github.com/dotnet/ef6/issues/115

( I actually had to debug the library and give a reasonable explanation to the team. They found a solution, that they already considered. Which i think is pretty awesome of them! I use the like operator a lot by now)

But what do you do when you don't own the code ? It as never been me which had the decision to choose which things to use. It is the manager or the market. The market is looking for certain kind of developer and I need to know how to use those libraries otherwise they will not hire me.

Fixing other people's code is actually part of the job.

The more "s*t" you fix, the better you understand the toolset and the better developer you become by making better decisions.

The powerless feeling you have could be because a certain toolset is currently new to you.

Eg. I received a legacy project from a junior developer ( an important one), it took me 4 months to fix all ( and huge) issues. Now it takes me 5-10 minutes to identify an issue ( after improvements). It's a similar situation, but from a big internal project instead of a "small" library.

While your manager doesn't pay you to solve an issue from an external tool. He does pay you to solve the issue in the internal project. It's the same thing, but another perspective.

If you need to spend 2 days in that opensource project and you're sure that's the cause, so be it. A manager "only" cares about the end-result, not the road to it.

Not sure what you mean by "own" the code. It is all open source?

Managers tend to pick products that are most aggressively sold to them. Either by salespersons, or by public opinions.

As for the market for developers you either meet the market by developing skills in the libraries/frameworks that are in demand or you choose a different niche. You have 7 years experience so there must be certain areas that you are comfortable with.

Beware, of fad-driven development. The latest shiny new thing doesn't guarantee that it is applicable for every possible application.

I don't know how much years experience you have, but a lot of these issues you get a 'feel' for after decades working with software. The tech is not even that relevant for me; I have a feel usually what the person was attempting to do and roughly where it went wrong. It is extremely hard or impossible to convey this info many of the times they occur. I really do not like this stuff and it definitely gives me nostalgia rose colored glasses. Like when using Pascal, C, Forth, asm etc years ago where there was none of this setup and leaky abstraction stuff. The rose colored glasses are actually not that fake though; when I do embedded work or lower level stuff like high performance work, it is so enlightening that I have no clue why I ever do anything else. Web dev really sucks, but what can we do without.

Look into stoicism. Everything you are describing is core to the dichotomy of control:

“The chief task in life is simply this: to identify and separate matters so that I can say clearly to myself which are externals not under my control, and which have to do with the choices I actually control. Where then do I look for good and evil? Not to uncontrollable externals, but within myself to the choices that are my own..."

-Epictetus

There are things within your control such as creating issues on GitHub, questions on Stack Overflow, chatting in the project's chat/mailing list, opening up a PR, explaining to your leadership, etc.

There are things outside your control such as approving & merging a fix, getting attention on a GitHub issue / StackOverflow question, how your leadership reacts, etc.

I think the challenge you have right now is having clarity of the problem & solution.

A problem is a known unknown. It’s our assumption that needs clarity. A solution is a known known. It's the facts we gain from having clarity.

Being able to articulate a problem helps us gain clarity. Clarity relies on the fact that our assumption is correct. Most of the time, our assumptions are wrong.

Feeling powerless comes from not taking control. You have many things in your control you can be doing. Once you do that, it'll be a hell of a lot easier on your conscious.

The practical problem with the boiled down stoic approach is that in modern life almost nothing falls firmly and clearly into one of those two categories.

In OPs situation for example, webpack problems aren't under their control. But whether they use webpack, to some possibly very small extent, is. So now OP has the choice of whether to _consider_ it under their control, and push for a different tool that might make life easier. That may or may not be a good or satisfying use of time and energy, and OP is on their own for that, the stoic "control vs not" dichotomy has not been useful here.

This applies to like, basically everything that could cause someone mental anguish these days. Foreign wars, economic inequality, accessible biking infrastructure. These are all problems for me. All of them are outside my individual control, yet I still have a degree of influence to affect them.

Under this simple stoic approach, which bucket do I put them in? Assuming responsibility for every event I have any power to influence seems like a path to despair. But abdicating responsibility for things I feel powerless to change is also grim.

Maybe it has always been like this. And yes I am read up on the stoics and know that they have a lot more to offer for these calculations. I'm merely pointing out that giving people the simple "control/not control" technique is rarely very helpful.

The whole point of the two categories is to be able to break down problems into actionable behaviors.

You won't be able to solve world hunger by yourself. But you can help by donating a meal today.

You won't be able to solve obscure webpack problems by yourself. But you can report an issue with a reproduction to the maintainers today.

It's all about perspective. If it doesn't help you, that's okay. Maybe it will help someone else like it helped me throughout my career.

I'm genuinely glad you've found it helpful! I'm not trying to mess with that. I just, as a problem solving tool, have never found any use for it.

For me it falls into the same category as expressions like "it is what it is" or "we'll cross that bridge when we come to it." These sayings point at important truths that should be considered frequently. But they are worthless for solving any specific problem.

Fair enough. It is what it is.

> Feeling powerless comes from not taking control. You have many things in your control you can be doing. Once you do that, it'll be a hell of a lot easier on your conscious.

Thanks for this one. It really hit me up.

The hard part is when there is a quick and un maintainable way to implement something without leadership to demand doing it the right way. Some times the quick way is the best way. It just needs to be explicitly stated and decided. Too often there's discussion but no decision and no follow through.

Knowledge is power.

To be a great programmer, learn how to get really good at reading and understanding code.

To get good at reading and understanding code, you need to know where to look, and then you need to just start reading it. If something doesn't make sense, figure out why it doesn't make sense until it does make sense.

I know that sounds a bit like "to be good at programming, be good at programming", but there's really no way around it.

Consider your Django example, the "they" in your sentence is actually code:

> they just reload the page

Figure out where that code lives, and read it. Dive into its methods/functions, and follow the flow of inputs/outputs.

A common thing see with both junior and more experienced programmers is their acceptance of "magic". If the libraries they use just work, they don't dig into understanding why. Then when those libraries fail, they feel much the way you do.

But there's no magic. The code is written down or the framework is documented, and knowing how it works (or doesn't) is as simple as reading the code.

I've also learned, having done this for 25 years, that you'll read a lot more code then you'll write. I'd guess that I probably spend 75% of my time reading code. The rest is split between meetings, thinking, and writing code.

This isn't just a thing for programmers to consider either.

Reading code as a programmer is the same as a race car driver knowing about suspension. Or a chef knowing about heat and chemistry. Or a luthier knowing about what wood to use. Driving the car, cooking the food, or assembling the guitar are just a small part of the entire job.

Happens to me all the time, I also feel powerless in many situations. How do I handle? Well, I try as much as I can to fix the issue by spending countless of hours on it. At some point I reach to my team for help and now the responsibility is shared: if we can't manage to fix the issue we try with another approach.

Managers usually like to say "we are here to clean up your way from distractions so you can focus on the important stuff". Well, most often than not what I need help with is with stuff like OP described... ironically managers can't help with that (they help with stuff I usually do not need help with).

I have come across too many managers who fixate on a goal. Uusually set with too short a timeframe and insufficient budget (both money and resources). Then they constantly harangue the team to deliver on their expectations. Generally, such managers are trying to impress their higher ups with their management talent.

The only solution I know of is to look for a new job. At the same time push back on the demands. Helps to have no concern whether you get fired or end up quitting before the new job comes through.

Without seeing any of your code, what I've written below can be considered wild speculation.

I've experienced this kind of page-reload relating to buttons that are of type SUBMIT and no specific ACTION is specified in the FORM tag. Sometimes, the default SUBMIT behavior triggers earlier than an attached Onclick() handler. If there's no ACTION, it reloads the same page.

You might try adding the following attribute to the FORM element:

ACTION="javascript:void(0);"

This should prevent the form from SUBMITting to itself. The job to submit the form then relies on JavaScript code in an event handler to submit the request properly.

You also might try switching the type to BUTTON if you just want to attach an Onclick() handler to it.

hello,

a bit o.T. here, but i think, that 50+% of (web) development is communication (with people).

especially in "common" projects - mostly CRUD stuff - this is much more essential than any other technical experience/knowhow ever.

why? its easy to delve into technical details, its hard to explain them to people, especially, if those people are non-techies ;))

br, a..z

> For the last few months I've been learning back Django which was my first love. I'm learning back the django rest framework and today I have an issue where in the DRF interface the button for POST/DELETE/PUT/PATCH don't work. They don't even send the POST/DELETE/PUT/PATCH request, they just reload the page as if the only thing those button do where `window.location.reload();`.

It's hard to know for sure without actually seeing it, but...

This sounds very much like a fairly typical JavaScript problem. Or to be more precise, a "lack of JavaScript" problem. Let me first explain what I think may be the problem and then how you could look into solving it.

The problem as described makes me think:

- There is a button which submits a form. It should use an XHR for the submission, which means there should be some JS event handler attached to the button.

- But instead of that, if for whatever reason the handler was not attached correctly, then the button would simply submit the form it belongs to in a default way, which would reload the page. This fits the description you give.

So, first thing, how can someone go about verifying if this is indeed the case of what is happening?

What you do is you open your browser development tools and look around for a couple of things. First, you load the page normally, and do not yet click the button. Now, you look in the console for any JS errors at all and, if there are any, see if one of them maybe either a. related in any way to the button, the form, the event handlers, etc, or b. there is one that breaks JS execution, which would prevent other code from being run. More: You inspect the button itself with the DOM inspector and verify if it actually has any click event handlers attached. Note that it may be the case that the handler is attached as a submit handler on the form, instead of as a click handler on the button. If there is neither of those, then it's very likely that something has prevented some piece of JS from being run and the handlers from being attached.

After looking at that, still with your browser dev tools open, you set the network tab as visible, and then actually click the button and trace what happens. There's a lot to learn about browser dev tools, and there is a lot of info out there, so when you have a chance, that's something you could spend some time on. But right now you just want to check the request that happens when you click the button. In particular you need to look at the type of request and the "initiator". These will tell you whether it is indeed a "normal form submission" or an "XHR request".

Once you verify these things, if this is not the problem, then you'll need to explore other options -which I cannot specify more due to the lack of information, of course-.

But if this is indeed the problem, that there's no event handler attached and the form is simply submitted, then you need to investigate why there is no handler attached, obviously.

Again, try to search for any errors in the console, check id's used on the form or button, check the template that generates the button and form. Also check the network template for any 4xx, 5xx, or any files that are not loading for whatever reason. It may be a misconfigured path, a missing library, a misconfigured MIME type... It can be a lot of things.

If you can't find anything like this that gives you a clue, then it's time to change the approach. Now start by looking for the origin of that button in the source. Where is it created? How is it created? Does it depend on any parameters? Are those correct? Does it depend on a global configuration? Is that correctly set up?

I can't tell you anything more specific than this, but that is how you "go about solving the problem". At some point, you'll most likely find a misconfigured path, or a missing file or parameter. Or, at the very least, you'll find an error message that can give you a clue of what is happening and what should be your next step. With that it will be much easier to ask questions.

----

So, in summary, you fight the powerlessness by actually trying to figure it out. There is no secret, really. There's no magic thing people do to solve problems we haven't seen before.

Note, also, that I cheated a bit. That is, going from your description I offered an experience I have previously had. But what if it was my first time? What if I had never seen this? The idea, then, is to first establish what is actually happening. You suggest "...as if the only thing those button do where `window.location.reload();`". This is an hypothesis. So you verify it. You do the thing with the browser dev tools -which you learn to use beforehand, of course-, and try to verify if your hypothesis is correct.

There's a small catch, though. Your hypothesis there is a bit "too sophisticated". Why would someone attach some JS to do location.reload()? Could there be an easier explanation? That's where the above comes into place: if you attache no handler at all, the submission is just a normal form submission; if the form has no explicit action declared, it will POST/GET to the same current URL.

So, in a way, that is a small secret -but really, it's not secret- thing: always start verifying from the simplest things. Always check the most simple hypothesis. This can even be extensible to "always check the most visible/obvious things", like always checking the error console and always giving the network tab in the dev tools a look for 4xxs or 5xxs.

Also, as already mentioned: owning the code. But this does not necessarily mean making the calls. Sure, you did not make the decision to use DRF, ok. But you can still make the effort to learn DRF to a desirable extent.

Thanks for your help and explaining your philosophy of debugging.

I found the issue, it was ublock origin which was preventing the request. My model name is called "Ads" so ublock think it was really ads ans so preventing the request and make the browser reload.

After deactivating ublock origin the request is executed and I receive data on the server. It still crash but now I can debug it and make my code work.

Thanks for your help and as you said there is no secret. You just need to work it out until you find out. thanks !

That is such a monster of an issue, glad you were able to figure it out though

You should rename the div then rather than assuming clients wont use ublock

To be frank, you’re struggling with junior web dev problems. Learn to be an engineer.

I don't know why it's downvoted but it's the hard truth, I just need to be a better engineer and put the work in to improve myself.

The webpack issue he's talking about was something I encountered when using Webpack and ES6 Typescript for the first time. I had to dive into Webpack, Rollup, Babel, and Typescript configurations. It took a week but I finally nailed down the issue as a noob. My background was in EE, debugging wires for logic gates etc, but the principles hold the same-- our job is to problem-solve.