Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "do you even know that author"
-
!rant
After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:
1) Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.
2) Working independently is a must. It's okay to ask questions, but ask sparingly. Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc..)
3) Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.
4) Ask for peer reviews and LISTEN to the critique. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Peer reviews are win-win-win.
5) When in doubt, do NOT BS your way out. Refer to someone who knows, or offer to get back to them. Often times, persons other than engineers will take what you said as gospel. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.
6) Slow down in order to speed up. Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. Rushing to complete, even for senior engineers, usually means less-than-ideal code that somebody will have to maintain.
7) Write documentation, always! Even if your company doesn't take documentation seriously, other engineers will remember how well documented your code is, and they will appreciate you for it/think of you next time that sweet job opens up.
8) Good code is important, but good impressions are better. I have code that is the most embarrassing crap ever still in production to this day. People don't think of me as "that shitty developer who wrote that ugly ass code that one time a decade ago," They think of me as "that developer who was fun to work with and busted his ass." Because of that, I've never been unemployed for more than a day. It's critical to have a good network and good references.
9) Don't shy away from the unknown. It's easy to hope somebody else picks up that task that you don't understand, but you wont learn it if they do. The daunting, unknown tasks are the most rewarding to complete (and trust me, other devs will notice.)
10) Learning is up to you. I can't tell you the number of engineers I passed on hiring because their answer to what they know about PHP7 was: "Nothing. I haven't learned it yet because my current company is still using PHP5." This is YOUR craft. It's not up to your employer to keep you relevant in the job market, it's up to YOU. You don't always need to be a pro at the latest and greatest, but at least read the changelog. Stay abreast of current technology, security threats, etc...
These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!221 -
"You gave us bad code! We ran it and now production is DOWN! Join this bridgeline now and help us fix this!"
So, as the author of the code in question, I join the bridge... And what happens next, I will simply never forget.
First, a little backstory... Another team within our company needed some vendor client software installed and maintained across the enterprise. Multiple OSes (Linux, AIX, Solaris, HPUX, etc.), so packaging and consistent update methods were a a challenge. I wrote an entire set of utilities to install, update and generally maintain the software; intending all the time that this other team would eventually own the process and code. With this in mind, I wrote extensive documentation, and conducted a formal turnover / training season with the other team.
So, fast forward to when the other team now owns my code, has been trained on how to use it, including (perhaps most importantly) how to send out updates when the vendor released upgrades to the agent software.
Now, this other team had the responsibility of releasing their first update since I gave them the process. Very simple upgrade process, already fully automated. What could have gone so horribly wrong? Did something the vendor supplied break their client?
I asked for the log files from the upgrade process. They sent them, and they looked... wrong. Very, very wrong.
Did you run the code I gave you to do this update?
"Yes, your code is broken - fix it! Production is down! Rabble, rabble, rabble!"
So, I go into our code management tool and review the _actual_ script they ran. Sure enough, it is my code... But something is very wrong.
More than 2/3rds of my code... has been commented out. The code is "there"... but has been commented out so it is not being executed. WT-actual-F?!
I question this on the bridge line. Silence. I insist someone explain what is going on. Is this a joke? Is this some kind of work version of candid camera?
Finally someone breaks the silence and explains.
And this, my friends, is the part I will never forget.
"We wanted to look through your code before we ran the update. When we looked at it, there was some stuff we didn't understand, so we commented that stuff out."
You... you didn't... understand... my some of the code... so you... you didn't ask me about it... you didn't try to actually figure out what it did... you... commented it OUT?!
"Right, we figured it was better to only run the parts we understood... But now we ran it and everything is broken and you need to fix your code."
I cannot repeat the things I said next, even here on devRant. Let's just say that call did not go well.
So, lesson learned? If you don't know what some code does? Just comment that shit out. Then blame the original author when it doesn't work.
You just cannot make this kind of stuff up.105 -
Hashedram's compilations #1
List of most annoying website designs.
1) Pages with AUTO PLAYING VIDEOS.
Yes I'm looking at you Netflix. Along with every news website known to man. I'm looking to read a fucking article, so why would you even waste your money and bandwidth trying to shove a video of some shit I don't care about in my face, and make it follow me as I scroll down like a fucking insecure puppy. Also, fuck you Instagram.
2) Pages that redirect once immediately after you visit them, thereby fucking with the browser history and the BACK BUTTON just leads back to the same fucking site.
I mean, just why. Did you think I would just go "Hey the back button doesn't work so let's stay on the site and read their awesome content"?
3) Sites showing things in a SLIDESHOW, when it actually should be in a list.
Slideshows are for progressive stories or for showing lists where you don't care about what's in them. Top 10 foods that reduce weight. Slideshow 1/15. Fuck you.
4) LOOKS LIKE YOU'RE USING AN AD BLOCKER
Yes. Yes I am. No I will not turn it off for you, you narcissistic snowflake fuck. And don't even try to guilt shame me into turning it off, because I know you're just going to bombard me with videos of sexy singles in the area if I do.
5) Pages where I see the first 3 lines of an article and have to SUBSCRIBE to see more.
Yes. Brilliant fucking idea. A user wants to see what your site has to offer, so within the first three seconds, don't show him exactly that.
6) Looking up an article and having to read through the entire motivational life story of the author.
I just want to know how to boil eggs, not read about your journey across Africa learning how to make difference recepies using boiled rhino dung.
7) CLICK BAIT.
Title: School boy designs blockchain machine learning game engine
Actual Content: Tic tac toe program made using linked lists6 -
An excerpt from the best rant about whiteboard interviews posted on the internet. Ever.
"Well, maybe your maximum subsequence problem is a truly shitty interview problem. You are putting your interview candidate in a situation where their employment hinges on a trivia question. — Kadane's algorithm! They know it, or they don't. If they do, then congratulations, you just met an engineer that recently studied Kadane's algorithm.
Which any other reasonably competent programmer could do by reading Wikipedia.
And if they don't, well, that just proves how smart the interviewer is. At which point the interviewer will be sure to tell you how many people couldn't answer his trivially simple interview question.
Find a spanning tree across a graph where the edges have minimal weight. Maybe one programmer in ten thousand — and I’m being generous — has ever implemented this algorithm in production code. There are only a few highly specific vertical fields in the industry that have a use for it. Despite the fact that next to no one uses it, the question must be asked during job interviews, and you must write production-quality code without looking it up, because surely you know Kruskal’s algorithm; it’s trivial.
Question: why are manhole covers round? Answer: they’re not just round, if you live in London; they're triangular and rectangular and a bunch of other shapes. Why is your interview question broken? Why did you just crib an interview question without researching whether its internal assumption was correct? Do you think that “round manhole covers are easier to roll" is a good answer? Have you ever tried to roll an iron coin that weighs up to 300 pounds? Did you survive? Do you think that “manhole covers are circular so that they don’t fall into manholes” is a good answer? Do you know what a curve of constant width is? Do you know what a Reuleaux triangle is? Have you ever even been to London?
If the purpose of interviewing was to play stump the candidate, I’d just ask you questions from my area of specialization. “What are the windowing conditions which, during the lapping operation on a modified discrete cosine transform, guarantee that the resynthesis achieves perfect reconstruction?” The answer of course is the Princen-Bradley condition! Everyone knows that’s when your windowing function satisfies the conditions h(k)2+h(k+N)2=1 (the lapping regions of the window, squared, should sum to one) and h(k)=h(2N−1−k) (the window should be symmetric). That’s fundamental computer science. So obvious, even a child should know the answer to that one. It’s trivial. You embarrass your entire extended family with your galactic stupidity, which is so vast that its value can only be stored in a double, because a float has insufficient range:"
Author: John Byrd
Src: https://quora.com/What-is-the-harde...3 -
I seear man fucking shit php devs make it hard for people to appreciate the language.
To start, i don't think there is anything wrong with php. As a language I know damn near all of its pitfalls and have successfully deployed huge applications with minimal fuss.
The thing is...this shit seems to happen only when I AM THE MOTHERFUCKER THAT DOES IT
In any other scenario i am constantly cursing the original author under my fucking breath hoping that they choke on their own dicks. Fucking cunts.
Really man, some of the fucking code i have seen. This shit is dangerous as fuck and i can't believe that in 2019 motherfuckers would not have the decency to google for best fucking practices or learn it from a fucking book and shit.
Writing proper php code is not that fucking hard people, every fucking update to the language, every fucking tool that comes out is for the betterment of it.
Guess proper oop or functional paradigms are too complex for some dickheads. Hell, not even top to bottom procedural code.
Fuck me. Good thing is, boss is happy, the entire faculty is happy, the board is happy. Everyone is motherfucking happy.
Dez negroids better remember this shit cuz I just asked for a $20k raise.
I got a raise literally every time i ask for one so this one better make the cut.
Fuck shit php developers man. Y'all don't deserve the language, y'all make the language look bad, y'all make the community look bad.
Fuck you, die and eat a dick. Do all that shit in whatever order you prefer.15 -
Consumers ruined software development and we the developers have little to no chance of changing it.
Recently I read a great blog post by someone called Nikita, the blog post talks mostly about the lack of efficiency and waste of resources modern software has and even tho I agree with the sentiment I don't agree with some things.
First of all the way the author compares software engineering to mechanical, civil and aeroespacial engineering is flawed, why? Because they all directly impact the average consumer more than laggy chrome.
Do you know why car engines have reached such high efficiency numbers? Gas prices keep increasing, why is building a skyscraper better, cheaper and safer than before? Consumers want cheaper and safer buildings, why are airplanes so carefully engineered? Consumers want safer and cheaper flights.
Wanna know what the average software consumer wants? Shiny "beautiful" software that is either dirt ship or free and does what it needs to. The difference between our end product is that average consumers DON'T see the end product, they just experience the light, intuitive experience we are demanded to provide! It's not for nothing that the stereotype of "wizard" still exists, for the average folk magic and electricity makes their devices function and we are to blame, we did our jobs TOO well!
Don't get me wrong, I am about to become a software engineer and efficient, elegant, quality code is the second best eye candy next to a 21yo LA model. BUT dirt cheap software doesn't mean quality software, software developed in a hurry is not quality software and that's what douchebag bosses and consumers demand! They want it cheap, they want it shiny and they wanted it yesterday!
Just look at where the actual effort is going, devs focus on delivering half baked solutions on time just to "harden" the software later and I don't blame them, complete, quality, efficient solutions take time and effort and that costs money, money companies and users don't want to invest most of the time. Who gets to worry about efficiency and ms speed gains? Big ass companies where every second counts because it directly affects their bottom line.
People don't give a shit and it sucks but they forfeit the right to complain the moment they start screaming about the buttons not glaring when hovered upon rather than the 60sec bootup, actual efforts to make quality software are made on people's own time or time critical projects.
You put up a nice example with the python tweet snippet, you have a python script that runs everyday and takes 1.6 seconds, what if I told you I'll pay you 50 cents for you to translate it to Rust and it takes you 6 hours or better what if you do it for free?
The answer to that sort of questions is given every day when "enganeers" across the lake claim to make you an Uber app for 100 bucks in 5 days, people just don't care, we do and that's why developers often end up with the fancy stuff and creating startups from the ground up, they put in the effort and they are compensated for it.
I agree things will get better, things are getting better and we are working to make programs and systems more efficient (specially in the Open Source community or high end Tech companies) but unless consumers and university teachers change their mindset not much can be done about the regular folk.
For now my mother doesn't care if her Android phone takes too much time to turn on as long as it runs Candy Crush just fine. On my part I'll keep programming the best I can, optimizing the best I can for my own projects and others because that's just how I roll, but if I'm hungry I won't hesitate to give you the performance you pay for.
Source:
http://tonsky.me/blog/...13 -
Why are people complaining about debugging?
Oooh it’s so hard.
It’s so boring.
Can someone do this for me?
I honestly enjoy debugging and you should too..
if it’s not your code, you’ll get to understand the code better than the actual author. You’ll notice design improvements and that some of the code is not even needed. YOU LEARN!
If it’s your own code (I especially enjoy debugging my own code): it forces you to look at the problem from a different perspective. It makes you aware of potential other bugs your current solution might cause. Again, it makes you aware of flaws in the design. YOU LEARN!
And in either case, if it’s a tricky case, you’ll most likely stop debugging at some point, refactor the shit out of some 50-100 line methods and modulize it because the original code was undebuggable (<- made up a new word there) and continue debugging after that.
So many things I know, I know only because I spend days, sometimes even weeks debugging a piece code to find the fucking problem.
My main language is java and i wouldn’t have believed anyone who told me there’s a memory leak in my code. I mean, it’s java, right? We refactored the code and everything worked fine again. But I debugged the old version anyway and found bugs in Java (java 6.xx I believe?) which made me aware of the fact that languages have flaws as well.. GC has its flaws as well. So does docker and any other software..
Stop complaining, get on your ass and debug the shit out of your bugs instead of just writing it in a different way and being glad that it fixed the issue..
My opinion.3 -
A loooong time ago...
I've started my first serious job as a developer. I was young yet enthusiastic as well as a kind of a greenhorn. First time working in a business, working with a team full of experienced full-lowered ultra-seniors which were waiting to teach me the everything about software engineering.
Kind of.
Beside one senior which was the team lead as well there were two other devs. One of them was very experienced and a pretty nice guy, I could ask him anytime and he would sit down with me a give me advice. I've learned a lot of him.
Fast forward three months (yes, three months).
I was not that full kind of greenhorn anymore and people started to give me serious tasks. I had some experience in doing deployments and stuff from my other job as a sysadmin before so I was soon known as the "deployment guy", setting up deployments for our projects the right way and monitoring as well as executing them. But as it should be in every good team we had to share our knowledge so one can be on vacation or something and another colleague was able to do the task as well.
So now we come to the other teammate. The one I was not talking about till now. And that for a reason.
He was very nice too and had a couple of years as a dev on his CV, but...yeah...like...
When I switched some production systems to Linux he had to learn something about Linux. Everytime he encountered an error message he turned around and asked me how to fix it. Even. For. The. Simplest. Error. He. Could. Google. Up.
I mean okay, when one's new to a system it's not that easy, but when you have an error message which prints out THE SOLUTION FOR THE ERROR and he asks me how to fix it...excuse me?
This happened over 30 times.
A. Week.
Later on I had to introduce him to the deployment workflow for a project, so he could eventually deploy the staging environment and the production environment by hisself.
I introduced him. Not for 10 minutes. I explained him the whole workflow and the very main techniques and tools used for like two hours. Every then and when I stopped and asked him if he had any questions. He had'nt! Wonderful!
Haha. Oh no.
So he had to do his first production deployment. I sat by his side to monitor everything. He did well. One or two questions but he did well.
The same when he did his second prod deploy. Everythings fine.
And then. It. Frikkin. Begins.
I was working on the project, did some changes to the code. Okay, deploy it to dev, time for testing.
Hm.
Error checking out git. Okay, awkward. Got to investigate...
On the dev server were some files changed. Strange. The repo was all up to date. But these changes seemed newer because they were fixing at least one bug I was working on.
This doubles the strangeness.
I want over to my colleague's desk.
I asked him about any recent changes to the codebase.
"Yeah, there was a bug you were working on right? But the ticket was open like two days so I thought I'll fix it"
What the Heck dude, this bug was not critical at all and I had other tasks which were more important. Okay, but what about the changed files?
"Oh yeah, I could not remember the exact deployment steps (hint from the author: I wrote them down into our internal Wiki, he wrote them done by hisself when introducing him and after all it's two frikkin commands), so I uploaded them via FTP"
"Uhm... that's not how we do it buddy. We have to follow the procedure to avoid..."
"The boss said it was fine so I uploaded the changes directly to the production servers. It's so much easier via FTP and not this deployment crap, sorry to say that"
You. Did. What?
I could not resist and asked the boss about this. But this had not Effect at all, was the long-time best-buddy-schmuddy-friend of the boss colleague's father.
So in the end I sat there reverting, committing and deploying.
Yep
It's soooo much harder this deployment crap.
Years later, a long time after I quit the job and moved to another company, I get to know that the colleague now is responsible for technical project management.
Hm.
Project Management.
Karma's a bitch, right? -
what percentage of these dune hipsters haven't read a SINGLE word of any of the 6 books in the dune series (yes drooling losers, there are 6 of them)
I'm guessing > 90%
wow congrats you watched a 2 hour film, make it your entire identity 🤡
god the world has become ever decreasing cycles of cringe... they will decrease in time length until we reach unending - and therefore infinite - cringe
FullStackCircus Principle™23 -
Microsoft is always at it.
Hello, I recently discovered this eye candy of a looking website and how good the CSS looks (Kudos to whoever made this) , and I decided to post a rant of my own. And its about MS Edge and other applications.
So I built my own ATX tower a while back (Loving it) , and I found that it was WONDERFUL to have a computer that was brand new, that didnt have candy crush preinstalled on it when I got it.
Windows 10 users, do this:
Press WIN+I to open the settings menu.
Go to "Apps"
Scroll down the list....
How many applications do you see there that are actually useful , or that you have downloaded?
I never downloaded a Realtek Driver... and I never need it for anything to work. This is the case for 90% of the things you may see in the applications.
Why is HULU installed?
Why is NETFLIX installed?
Why is MINECRAFT BETA INSTALLED? THE BETA HASNT BEEN OUT IN YEARS?
But I digress, this is the case when I work on a computer such as my grandmothers who, bless her soul, isnt very adept at basic file management. Heck , she uses free Norton Antivirus against my recommendation to use the PAID active firewall application on her computer (VIPRE)
So needless to say she needs help. All the time.
So here comes microsoft recently, reinstalling like 15 different programs on her computer , including MS edge. Who else is tired of bloating? I know I am.
I recently found this program on Git!
Its the Sycnex Windows 10 DeBloater
But guess what? DONT USE IT.
Wanna know why?
Because if you do, it works, and if it works, it disables:
- Cortana (basic search engine for your OS, good luck finding candy crush).
- Microsoft Store (That means no XBOX games pass either)
- It breaks part of the file explorer
Wanna know why? BeCaUsE it geTs riD oF Ms EdGe
And believe it or not, apparently MS edges source code is Mandatory for certain functions on your computer. So even If you try to uninstall the browser, it stays behind in some form.
So there you have it. They hard coded it into windows.
Enjoy!
So its not even the author of the GITHUB programs fault, its just a real techincal limitation of the platform.
I hate that stuff man. I really do. There should be 20 things installed on my computer and thats it. Everything else is just, space for games on a solid state. Or Eclipse Photon, etc.
I would post links to show you guys a few things but. Unfortunately I cant post URLs yet!
However, thats my first rant. Hope you liked it.20 -
Welcome to post 2 of WHY WOULD I WANT TO WORK WITH YOU?, a saga of competence, empathy and me being dick, even tho I didn't want to be one.
This is a follow-up to: https://devrant.com/rants/2363374 It's title is: "Oh, you can post only every 2h. Didn't know that". I also didn't know that the rest of my rant would be put into a comment. For consistency tho, this time I am still splitting the story.
A wise person once wrote in their book: "People judge other people by two things: Empathy and competence." This may not be an accurate quote, but it carries the same message. Also, I don't really remember who was the author. I only know they were probably quite wise. Anyway, I just wanted to share that sentence. Have a moment and think about it. Or don't. Here's my story:
A was a software house that looked pretty promising. They were elegant, their page and offer looked nice. Well, unless you consider the fact that they offered me internship. Unpaid. But I decided to meet with them anyway, since I had hope that I could negotiate some sort of paid internship or a job contract even. I did my homework after all, and I was confident I am able to keep up with their requirements. I arrived a little bit... no, way to early. One damn hour. Whatever, I waited. I was greeted by a woman. We had a cultural conversation, she had a list of 12 questions I needed to answer, as a form of a test. We begun. First question: How do you change a value in Oracle Database? "Wait a minute", I thought, "What kind of question is that?". Why in seven hells would you want your frontend developer to know how to handle oracle db? Well, I gave my answer, I did lick some of that SQL in my life. Next question: Java stuff. The bloody gal didn't even care to check what position I am applying to before the interview! At this point I didn't really have very high hopes. A shame on them forever.
The story of B and C is connected and a little bit more complicated. More on that in part 2. B stands for Bank. A big corporation then, by definition. A person I know decided called me that day and told me they're hiring, that he referred me and that they would like to arrange a meeting. And so we did. It was couple of days before Christmas. C was a software house again. Or a startup. Idk really. Their website wasn't finished so I couldn't read anything useful up on them. They didn't tell me much about themselves either. They also started with "unpaid internship".
In C, they would greet me and instantly sit me down next to a mac laptop and told me, "hey, do this stuff in python". What the fuck, not again... I told them that I am frontend dev, they guy said "it's no problem, you said you know python, it's a simple task". And yeah, I did host some apps in Flask and I did use psycopg2. It was in my CV. But never, ever, have I mentioned knowing heuristics nor statistics. I'm no data scientist, monsieur. Whatever, I tried, I failed a little bit, I told them that maybe if I did want to spend half of my day there I would finish this task, but back then I was way too nervous to focus and code. I told them what should be done in code and that I just was unable to code this at the very moment. They nodded, we said goodbye and I was sure not to hear from them ever again.
In B, I was greeted by a senior frontend dev. He told me the recruiter is sick and he couldn't come, so we're talking alone. I can buy it. We sat down in said meeting room, and he asked me if I wanted a drink. No thx, I had digested so much caffeine during last 24h, next dose could be an overdose. And then, he took out my resume printed in paper. With notes on it. With some stuff encircled. That bloody bastard did his homework. We spent over an hour, just talking in friendly atmosphere. It was an interview, but it was a conversation also. We shared our experiences, opinions and it went just perfect.
On December 20, I was heading home for Christmas. My situation looked like this: A called me they could offer me only unpaid internship. I was getting kinda bored of rice and debts, tbh. I gracefully rejected their generous offer. B didn't give me feedback yet(it was a most recent interview, so I didn't expect any message until after Christmas anyway). C told me that they could give me internship, but I managed to convince them to make it paid internship. After three months of very bad times, things were starting to get better.
On part III we will explore further events of my very recent past. That post will be same amount of storytelling and possibly a lesson for those who seek an employer and for those who seek an employee.6 -
Good code is a lie imho.
When you see a project as code, there are 3 variables in most cases:
- time
- people / human resources
- rules
Every variable plays a certain role in how the code (project) evolves.
Time - two different forms: when certain parts of code are either changed in a high frequency or a very low frequency, it's a bad omen.
Too high - somehow this area seems to be relentless. Be it features, regressions or bugs - it takes usually in larger code bases 3 - 4 weeks till all code pathes were triggered.
Too low - it can be a good sign. But it should be on the radar imho. Code that never changes should be reviewed at an - depending on size of codebase - max. yearly audit. Git / VCS is very helpful here.
Why? Mostly because the chances are very high that the code was once written for a completely different requirement set. Hence the audit - check if this code still is doing the right job or if you have a ticking time bomb that needs to be defused.
People
If a project has only person working on it, it most certainly isn't verified by another person. Meaning that only one person worked on it - I'd say it's pretty bad to bad, as no discussion / review / verification was done. The author did the best he / she could do, but maybe another person would have had an better idea?
Too many people working on one thing is only bad when there are no rules ;)
Rules. There are two different kind of rules.
Styling / Organisation / Dokumentation - everything that has not much to do with coding itself. These should be enforced at a certain point, otherwise the code will become a hot glued mess noone wants to work on.
Coding itself. This is a very critical thing.
Do: Forbid things that are known to be problematic in the programming language itself. Eg. usage of variables in variables, reflection, deprecated features.
Do: Define a feature set for each language. Feature set not meaning every feature you want to use! Rather a fixed minimum version every developer must use and - in case of library / module / plugin support - which additional extras are supported.
Every extra costs. Most developers don't want to realize this... And a code base that evolves over time should have minimal dependencies. Every new version of an extra can have bugs, breakages, incompabilties and so on.
Don't: don't specify a way of coding. Most coding guidelines are horrific copy pastures from some books some smart people wrote who have no fucking clue what you're doing and why.
If you don't know how to operate on people, standing in an OR and doing what a book told you to do would end in dead person pretty sure. Same for code.
Learn from mistakes and experience, respect knowledge from other persons, but always reflect on wether this makes sense at this specific area of code.
There are very few things which are applicable to a large codebase on a global level. Even DRY / SOLID and what ever you can come up with can be at a certain point completely wrong.
Good code is a lie - because it can only exist at a certain point of time.
A codebase should be a living thing - when certain parts rot, other parts will be affected too.
The reason for the length of the comment was to give some hints on what my principles are that code stays in an "okayish" state, but good is a very rare state