Be An Agnostic Programmer

[-]

Public_Being3163@reddit

nicely written. could take some of your points in different ways but accept them as literary devices, rather than triggers. when does your book come out?

[-]

moreVCAs@reddit

“If you don’t follow TDD, you’re not a professional.” “If you think OOP leads to overengineering, you’re doing it wrong.” “100% code coverage is the gold standard.”

I’ve never met a serious person who claims any of these things

[-]

Beautiful_Grass_2377@reddit

This is totally something who's still studying would say

[-]

He's who's cited by the researcher who wrote a badly maintainable design. "I did this because of the xyz principle." "Right, and as soon as you will move on the implement the next feature it will fall apart and drags 4 classes with it."

[-]

wolfy-j@reddit

Love engineers that pick patterns and stack before they even know the domain problem, never gonna leave me without a job.

[-]

moreVCAs@reddit

serious person

👆

with all due respect. also i’ve never met the guy; i’m sure he’s very smart. definitely a great salesman.

[-]

chrisza4@reddit

There are person who saying these but if we simply label them not serious we kind of neglect or solve the whole problem of tech community. Bad behavior? Bad trend? Nah, they came from not serious people.

I don’t like Uncle Bob btw, but I can see why some people perceive that there is a lot of dogmatic in tech.

[-]

moreVCAs@reddit

i think this is a charitable reading of the three claims and an uncharitable reading of my claim. all three are weirdly absolute dogmas that i, truly, have never seen someone express in real life.

does that mean nobody does? certainly not. does it mean i’m choosy about who i take advice from? absolutely. but more importantly, i don’t feel any obligation to argue against three ridiculous overstatements that nobody I take seriously is arguing for.

[-]

grauenwolf@reddit

That's an understatement. SOLID has been a minor religion for over a decade.

[-]

-Y0-@reddit

I've definitely met people insisting on near 100% code coverage. There are dumb people everywhere.

[-]

jk147@reddit

Sure, if I had all of the time in the world to code whatever I want.

[-]

A1oso@reddit

I've met developers who seemed to think that OOP is perfect and didn't want to consider other paradigms. Following the mantra "OOP is what I know, and it has worked well enough for me so far".

[-]

moreVCAs@reddit

sounds reasonable, but that’s very different from “if you don’t like it you’re doing it wrong”.

[-]

cipp@reddit

Same. This reads like a conversation OP had in his head.

[-]

Lechowski@reddit

He had it with chatgpt for sure

[-]

moreVCAs@reddit

Yeah I think about this occasionally. It could just be a straw man constructed for blogspam purposes. Or it could be that people are stuck in a kind of Ouroboros of incompetence where generations of mediocre engineers are learning dumb ideas from people who have no idea what they’re doing and passing that knowledge down to the next generation as “best practice”. If the latter, then good on OP thinking for themself.

[-]

grauenwolf@reddit

Programming books are a major culprit, because they hold the ultimate air of authority.

No, blind faith in programming books is the culprit.

Anyone who bothers to look at the code samples in Clean Code can immediately see that the book is garbage. But you have to actually look and not just accept the book on blind faith.

Robert Martin flat out tells you that he's conning you in his blog post on SOLID, but people refuse to believe him. Instead they treat him as a religious figure, and that's where the real problems begin.

[-]

I_AM_AN_AEROPLANE@reddit

Clean code is one of the biggest cancers in software development, as the concept is too difficult to grasp for many, leading to “layered spagettio”.

It leads to an incoprehensible amount of redirections and fragmentation.

[-]

grauenwolf@reddit

Are you sure you aren't thinking about Clean Architecture?

Clean Code is stupid shit like not having more than 4 parameters to a function and passing everything else via member fields.

[-]

I_AM_AN_AEROPLANE@reddit

Hmm perhaps, same author though, same shit.

[-]

grauenwolf@reddit

Same flavor, but in fun new shapes.

[-]

CooperNettees@reddit

When you include the word “engineering” in your title, people think your discipline is this scientific, rigorous, methodological process that yields the best answer based on collective historical experience. And to the layman, it might seem so. After all, software runs on machines, and machines fall under “engineering.”

But let’s not kid ourselves.

Software development isn’t a science.

It’s not an art, either. It’s a mix of both, and that’s why I love it.

The science is in the logic of your program and the architecture of your system. It’s in how well you can prove the correctness of your code (invariants, assertions, tests, etc). And it’s in how you investigate and deduce your way to the root causes of issues.

But there’s a human element, too.

