Worst Programming/Technical Advice And Fads - Trends that do more harm than good.

[Judge Dredd]

What's the worst programming advice you've heard, or just technical advice in general? Any particular tech trends that held things back, or are just bullshit?

I'll start with three.

First is the phrase "move fast and break things". I first heard of this recently, but it supposedly dates back to the early days of facebook. I assume there was some logic to it, but I struggle to think what.

Second, the programming advice "never use globals". "Never use globals" was something I struggled with early in game development as I took the advice literally. The actual advice should be "keep things in scope", but what might have been well meaning advice to stop beginners leaning on globals turned into dogma where using a global is a failure state ...unless they do it of course.

Third, and related to the above, the hatred of nested if statements. From what I can tell, this comes from people mocking the code for Yandere Simulator, which used them excessively.

 

[Zeftax]

never use globals

Almost all of these "NEVER DO THIS!!!11!!!!!!1" mantras. "Never use goto anywhere ever" comes to mind.

 

[We Are The Witches]

"move fast and break things"

Maybe it means that you should be bold and try things that you have not experimented with in the past before, so you'll end up breaking them, but in the process, you'll learn from those mistakes.

As opposed to taking things very slowly or in a conservative manner. So in essence, appreciating or taking advantage of what failure can bring to the table, if you're interested in knowing what's what caused the error.

It's what I understand it as.

 

[Kuroyuri]

"Use <insert person's favorite neo-lang here>!"

 

[YOU ARE]

Clean Code™ has become dogma and keeps getting abused by poo-grammers. Especially "each function should be small and do one thing". Also "comment your code" gets misconstrued to "write comments above every single line saying what the code is doing". Comments should contain documentation, or explain why you're doing something, not what you're doing. The latter should be conveyed by the code itself.

 

[Jerry1337]

Computers fucking suck dick, and I'm tired of pretending that they don't.

 

[agent_donkey]

Almost all of these "NEVER DO THIS!!!11!!!!!!1" mantras. "Never use goto anywhere ever" comes to mind.

Do not forget about the ALWAYS mantras either.
> always write tests before writing any code (TDD)
> always comment your code
> always mark member variables as private
> always commit after an edit
Etc.
Compsci is no place for dogma.

 

[The Mass Shooter Ron Soye]

Computers fucking suck dick, and I'm tired of pretending that they don't.

Sex robot experiences fatal error, chomps off dick.

 

[Anti Snigger]

Almost all of these "NEVER DO THIS!!!11!!!!!!1" mantras. "Never use goto anywhere ever" comes to mind.

Goto is a massive filter, I don’t know how programmers convinced themselves that unconditional jumps were somehow bad

 

[Estate]

Especially "each function should be small and do one thing".

What's your exact gripe here?
Functions should be small and do one thing because:
1. Easier to read
2. Reusable
3. Easier to test

Clean Code™ has become dogma and keeps getting abused by poo-grammers

I've worked with jeets for years, on huge american projects and there's nothing clean about their work.
I fucking wish jeets would be dogmatic about clean code, but in reality, they push dogshit code, bitch if you reject their PR, bother you non-stop if you comment their work, and bitch to managers because they couldn't finish their work because you didn't approve it, not because it's pure slop.
Sorry, when it comes to jeets, past experience makes me froth at the mouth.

 

[Anti Snigger]

What's your exact gripe here?
Functions should be small and do one thing because:

Stack frames are something to be mindful of

 

[DumbDude43]

What's your exact gripe here?
Functions should be small and do one thing because:
1. Easier to read
2. Reusable
3. Easier to test

>easier to read
debatable, depends on how you do it
check this for example

relevant part starts at 12:24
some people take the "short functions" meme to such an extreme that it completely ruins code readability

 

[Disquiet]

My jeet collage programming teacher (java of course) told us to comment on every line of code. He said when we got a job we would be reviewed based on the number of lines we write. All of the jeets i've worked with do this.

// return the posts from the database
return posts;

 

[Diesel Boogaloo]

What's your exact gripe here?
Functions should be small and do one thing because:
1. Easier to read
2. Reusable
3. Easier to test

If all functions can only do one thing, then the entire program can only do one thing, as after all, all a typical program does is call main.

 

[Coolio55]

Second, the programming advice "never use globals". "Never use globals" was something I struggled with early in game development as I took the advice literally. The actual advice should be "keep things in scope", but what might have been well meaning advice to stop beginners leaning on globals turned into dogma where using a global is a failure state ...unless they do it of course.

Globals are fine when used properly but a "global scope" struct with most of the data that you can pass into functions retains most of the convenience while allowing you to trash/spin up more instances as needed.

I've worked with jeets for years, on huge american projects and there's nothing clean about their work.
I fucking wish jeets would be dogmatic about clean code, but in reality, they push dogshit code, bitch if you reject their PR, bother you non-stop if you comment their work, and bitch to managers because they couldn't finish their work because you didn't approve it, not because it's pure slop.
Sorry, when it comes to jeets, past experience makes me froth at the mouth.

I want to find whoever invented factory classes and fucking kill them.
What it sets out to "accomplish" can also be accomplished by a simple find/replace job.

Goto is a massive filter, I don’t know how programmers convinced themselves that unconditional jumps were somehow bad

Goto + switch case + fallthrough is good fucking shit for certain problems.

 

[Kendall Motor Oil]

First is the phrase "move fast and break things". I first heard of this recently, but it supposedly dates back to the early days of facebook. I assume there was some logic to it, but I struggle to think what.

