Skill matters and the most important skill is raw problem solving. Designing and typing in the code with tests and all is the easiest part of software development. The hard part are the insidious bugs and malfunctions. These take a HUGE amount of skill to solve effectively. If someone only writes code for a few hours a week they are not solving the hard technical problems. Why does the server deadlock? Why does the application sometimes crash after a click? Each one of these usually is a five hour problem. In a 40 hour week an average developer can solve eight of these if they do absolutely nothing else. The skill that is developed solving these issues cuts the problem solving down to maybe an hour and adds time that can be applied to coding, design, meetings, and everything else. Unskilled people are going to be stuck on the problem for weeks.

There was a recent kernel leap second bug that caused CPU usage to spike in certain applications. A part time coder is not going to have enough skill to even deduce that what they are seeing is this type of bug. They probably would not even know what the kernel is or what the code looks like. The usual reaction to showstopper challenges is to proclaim that there is just a really simple answer that should only take a few more minutes of effort to discover. In reality, for someone without the right skills, it is going to take weeks of full time effort to discover. Does a part time developer/manager go home on the weekend and read release notes and look at kernel code?

As far as raw coding, there are far too many tools and libraries in use to learn even within a full-time job. A modern large application will use several hundred packages (some use thousands). With only a few hours a week, a developer is only going to be able to learn what one or two of those packages do and their API. Looking up the API is not enough. If it can't be determined what the library does then it doesn't matter what the API says. The developer usually has to learn the internals and that takes lots of hours.

Contrary to what most people think, one cannot look up all the practices, idioms, and patterns used in programming. It's like saying a painter can just look up a technique in a book mid-painting. Can a surgeon sit in a surgery with an anatomy book open or a guide on cauterization? A developer has to have a very wide repertoire, not just for one language, but for 3-5 languages that are going to be used in a modern application. If you look up every bit of the thousands of pieces of information, nothing would ever get finished.

People who manage and code a few hours are usually being disingenuous, and I have worked with a couple. They do something very, very simple with one single component and use that as evidence that it's not really that difficult. For instance, make an form and then proclaim that web applications are easy because a form took 30 minutes to set up. The form, however, is microscopic in terms of the total effort needed to run an application or set of applications. They blow off entire requirements areas such as security or performance. Does the form have any security or performance requirements? Who cares, right? They're just part time developers, someone else will finish it. Part time devs are not even going to understand why performance or security are important. Most people that would be in the part time camp have less than two years of experience as a developer and are still in that formative early phase where the only requirement is 'does it work'.

Of course part time devs get to choose where to give up along the way. If the form is too hard maybe they add a few links or something and call it development. A full time developer does not have the luxury of picking and choosing tasks that are easiest. Part time developers simply try to redefine the meaning of 'good developer' to the point that they can reach their own weak standard and gain some developer credit.