Details
-
AboutJr Software Developer, CS student
-
SkillsC#, C++, Java, Full-stack
Joined devRant on 1/26/2018
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
-
*In GitHub*
Manager: "Team, we've not made any changes in UI recently.. we've to do something".
UI: "Let's switch right pane to left."
Public: "Wow.."2 -
We have a company policy of “you kill it you fill it.” We get free coffee here, it’s nice, I’m happy - but notoriously I’m the only one filling it for the whole company!! So I did the unspeakable today...
Fill the damn coffee. Thanks.6 -
In your opinion what is the best programming rant to ever grace the internet?
My submission === programming sucks:
http://stilldinking.org/programming...
(small) excerpt: "You discover that one day, some idiot decided that since another idiot decided that 1/0 should equal infinity, they could just use that as a shorthand for “Infinity” when simplifying their code. Then a non-idiot rightly decided that this was idiotic, which is what the original idiot should have decided, but since he didn’t, the non-idiot decided to be a dick and make this a failing error in his new compiler. Then he decided he wasn’t going to tell anyone that this was an error, because he’s a dick, and now all your snowflakes are urine and you can’t even find the cat."7 -
Why do people put their "TL;DR" at the end of the freaking long text. Put it on top for God's sake.5
-
[...] we should never ignore any part of code. The parts we ignore are where the bugs will hide.
- Uncle Bob1 -
Beware of scope creep. If it's a bug, fix it for free. If it's a new feature or changed from the original signed off scope, charge for it.1
-
*Never* do CSS tweaks over the phone and tell the customer to refresh and approve the change. This will lead to endless tweaking andlong calls at any hour, and further trivializes your work by making it look like everything can be done instantly. Better to have them send you the changes they want, then send them an update later once they have been done—perhaps with a bit of a delay to further stave off the sense of instant gratification.
Also, if they keep requesting changes to changes after you’ve done what they asked, be prepared to let them know that future changes will incur an additional fee. -
The sooner you start coding, the longer it will take.
This was meant as a way to tell us all the slow down and plan first. If you go right into coding things before the structure is thought out you will end up with garbage code.4 -
- Premature optimization is bad and wastes your time
- You need to see the big picture
- Always add extra hours to your estimates
- Test your feature like a QA engineer; look for the edge cases2 -
Actual pro tip: don't push only when you are done with code. Always push when you are done with coding session. Minimize the possibility of data loss and always have your code on the server.8