With every sizable new system or feature, you explore while your design isn’t yet crystallized, and that gives room to creativity. You don’t always know how your interfaces (APIs, classes, namespaces, modules, etc) will end up until you have a good amount implementation in front of you (part of my dislike of by-the-book TDD).

I can't help but point out that engineering, science, and math all also operate like this. I find it weird when people say "software isnt a science, its a science and an art" and then follow up with language like this. every novel human initiative ends up looking like this regardless of domain, its not a special characteristic of software development.

[-]

TheScullywagon@reddit

Genuinely every human domain can be extrapolated into science and art. The most artistic domain will still have elements informed by logic and science. This goes both ways

[-]

CooperNettees@reddit

absolutely

[-]

ciurana@reddit

My beef isn't with how this is explained, but with people whose programming training is incomplete and lacks math, computer science, computer architectures, networking and communications, and otherwise the things that an engineer is required to know in order to graduate.

Cheers!

[-]

grauenwolf@reddit

That's fair. There's a huge difference between being a software engineer and just knowing how to write programs.

[-]

mfitzp@reddit

Yeah. I liked the article & agree with the point. But this part tells me the author hasn’t worked in science. The decisions of what to do next are mostly based on hunches, gut instinct, or who you want to work with. It’s only logical, methodical at the smallest scales. Much like programming.

[-]

Global-Biscotti-8449@reddit

Good points but the author misses how science actually works. Most decisions come from intuition and collaboration not pure logic. Same as programming

[-]

IDatedSuccubi@reddit

People get really confused when I tell them that completely mechanical machines made of gears and levers have bugs just like software does. And bad management, bad planning, overlooked edge cases. There's even "elegant code" in the form of well made drawings, easily modifiable CAD files and documentation.

[-]

elSenorMaquina@reddit

I've been doing some CAD as a hobby, and very quicky realized that there's a nice way and a spagheti-ish way to define the sequence of operations that result in a parametric 3D model.

the "nice" way to do it is such that you can change a parameter and all the things that follow adapt to it with minimal to no refactoring. The spagheti-ish is such that eveything breaks if you touch something and you have to edit multiple stuff everywhere so it "compiles" to a valid part once again.

So, yeah, I second the idea that well designed code and well designed CAD parts share at least that.

[-]

grauenwolf@reddit

...and sometimes you don't realize you're doing it the spagheti-ish way until you go back to try to change it.

I ran into that today when I needed to repurpose a model. Same shape, just needed to move some dimensions. And wow, my parameters were garbage.

[-]

LucasOe@reddit

It's funny to me that the author chose OOP as something that's being preached (I do agree!), because I just had the opposite experience a few days ago: I was telling a friend of mine, who's a C# programmer, how OOP is bad and he should use composition over inheritance, etc., and at the end we came to the conclusion that OOP and inheritance can be just fine if you don't overdo it and know the trade-offs. I was the one preaching "OOP leads to overengineering!"

I also think that sometimes programmers think you're preaching just because you state your preference. Someone will say, "I like Rust!" and people will say they're part of a cult just because they like something.

[-]

mlitchard@reddit

Composition is the way to handle complexity. Slings and arrows incoming.🥸

[-]

sprouting_broccoli@reddit

As someone who spent a ton of time in C++ and C# and a good amount of time with Go and a decent amount of time as an architect I couldn’t agree more. Composition with interfaces is a much better pattern for engineers to follow than trying to build out complex inheritance hierarchies which are difficult to modify or understand. There are use cases for inheritance but they’re really few and far between and generally not worth the trade off. Preventing people from over engineering with inheritance is one of the easiest wins in terms of complexity when building a new system.

[-]

grauenwolf@reddit

Inheritance shouldn't be an architectural issue. You use inheritance to solve specific implementation problems as they arise.

If you start by saying "I should be using inheritance here" or "I should be using composition there" then chances are you're wrong.

[-]

sprouting_broccoli@reddit

Sure, but my responsibilities as an architect generally included code quality and overall guidance for the engineering team. Generally composition can solve any problem and engineers who see inheritance in codebases continue using inheritance because it’s pleasing aesthetically and often engineers will implement aesthetically rather than thinking about the maintenance burden they’re creating.

Singletons aren’t an architectural concern either but I’d discourage engineers from using them.

[-]

grauenwolf@reddit

Singletons aren’t an architectural concern either but I’d discourage engineers from using them.

Why?

I'll admit that it's a rare situation where I actually need to define a singleton. Most of the time a static class will serve the same role. The exception tends to be a class that could have been static, but needs to implement an interface or inherent from a base class.

