How do you balance object-oriented programming with other software development skills and competencies?

OOP is supposed to be easier to maintain. If your objects are loosely coupled then you can change one without affecting the others. However, if your objects are too loosely coupled then it's hard to find what needs to be changed to repsond to development requests from users. They don't know your objects so the request will be based on what they see vs what they expect to see. The design needs to keep business objects separate from the visual objects but have them easy to find for the developer.

OOP has been a hype in the 90s due to the way "objects" naturally map into everyday life, more so than pure functions and variables. Object-oriented design also opened up for interitance, which allows the reuse of common functionality across similar classed objects, making code more scalable, maintainable and easy to understand. As with everything else, there's also a way to over do OO, by treating everything as an object, burrying things in layers of abstraction with the aim of making it super flexible/modular, which in the end results in a bloated codebase which is both lower performing, harder to test and maintain.

I tend to agree with others' comments. Unless you're at the fringe of computer engineering, where you either need super high performing code because it's ran million times a day, or you need super low footprint for resource constraint applications: Rely on the compiler to help you! That said, I see a lot of people nowadays lacking understanding of the underlaying system architecture of where their code will run, assuming almost infinite available resources, which makes their code really inefficient. This is especially true nowadays in the web world, where a simple animation can end up using up 100% CPU on one core if it's not done right 🥲

No one should be programming for efficiency! (unless your code is run millions of times a day) Compilers and hardware are just so fast - and experience dictates that developers are terrible at guessing what parts of their code are inefficient, and often optimise little-called code. (early optimisation is a problem) On the matter of paradigms - modern languages try to lift us away from assembly language, and more to abstract concepts. This usually means more expressive and human-like. We should keep in mind that we write code first for developers, and secondly for the computer! - it must be maintainable! Some paradigms make work easier in asynchronous and multithreaded situations. Its worth considering that when faced with a problem.

I'll second not programming for efficiency. Even if your code is run millions of times a day, at the end of the day, we read code more than we write it. If I come across terse variable or function names, are we really saving any time? If I see something named, for example `bTxn`, what is that? Business Transaction? A ranked transaction where we used letters? (such that there's an aTxn running around.... somewhere, that is higher significance). Something else entirely? Even if your argument is that the context of the code should make it clear, in my experience rarely is that the case. If terseness of the final product is important, then you can do things like pre-compilation to solve that problem while maintaining human readability.

