Thats ok, stand up meetings are gay, design patterns are for ******s, libraries are for pussies (except maybe STDLIB) and git was invented by one of the biggest wankers in the world. Cowboy coders of the world unite!

TIL there is just "OOP" and "spaghetti code"

Narrator: And they did unite. 3 years later they gave us Windows ME.

I actually agree with some of this to a degree.

Use standups where they make sense - not just because the scrum handbook says so.
Use patterns where they make sense - not just because they exist.
Using libraries ties you to those libraries (which can lead to support nightmares) - so use them when they add value not just because they give you that one thing you really like

But going the other way and never using any of those is a sure fire way to create a team that is coding for the garbage can.

Nowadays there's also aspect oriented programming.
Use what's best for the task. If you're just coding an internal tool that will do one thing (and which will not jeopardize the project if it is no longer maintained) then spaghetti code is perfectly fine for, say, 50 lines of code or less.

But as soon as you get what OOP brings you you'll never be going back - even in smallish projects you code for yourself at home. What you spend in thinking about in design you vastly more than make up in debugging/maintenance time.

OOP is really easy to screw up. I've noticed increasing backlash against it among my programming friends over the past few years.

It's interesting that the games industry has moved towards "data-oriented design" (eg: Entity-component pattern); partly for performance reasons but mainly to get away from deep/impenetrable inheritance hierarchies.

Here's a couple of bookmarks I've saved:

http://www.dataorienteddesign.com (just updated after 5+ years of of dormancy)
https://github.com/dbartolini/data-oriented-design

Juk

Not read it yet, but there is a hard copy version now too:

Data-oriented design: software engineering for limited resources and short schedules

Juk

We are all trying to get the most done with the least investment of time, energy, and money. If OOP works then we will use that. If something else works better then we will all switch to using that. This is not dogma.

OOP has its place, functional (spaghetti!...never write spaghetti code, call it functional, or stateless programming) has its place.

OOP really had a lovely match with the robust APIs (Application Programming Interfaces) or standard libraries needed to give access to service layers, such as those found in Graphical User Interfaces.

When doing hard core algorithms for calculating, OOP makes no sense...(hello "static"! for you programmers out there)

Use the tool that works, be able to leverage both. Anyone who says you absolutely should do this in all cases or that in all cases is WRONG.

Take Android for instance. It is in the Jave language (ok you can use Kotlin now) but it's the LIBRARY of Types and Objects that ABSTRACT (sorry, had to say it, but it is precisely correct) the screen elements, events and activities of your mobile app that make it android. Other non-android apps also are Jave of course, they just don't have the libraries specific to android.

If i've cleared at least 1 thing up, my work here is done.

Dont start with android. Do C#, ruby, or python.