More often I use semantic singletons. These are classes that are not technically a singleton but you treat them as if they were. For example, Utf8Encoding is effectively a singleton. You could create your own instance of it if you need to use an unusual configuration like changing how it applies byte order markers. But the overwhelming vast majority of people are just going to use it as a singleton.

[-]

sprouting_broccoli@reddit

They’re difficult to test and debug and typically not being able to control the lifetime of a class, especially when it’s holding mutable state, can cause a bunch of weird interactions (which applies to anything with global state like static classes).

Again, there are use cases for them but it’s usually perfectly possible to a use dependency inversion to pass a single instance of the relevant object down your hierarchy. This relies on sensible class design as well - ie throwing a dictionary of settings literally everywhere isn’t generally the right way to do it either.

The most common use case for singletons that makes sense is loggers but a lot of the time using a singleton is a sticking plaster for lazy class design - ie dump everything related to x in this singleton to avoid having to pass it sensibly.

It’s really commonly accepted practice to avoid global state and especially mutable global state - singletons are just global state wrapped in a design pattern and let’s not get into Alexandrescu’s phoenix singleton…

[-]

grauenwolf@reddit

especially when it’s holding mutable state

Okay, sure. If your staff is so stupid that they keep trying to put mutable data into application scoped objects, then sure you can ban singletons. But it's not really the singleton that's causing the problem.

Again, there are use cases for them but it’s usually perfectly possible to a use dependency inversion to pass a single instance of the relevant object down your hierarchy.

That's a separate question. A lot of my singletons are passed down through dependency injection. In fact, the built-in DI framework for asp.net core has an option to treat normal classes as if they were singletons. If a class is thread safe, chances are you don't need more than one for the whole application.

singletons are just global state

Again, that's not necessarily the case. But when it is, there's often a really good reason. For example, in WPF you need the Application object to deal with the OS.

[-]

sprouting_broccoli@reddit

Oh sure, and I agree with all of what you’re saying here which is why I’d “discourage” singletons unless people are critically thinking about them. I have zero problem with sensible usage but we don’t always get development teams or legacy code that we’d like :)

[-]

mlitchard@reddit

Word on the street is c++ is upping its functional game.

[-]

sprouting_broccoli@reddit

It’s been 15 years-ish since I used it and I never spent the time keeping up with the fun changes other than a passing interest - I’m glad the direction it seemed to be going though!

[-]

grauenwolf@reddit

Inheritance is just composition combined with polymorphism. At this point I'm convinced that anyone who says to favor composition over inheritance probably doesn't know how to use inheritance correctly. So for them the advice is actually good.

[-]

Dean_Roddey@reddit

OOP can be used to great effect. I used it in a very large and very complex product I supported for a couple decades, which went through massive changes over that time and stayed completely clean. That's just because I did the right thing.

Now, I use Rust and I'm doing well with out it as well, though 'it' here means inheritance, not object orientation. Rust is very much object oriented, it just doesn't support implementation inheritance. Of course it also doesn't take the 'everything is an object' approach either. It's something in the middle, but objects are foundational to it.

The gotcha is not doing the right thing, and languages that really push back hard against not doing the right thing or that just don't support mechanisms that best allow not doing the right thing are going to be a better choice in more average commercial, team based, deadline driven development. Rust is one of those languages, though it also has a MANY advantages for individual or small team development as well.

Of course now someone will call me an zealot. But honestly, going by word poundage, you see a lot more of people screaming about Rust zealotry than actual Rust zealotry in most discussions around here.

[-]

mcknuckle@reddit

People don't have a psychological disposition to presume statement of preference for a language correlates with or equates to preaching. This is something specific to Rust and there is a reason for that.

[-]

LucasOe@reddit

I downvoted you because you're making a strong claim without any evidence. The problem isn't entirely specific to Rust. I've seen the same with Lisp, Haskell, and even Emacs or Vim. When enthusiasm gets very vocal, outsiders start interpreting even neutral preference statements as evangelism.

I was wrong on one point, though: it's not just a problem among programmers. The same thing happens everywhere. I’ve even had people act like I’m crazy for saying I don’t like Harry Potter when it's just a personal preference.

[-]

mcknuckle@reddit

You're being disingenuous.

[-]

FlyingRhenquest@reddit

OOP is fine as long as you don't try to model the world. Most OOP tutorials talk about cars or animals and the noises they make, both of which are terrible examples, and they usually lead to you overthinking your system design. In reality you should be putting the majority of your engineering effort into the API you expose to the rest of the world, because people aren't going to have to become subject matter experts in order to use your library. That's really true no matter what style of programming you use.

