Not if you care about maintainability.

I was about to go into a rant about that moron that named its variables after Starwars characters and then left for a better paying gig, leaving his unmaintainable mess for others to care about, but it would be unfair for me to project my own traumas into you. Besides... it was 2007, so I better learn to let go.

Instead, I am going to say that getting your software working is one important goal, perhaps the most important goal because by doing that you get the money and the social capital that let you keep going and accomplish the other goals, but it is not the only goal.

Other goals, such as maintainability, are important too, and they come with their own sets of requirements and constrains, often conflicting with those of other goals. If you want to call yourself a professional, you must recognize those conflicts and make deliberate tradeoffs based on local conditions, and never gratuitously undermine any set of goals just for the sake of it.

Or you can make a whole career out of bluffing and waving the "get shit done" mantra. Never keeping the same job long enough for the consequences of your own poor decisions to come back and bite you in the ass.

It isn't hard (actually it's pretty easy) to get in the habit of replacing magic numbers with named constants immediately. Any time you hardcode a number just name it instead, and on the line immediately above it define the constant with a "TODO: refactor to the right place" comment. That way when you're done with the current creative focus, you can go back and put it right. This fixing is great for boring meetings, warmup/rezoning time, and so on. Alternately just keep a bookmark to the #defines in your editor and go drop it in the right place immediately.

Doing this makes life convenient because magic numbers often turn out to be real problems - did you typo the number somewhere? Did you forget to update the magic in one spot? These bugs waste more time in hunts than they cost in "do it right immediately".

Maybe...But caring about magic numbers can also keep your software working properly.

Refactoring out magic numbers (and magic strings!) is one of the easiest refactorings you can do.

Not putting in the effort to pull these out shows a complete disregard for code quality and maintenance.

Once the software's working, and has been for several years, and it has become unmaintainable because lax guidelines let this stuff through, this sort of thing becomes your real problem.

I once worked with a guy who thought like this. His work was a morass of hundreds-of-lines-long VB methods. And when it stopped working, it stopped working hard, and I had to pick up the pieces.

Good programming practices are not a distraction from getting it working. They're essential to keeping it working, even in the face of changing requirements and unanticipated circumstances.

Because doing so is one of the many measures you can take to ensure your software is (and stays) easily maintainable. Getting your SW working is only really one stage of a product life cycle.