x0hm

OOP separates coders from craftsmen.

Mermaid CEO is probably the coolest title I've ever heard

I think the internet has caused an uptick in people who make free speech seem like a bad idea tbh

thants

So this dude is just a fucking sellout.

When Elon Musk

How?? This is insane. Dark Souls is the most absurdly plain and boring looking game that ever somehow defined a genre.

tl;dr - the secret to learning is to learn

"Work" and "jobs" are two very different things.

We need action towards results.

We do not need 16 hour workdays.

Lost me here - "Tiago Forte (the original creator of the second brain concept)"

Ugh, no. No, no, no. Tiago isn't doing anything original. Tiago has never done anything original. This isn't Tiago's thing.

Language is fuzzy. Every word you say is a theory that carries with it everything you know about a word.

"Red" may bring to mind the color. It may bring to mind anger. It may bring to mind a bull and a matador.

All of those things happen in your subconscious, and they affect your understanding in uniquely-local ways.

So the transfer of information through speech from my mind to yours may sound very direct, but your interpretation of what I am saying is different than my interpretation of what I'm saying in very subtle ways.

Because of this, there's a very good chance that I am either completely wrong because I have misinterpreted things, that I am wrong because you have different context than I do, or that I have done a poor job of explaining things because context exists locally (in my head) that you don't have.

About this topic in particular, it was hyperbole to say "you are all doing it wrong". What is more accurate to say is that "my understanding of OOP is different in implementation than what I'm used to seeing, and I believe that my understanding is more correct/beneficial than those implementations"

Totally.

This also applies to really anything with the "-er" suffix, which lead us to treat objects as "data" and "things that act upon that data".

This often shows up in code as "Thing" and "ThingManager", or something similar.

You can achieve immutability with OOP. Other paradigms just emphasize it more.

I agree, though, that mutability is detrimental, and that traditional OOP can easily lead us to believe that state is not a concern.

I do not believe that this is a problem inherent to OOP, rather it's a problem of paradigmatic implementation.

Good questions!

One of the biggest issues with OOP I think is the lack of a unified understanding. I think there's value in trying to define a "right" way, if only so that when we are talking about OOP, we are talking about the same thing.

I think that definition would require a volume of text, so I'm not prepared to fully elaborate, but ultimately I think that the core issues lie in our approach. We tend to think like computers when programming, which leads to OOP being a morass of procedural code masquerading as objects. Effectively, we tend toward functional decomposition. Code is boxed up into related data and behavior, and we call these "objects". What we really should be doing is approaching object design as a function of behavioral affordances.

Object design then becomes a necessary, often overlooked, step.

Object design is the first hurdle. The second is in the actual implementation, wherein we traditionally treat our objects as "data" and "behavior upon that data". I can't tell you how many times I've cringed at seeing "Thing" and "ThingManager" in code.

OOP might not be a good thing. It definitely isn't a good thing when it is done poorly. Exposing an object's data, for instance, makes the entire paradigm worthless. The widespread acceptance of `public` data members completely ruins the usefulness of OOP.

That brings up implementation languages. Programming languages really want you to use them, and they make it easy to eschew good OOP principles in favor of ease of use. Accessibility features and syntactic sugar lead not only lead us away from the paradigm, but also confuse about what it actually is.

OOP's biggest strength, and one that most of the literature doesn't go into, is it's ability to lighten cognitive load. When an object works independently of its environment, it is easy to both learn and understand that object. But we sacrifice a huge chunk of this strength in the name of "getting the work done".

I believe that good OOP resembles FP in implementation. Not completely, but much more closely than the procedural landmines we're used to would have us believe. OOP just provides a lower barrier to entry in that it lends itself well to the usage of basic programming constructs and it more closely resembles how humans think, though that could also be argued.

Object oriented programming.

tl;dr - literally all of you are doing it wrong.

In "The World Beyond Your Head" by Matthew B. Crawford, the author introduces the idea of an "attentional commons".

The gist of this is that there are shared resources in the world. Air and water are examples. We recognize them as shared resources, and we recognize that without regulations, some people would use them in ways that make them unusable for others.

Crawford makes a pitch for treating "attention" as a resource, and asserts that folks should have a right not to be addressed by mechanized means.

It's a very good read, especially for software developers, phenomenologists, or cognitive science folks.

