I wonder how many shit developers read that while nodding in agreement without understanding at all what the article is talking about.

Ive seen a dev shop where if these were laws every one of the developers would be given the chair.

1. Refactor, Refactor, Refactor

Sorry, I can't understand the author with all that Agile dick in their mouth

As per my experience, I'm telling you five major and basic programming elements:-

1. Input: getting data and commands into the computer
2. Output: getting your results out of the computer
3. Arithmetic: performing mathematical calculations on your data
4. Conditional: testing to see if a condition is true or false
5. Looping: cycling through a set of instructions until some condition is met

Thanks Michelle

Textbook examples but does not make you a good developer.

This is what makes a good developer:

• Never ever blame a bug in your code on something external. Learn from it and adapt your code so that fail never happens again. Giving excuses is the hallmark of a bad developer. 'but but, you did not install SP3.0.1.21.21 from you need to install SP3 SP3.0.1.21.22 instead.
• Any code you find on the Internet, take it and make it better. Fit it into your current design.
• Methodologies, design patterns sucks. Be aware that they exist, use them if you need but be very aware that they more probably will cause more problems that solve things.
• Design your code for failure upfront. It is more friendly for the tester and your code will naturally become controllable. You get better error messages, you get control of phone calls that prevents you to fix that bug.
• Realize that there is non single good solution. There are many ways and they will all suck. Most of the time you can solve the issue by pure brainpower instead of jumping to yet another library. It is not the first time that I see some person use a stupid big library just to read in a stupid simple html page to search and replace some element. A stupid text file read and write could have handled that job.
• Design the code in such a way so that testers can easily test it. If a tester can easily test it so can you. His bug report will easily pinpoint you to the exact location.
• Optimize upfront. The single method should not be optimized yet but the design of your application will do more than the fact is you use StrighBuilder or not.
• Mocking, Unit tests should be kept to a minimum. 90% of my code is fully production code. The mocking and unit tests introduces noise in your code causing more problems than what it is worth.
• AGILE, SCRUM unit tests are not your friend. It gives a false sense of security but in a lot of cases it is rotting your code base under that shiny green build status LED s.
• Survival of the fittest, the modern AGILE and SCRUM has crippled my productivity. However I have adapted my coding styles to make sure that I hit that user story mark every single time. Team work is nice but in the end your job is at the line if you keep on missing that user story.

And as last: For gods sake stop this stupid mantra that "SCRUM is supposed to fail". If you call yourself a developer you should kick that losers mentality out of the window and not allow failures in the first place.