[-]

grauenwolf@reddit

What pisses me off is that EVERY OOP programming has a standard library that you can use to demonstrate real OOP concepts.

Want to see inheritance in C# used correctly? Look at System.Data.DBConnection and its database specific subclasses.

Want to see the negative effect of not using LSP? Look at the IList interface.

There are endless things to talk about. We never needed to invent Animial => Duck => LameDuck.

[-]

mfitzp@reddit

Anyone who criticises someone else’s language choice is usually just deeply insecure about their own choices.

[-]

romulof@reddit

[-]

Ready-Marionberry-90@reddit

I‘d rather be a militant atheist programmer, thank you.

Badum tsssss

[-]

grauenwolf@reddit

The classic example is Object-Oriented Programming. Many developers had their first exposure to programming through this paradigm, and were taught little else. So when they went into the workforce, they constantly ran into problems that didn’t map neatly onto OOP principles. So what did they do? They forced them to, like a square peg when all you have are round holes.

No one is taught "Object-Oriented Programming". I wish they were, but they aren't.

Instead people are taught to memorize the examples in the appendix of a poorly written book titled Design Patterns.

If you want to learn about design patterns, you have to start by learning about the concept of a pattern language. This forms the basic context that you're working in, for which you can then select or create design patterns to fit.

An example of a pattern language in software engineering would be "Controller style API server with REST conventions".

From there you pick the DI conventions, controller design, etc. that are specific to your language and framework. These are your "design patterns", not the random stuff you were told to memorize in a book.

For OOP, you need to learn...

What are the OOP features in your programming language?
What specific problems does each feature solve?
What problems does using each feature cause?

And of course rule 0: "Don't use an OOP feature unless you have the specific problem the OOP feature is meant to solve." with the corollary "Loose coupling, maintainability, and other such vague concepts are not specific problems. If you can't express the exact problem not using this feature will cause, you don't have that problem."

[-]

grauenwolf@reddit

You don’t always know how your interfaces (APIs, classes, namespaces, modules, etc) will end up until you have a good amount implementation in front of you (part of my dislike of by-the-book TDD).

This tells me that the author doesn't know what "by-the-book TDD" actually is. They learned TDD from bloggers who didn't know what it means either, which is where a lot of the problem comes from.

When Beck was talking about unit tests, he wasn't talking about those tiny tests that touch one method of one class. He calls them 'exploratory tests' and expects you to delete them when you're done with them.

For Beck, a unit test covers a large piece of functionality. It can touch files. It can touch databases. The only thing it is isolated from is other tests so that you can run the tests in any order.

[-]

ILikeLiftingMachines@reddit

Writing shitty code is language agnostic.

[-]

grauenwolf@reddit

I have to disagree. For weapons-grade fuckery, you need to abuse language specific features.

[-]

diseasealert@reddit

True, but some languages make that easier than others. looks at Perl

[-]

mlitchard@reddit

/me twitches

[-]

OddMoon7@reddit

Lmao, this sounds like the most Reddit shit I've ever heard in this sub.

[-]

HademLeFashie@reddit

Every part of this article resonated with me, except the "plotter" and "pantser" stuff at the end. I'm not really a writer but good article.

[-]

levelstar01@reddit

If civil engineering is a mature field, then software development is a baby. An ugly baby, but perhaps a late bloomer. The so-called “best practices” of our industry are a chaotic nebula of differing, often incompatible, perspectives.

“If you don’t follow TDD, you’re not a professional.”

“If you think OOP leads to overengineering, you’re doing it wrong.”

“100% code coverage is the gold standard.”

But I’m not here to discuss individual practices in detail. Instead, I want to zoom out and look at how we got here in the first place. Strap in, because this is gonna get philosophical.

Margaret Hamilton coined the term “software engineering” to lend the discipline a legitimacy when the moon landing was in the works. It seems to have worked. Although nowadays, the term is so broad that a simple React web app also qualifies.

When you include the word “engineering” in your title, people think your discipline is this scientific, rigorous, methodological process that yields the best answer based on collective historical experience. And to the layman, it might seem so. After all, software runs on machines, and machines fall under “engineering.”

But let’s not kid ourselves.

Software development isn’t a science.

It’s not an art, either. It’s a mix of both, and that’s why I love it.

The science is in the logic of your program and the architecture of your system. It’s in how well you can prove the correctness of your code (invariants, assertions, tests, etc). And it’s in how you investigate and deduce your way to the root causes of issues.

But there’s a human element, too.

Absolutely not reading something written in LinkedIn-ese

[-]