Additionally, doesn't advertising go directly against the notion of a "free market"? The idea that "capitalism breeds competition, and competition creates quality" goes out the window when huge advertising budgets urge you to buy some cheap commodity product over a well-made product with a smaller advertising budget.

Well, that's the problem.

CS classes teach you to "think like a computer", and computers "think" imperatively.

OOP is inherently a declarative paradigm.

CS classes don't prepare you to think this way. So we get fancy pants CS hotshots writing "objects" that are really just functionally decomposed into classes, and we call the instantiation of those classes an "object".

I would go so far as to say OOP is NOT science. It is philosophy.

This is pretty accurate.

I'd also throw in "Don't use static functions" and "Write declarative code".

Honestly, I think getting rid of public getters and setters goes a LONG way toward more reasonable objects.

Every once in a while I see this article, and every once in a while I fear that junior programmers are going to read it as if it is at all accurate.

This is a great article that represents the fundamental problem of OOP - that developers don't actually use it.

Instead, we have a lot of procedural programmers writing code that masquerades itself as "object oriented", when in reality it's imperative functional decomposition that we're calling OOP because we don't know any better.

I'd like to see a separation of Science and State, much like we have with religion except maybe actual separate.

Hmm, it seems like you made this repo to sell a book.

1) Build a database 2) Begin the slow, painful, arduous process of adding them to it.

The problem, as I see it, is that positive impact on a large enough scale that matters requires orchestration that we aren't equipped for as just software developers.

The beauty, though, is that we are more than just software developers. We are also humans with compassion and the capacity to plan and execute.

But planning and executing a software project is different than planning and executing a system whose output is "social good".

Our strength lies in our ability to create tools, but tool creation is only part of the equation. There's also the monumental task of building the social infrastructure to support whatever good we're trying to bring into the world. That's a task we're often not equipped to complete on our own.

It seems, then, that we should look at it through a similar, but subtly different lens.

Instead of asking "what's the best way to help people with software", maybe the question should be "who is already making a difference, and how could software increase their impact?"

Reduce your scope. Don't look for new ways to help society. At least not yet. Instead, look for groups of compassionate people who are united toward a common goal, and ask how software can help them achieve it.

I hope that helps in some way.

Prototype!

Companies that don't value these practices exist. They're everywhere. That's no excuse not to sharpen your skills, but hopefully it'll help you rest a little easier.

That said, the best medicine is practice.

To practice unit tests (or TDD when you feel like you're ready), do some katas. There are plenty of popular ones, and sites like http://www.codewars.com/ offer great challenges.

As you're working through your katas, make sure you check in to source control as you go. Learn the basics well, and pick up the rest as you go. You can always Google the more advanced stuff if you need it (most of the time, the basics are all you'll need).

For code reviews, read code. Read your own, certainly, but also read others. Hit up github. Find a repo you like, and then hit the 'commits' button. Read through the list of changes, and then write down what you think.

In real life, code reviews will be a little more tricky. You'll have to navigate a social structure and determine what is and isn't okay to say in a code review. Some groups are ruthless. Some are academic. Most, however, will be regular developers who are proud of their work, and the ability to criticize constructively will be of great value.

Two other suggestion come to mind for new team members. The first - be an apprentice first. Ask questions and learn. Especially in the beginning, your #1 job is to understand your environment - the people, processes, patterns, and practices that compose the overall work.

The second, take a shower. Nobody likes smelly teammates.

You should not ever, under any circumstances, apply the 'next big thing' to your project if your criteria for success is "other people are using it".

You should evaluate your needs and pick a tool based on those.

There aren't "winners". There are tools. Some of them are more effective at certain things than others.

If you are asking how to evaluate "which framework is going to win", then I'd argue you have no business making these decisions.

I'd have more time for articles like this if they didn't come from shitty, poisonous places.

The author doesn't care about helping others improve or shedding light on inadequacies of the technology.

The author only cares about strong-arming you with his own dumb opinions. The shortcomings of the software are secondary.

Save yourself some time and don't read this.

That's a good point, and probably a better way of saying it.

Because your ideas are generated internally. You're creating something before its necessary.

Find something that brings people pain, and then solve that pain. Your ideas will be generated from externalities.

Your thinking should shift from "how can I make this idea work" to "how can I solve this problem".

Fill in natural blanks. Don't try to create, try to solve.

Design considerations.