Perhaps "bad" is not adjective you should use. From your description I would say such a programmer is "slow" and hopefully getting "faster" as they learn and gain experience.
As @andreareina points out, rate of completing work and the quality of that work are unrelated factors. In my experience many fast programmers turn out low quality work when you consider the amount of re-work their work requires over a period of time.
You can't just say that a developer is producing X quality and Y speed. Everyone can go faster by sacrificing quality or improving quality by going slower. I've never seem one of those "slow but writes good code" people, if you code slowly you will have less experience delivering products and therefore most likely produce shoddier work in the end. I have seen "really fast but reduces their pace to produce quality" though.
I am one of those slow programmers that writes good code. My manager used to say that any dates I give him, he has to multiply by 2 or 3. However he knows that any code delivered has no bugs whatsoever. I just checked and I had 4 defects found against my code for the entire last year. I completed about 70 features of varying complexity.
Here is the kicker, I completed the most features out of anyone of my team. What happens to them is they finish a feature and within a few sprints they have at least a couple of defects they have to address from their own code. So their feature + defects ends up taking longer than my feature coding speed.
Having said that in 2020 I started to try to devise strategies to iterate faster, mainly because I felt I could optimize my thinking process since I knew that I had mental loops I would get stuck in trying to solve a problem.
As @andreareina points out, rate of completing work and the quality of that work are unrelated factors. In my experience many fast programmers turn out low quality work when you consider the amount of re-work their work requires over a period of time.