It depends on the company and their culture. We are the Witches is correct about what it means. The moving fast and breaking things is more about pushing forward with projects/deployments/features by accepting that failures/outages will occur. The alternative is a process so slow that projects don't complete or a mess of backwards compatibility needs to be added for deprecated versions of software that creates more tech debt.
Bad mangers will use that phrase as a way to overwork people while also taking issue with breaking things.

 

[Judge Dredd]

Clean Code™ has become dogma and keeps getting abused by poo-grammers. Especially "each function should be small and do one thing". Also "comment your code" gets misconstrued to "write comments above every single line saying what the code is doing". Comments should contain documentation, or explain why you're doing something, not what you're doing. The latter should be conveyed by the code itself.

What's funny is that you shit on clean code, then immediately talk about what clean code was supposed to fix. eg. The over use of comments. Comments should be used to describe the how and why only if it isn't immediately obvious. That's also the premise of keeping functions small and doing one thing.

It's sounding like clean code has become a dogma that has moved away from it's intended purpose.

Related to that, I had a bunch of people oppose clean code because Uncle Bob is a nazi. ...or something like that.

Maybe it means that you should be bold and try things that you have not experimented with in the past before, so you'll end up breaking them, but in the process, you'll learn from those mistakes.

Bad mangers will use that phrase as a way to overwork people while also taking issue with breaking things.

The recent way I say it used was justifying breaking things for no real benefit. As in destroying data that had no backup, or degrading functionality that may or may not be fixed. But hey, gotta move fast and break things. sunglasses emoji

Do not forget about the ALWAYS mantras either.
> always write tests before writing any code (TDD)

Agreed. Double points if they don't know what it means.

One I left out of the OP. But "Industry Standard" being the only value of a tool or technique. While a tool or technique only becomes "industry standard" when something makes a shit load of money.

In old games like Doom and Half-Life, you texture as you go because brushes are made to fit the texture. In Half-Life 2, they used orange textures as placeholders so the texture artists could come in after testing and pretty up the levels. I've seen said textures backported to those old games with the logic that "Finally, professional industry standards comes to modding".

Unreal engine was industry standard. GameMaker was a babies engine, until Hotline Miami blew up. Unity was babies game engine, until Harthstone. Every game should be made in C++, until Balatro used Lua and now that's the language of choice. I could go on but you get the idea.

 

[Kendall Motor Oil]

The recent way I say it used was justifying breaking things for no real benefit. As in destroying data that had no backup, or degrading functionality that may or may not be fixed. But hey, gotta move fast and break things. sunglasses emoji

I've never seen that in the industry but people will use any phrase to justify their behavior.
Usually management outside the technical departments have a lot more sway with upper management so they can slow things down because they can't handle any downtime.

 

[Creative Username]

Second, the programming advice "never use globals". "Never use globals" was something I struggled with early in game development as I took the advice literally. The actual advice should be "keep things in scope", but what might have been well meaning advice to stop beginners leaning on globals turned into dogma where using a global is a failure state ...unless they do it of course.

the real advice is "avoid using mutation" because globals are what novice programmers like using to mutate things and affect some shit halfway across the program, causing really hilarious bugs in the process

Almost all of these "NEVER DO THIS!!!11!!!!!!1" mantras. "Never use goto anywhere ever" comes to mind.

Goto is a massive filter, I don’t know how programmers convinced themselves that unconditional jumps were somehow bad

goto should be avoided when possible but there are certain cases (c error handling) where it is quite nice
a goto or two is very nice but only when used in idiomatic and easy to comprehend ways (breaking out of nested loops, early return with extra (freeing memory) steps, etc.)

My jeet collage programming teacher (java of course) told us to comment on every line of code. He said when we got a job we would be reviewed based on the number of lines we write. All of the jeets i've worked with do this.

// return the posts from the database
return posts;

daily reminder: lines of code should be measured in "spent" lines of code, not "written"
otherwise you get amazing swathes of code that love assigning every single intermediate value to a variable like it's an assembly program, and 5 comments in between each line because the reader might get lost
don't forget 11,000 "well-factored" classes that mainly just serve as structs but with the opportunity to add a few 3-line getters and setters each for maximum line count

Every game should be made in C++, until Balatro used Lua and now that's the language of choice.

the c++ dicksucking is one of the most retarded things in game development
garbage collectors are fast enough these days
hell you could probably make a 3d shooter in ruby and not experience any cpu-related issues if you didn't program it like a complete retard
unfortunately many games are programmed like a complete retard

so here's my gripe for the thread: "make sure to always use c++ everywhere for le heccin performancerino!"

 

[rando[Numbers]]

Get AWS/Azure/GCP certified: Had a few contract companies push hard on this just because they want partnership to get on stores. I saw AWS was just a ad for Lambda/Dynamo and loled out of there.

The best way to get a raise is to quit: This mindset fucked the industry. Really tired of spending all my time cleaning up shit left behind by people who had no intention of sticking around. If you want to be rich, don't work for other people, period. If you want to grind, stop applying to jobs.

Much of every other problem I see is a lack of advice, not bad advice. I've never met a working professional that sits around and argues language semantics or basic design patterns. These are undergrad concerns.

What I see is a lack of discipline and engineering. No testing, no architecture, no design, no communication, no API contracts, no requirements, no maintenance, just throwing code around like shit eating monkeys.

Industry could do with more advice, not less tbh. You can't whine about programming features when you're dealing with the real world.