For those who are reading this and are new/newish: SOLID: (https://www.baeldung.com/solid-principles) S: Single Responsibility: A class, method, etc should be responsible for one thing and one thing only. O: Open/Closed: All code should be Open for extension but Closed to modification L: Liskov Substitution: Subtypes should be able to stand in for their super classes without causing issue I: Interface Segregation: Break large interfaces into smaller ones D: Dependency Inversion: Decouple your modules to depend on abstractions, not each other YAGNI: You Aren't Going to Need It DRY: Don't Repeat Yourself Be careful with DRY; my rule of thumb is I don't extract things until I'm using them for the third time.

YAGNI is perhaps one of the most overlooked principles of software engineering. When we focus on the essentials, and continually refining our code, we can enjoy the benefits of faster development, reduced technical debt, and improved overall software quality. As Antoine de Saint-Exupéry said: “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

The problem with YAGNI is that when you do need it, the managner who said YAGNI tries to deny every saying it. Instead it's suggested that of course it's needed, how could you think that it wasn't needed. It's one of the main flaws of agile programming, programmer creativity is stifled because they are programming to estimates and have no time to create top quality features. High quality takes time but garbage can be delivered straight away.

Factory isn't about hiding implementation details! Any class or Function / Method / Procedure can do that! A Factory has the responsibility of creating instances of an object on demand - usually with some fixed configuration, and some variable arguments, but not always. Design patterns don't seem to be talked about nearly enough - and perhaps have lost some of their shine since there's a lot of promotion towards Functional programming, which often negates the need to use many patterns that are object/relationship based. YAGNI and DRY principles have and always will be relevant!

One of my favorite RoR developers, Sandy Metz said something that I keep in mind: good tests are the wall of green at your back. What does this mean? It means you are free to experiment and try things. Want to try out that new pattern you've been learning? A solid wall of green lets you do that. When you know you have a safety net should you break things (and failing/breaking is how we learn best!) it lets you do that with confidence. And as odd as it sounds, knowing you have that safety net also lets you finish your work more quickly; no longer do you sit there trying to think of all the things that could go wrong and whether or not the risk is worth it. You just do it. And if things break, then you can fix it or back it out with ease.

If you don't have a test system with coverage of every feature combination, then you don't know whether your product works. I also like to have a subset of tests that are automatically run for every check-in, with test results sent at least to the author of the change, and to the project lead if the check-in is not on a private branch.

Unit tests are a great starting point of you have good acceptance criteria defined up-front. TDD is a natural consequence. Integration testing is a great starting point for using a 3rd party API with unknown responses (and bad documentation). They can also be converted into a mock/fake to turn an integration test into a unit test. Beyond this, developers tend to get too granular with their testing, which I term 'frag-testing' (fragment testing) and not 'unit' testing. I've always loved the idea of code coverage, but its not a metric many managers look for. Quality is an elusive concept, where "done" isn't "done, done". -and even then, often still not completed! What a messy world we work in!

It has been a long tradition to start new software developers in QA. If one can't figure out how to effectively test their code, what possible business do they have writing it ? Debugging is also a starting point to learning languages and development environments. Basically, we spend most of out time testing and debugging.

Developing something is a lot about trying to get what you have in mind, down to some functional piece of code. This involves a lot of iteration (and failing under the process), until you end up with something that you're good with. Your debugging and testing strategy along the way can significantly impact how quickly you can iterate and the quality of your deliverables. Choosing the right methodology for it is also highly dependent on the type of project, environment, available tooling and your overall appetite (or requirement) for speed vs. quality.

"Good code documents itself", as they say. While this is true to some extent on simple code, for the rest, writing good documentation is as challenging as writing the code itself. Why? Because it needs to not only comment on what the actual piece of code is doing, but give enough context on the general idea behind it, why it's designed in a certain way, where it will be used and so on.

Documenting the code without updating the documentation when the code is updated can create confusion. So now the people who update the code, which is precise, also have the extra responsibility of updating the documentation, which is imprecise and might even be lengthy.

Fear of losing one's job is a major reason many programmers don't document their code. A lack of time is another but that's only for trying to document code after it's been written. You can see numerous examples of bad documentation from Microsoft, where it's clear that you already need to understand what's being documented before the documentation makes any sense, i.e. no hallway useability testing.

yes! The elephant in the living room! No one sees it, no one looks at it, or talks about it. Documentation is dead from the moment you write it! inline comments? Love them. Function/method/procedure comments? Love them too! Object comments? A real must-have! Beyond this, as you check-in code, I hope there's a way to link your work to what ever management software you're using, which gives developers a change to look at DevOps / Jira or the like - and get the context of the code changes they see. Beyond that, there must have been some requirements the code was developed against? All this is documentation - and few think to distil it to user documentation / technical documentation. Projects already overrun and cost too much! argh!!

With SDLC processes already producing documentation and version control tools creating a trail, clean and readable code would be the focus. (where possible, sometimes performance can take precedence over maintainability) Needless and time consuming documentation. Comments that create a mess rather then readable code. Developers that insist that their essential job function is not English Composition. We document and comment for clear reasons, not just because. There is no one size fits all solutions to software.

The best documentation in my opinion and experience is solid tests. By their very nature, tests tell you and everyone else a bare minimum of what your code SHOULD be doing (or SHOULD NOT in some cases). By its very nature (unless you're mocking a lot, but that's a different convo) it is live and never becomes dead wood like other documentation (even inline comments!) eventually becomes. If what your code does changes and your tests are quality, you will know instantly if your documentation is no longer accurate -- because your tests will start to fail.

Check your ego. See questions, even a simple "Why?" as an opportunity to teach and to learn. The moment your team doesn't feel comfortable talking to *anyone* on the team about why something is the way it is, and why a different approach wasn't used is the moment your team is falling apart. Remember that your code isn't you, there is always someone with more knowledge than you, and someone with less. A junior dev might know more than you on some things, and a senior might know less than you on others. If you approach questions and conversations with your team mates with curiosity and a desire to learn, your team will be a powerhouse, your juniors will level up faster, and you will deliver top notch solutions to your clients.

Collaboration is key to all but very small projects. If it's done right, it's also a great way to learn from others, improve yourself and have fun in the process! Over the last 3-4 decades, we, as developers, have tried many different ways of collaborating with each other, and doing so remotely is engrained in how we work. There are no shortage of wonderful tools to help facilitate it, and frameworks & methodologies to apply. But above all, collaboration is about PEOPLE, and each group of people are unique, so there's no one fit for all. The most important thing is to be open minded, curious, receptive to feedback and humble.

OOP follow a bottom-up approach. OOP tells the program how to achieve results through objects altering the program's state. OOP allows constructing a program using a set of objects and their interactions. Once this is understood, then it's easier to balance OOP with Structured, Procedural, Functional programming, other software development skills and competencies.

There is no one size fits all solutions to software. Everything is done for very clear reasons and not just because... Sometimes it helps to understand why things are done the way they are. Sometimes asking "why" directly will make others jumpy and assume criticism. So keep asking "why", but do it with professional discretion.

A full stack engineer/developer not only does OOP programming but also several other forms of programming. For example, with lots of cloud computing now enabled for many projects, Infrastructure as code has also become part of development and part of DevOps deployment models.