What makes a bad programmer?

Rigidly following sound processes always turns good professional to the bad one. It just takes 2 years, so it is hard to notice.

Naivety of my fellows who believe that following best practices alone will yield good results is astonishing. Processes allow masses not to think and spend their lives unknowingly misguided.

I guess there is no doubt about the fact that programmers tend to fall victim to the Dunning-Kruger effect. <a href="https://essentialsclothing.co/sweatshirts/">sweatshirts</a>

gREAT WORK

In the context of startups, there are "bad" programmers on 2 opposite ends of the spectrum: those that lack the skills to build a basic app, and those that are extremely skilled but insist on over-engineering everything. Either way, nothing will get shipped on time or on budget.

A bad programmer is someone who does not take the time to understand the problem they are trying to solve, is not organized and lacks attention to detail, does not use best practices and fails to comment code, and does not stay up-to-date with new programming trends.

A bad developer can mean many things, starting from organising code, talking with clients, what methods he use to develop the coding.. to, understanding the tasks, delivery time, and so on.

There are many povs when you refer someone as being a 'bad developer'.

No mention of poor variable/function naming, not thinking about program & data structure? One of the problems I've had with contractors is exactly that: poor overall program structure and variable/function naming, coupled with no meaningful comments/documentation whatsoever to make up for the aforementioned poor structure & naming. In some cases you can add difficulty understanding the task at hand to the list of shortcomings (e.g., wanting my PayPal sandbox API key when interfacing with PayPal is NOT part of the job).

Skimming through the article, a good dose of humility would probably do wonders both in terms of relationships and the ability to learn and get better in your craft (the hardest lesson is the one you're too arrogant to learn). I know it's nice to feel important, but it's those who make others feel important that bring out the best in everybody (including themselves).

One of things id say is stubbornest. There is nothing wrong with being confident in your solution, but everything can be done in quite a few ways, and some just follow some things dogmatically. Causing just mess in the code

Yup, the Dunning-Kruger effect is certainly rife among programmers.

My issue, when hiring devs, and being a non-tech person is that you don't know whether they are incompetent or very smart and just pulling the wool over your eyes (to secure more work/money). This is always the issue when you hire someone for a job you don't know how to do yourself.