Details
-
AboutI'm a dev.
-
SkillsC++, HTML, CSS, PHP
Joined devRant on 8/26/2019
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
-
Just had a talk with my manager who wanted to know why I removed a feature from an application we had. This removal had been discussed WITH THE MANAGER several months prior, but apparently they hadn't written a little note or anything down about it.
I told them we had discussed it earlier. They didn't believe me. They checked the project technical specifications that said it _should still be there_. I told them we talked about it previously. They told me to prove it, so I go looking through the commit history.
Lo and behold:
- Commit <hash> authored 4 months ago.
- Update to specifications, asked for by <manager>
Eat it.2 -
Mobile app dev here 🙋♂️
Guy at work asking me why his phone feels heavier then mine (we have the same phones)
I just told him that his phone gets heavier with every apps he installs.
1 week later he meets me outside the office and tells me he deleted a lot of apps and his phone is actually lighter know.
Sometimes I just want to cry 😂😂😂12 -
So I recently started going to a university, and I am being taught C. I have previously learnt C++ in school so its all pretty easy for me compared to those who are programming for the first time.
So, one of my classmates run into a problem with their code so he asks to check where he went wrong. So, the teacher comes and checks his code and then concluded that the compiler is F****** broken!! And i am like FFS theres a missing semi-colon, even the compiler pointed it out....just because you couldn't figure out the problem doesn't mean the compiler is broken.7 -
To all developers who think "I don't need to delete that one 1KB temp file"
FUCK.YOU.
You are not the only garbage developer who does not clean his shit up. The reason we need TERA FUCKING BYTE storage devices nowadays is because you incompetent shit heads have no idea how an application has to properly work. A temp file is not there to exist for ever. HENCE THE FUCKING WORD TEMPORARY20 -
What devrant taught me:
Everyone hates java
Everyone hates php
Everyone hates spaces
Everyone hates tabs
Everyone hates vim
Everyone hates windows
Everyone hates linux
Everyone hates clients
Everyone hates PMs
Everyone hates every language they're not working with
Everyone loves devrant 😊36 -
Website design philosophies:
Apple: "...and a really big picture there, and a really big picture there, and a really big picture there, and..."
Microsoft: "border-radius:0 !important;"
Google: "EVERYTHING MOVES!!! And most websites get material design. Most."
Amazon: "We're slowly moving away from 2009"
Wix: "How can we further increase load times?"
Literally any download site: "Click here! No, click here! Nononono!! Click here!!..."
Facebook: "We can't change anything because our main age demographic is around 55"
University websites: "That information isn't hard enough to find yet. Decrease the search accuracy and increase broken links."32 -
Have you ever wondered we programmers have so many strong communities.... Stackoverflow, devRant, Reditt, etc...
No other profession has such communities... Why? Why?
Because, we haven't built one for them.... 😂😁61 -
!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 -
Fucking intern.
While I was working next to her a couple weeks back, she spent half her time on social media, playing Candy Crush, or talking with her friend. She also left early almost every day.
I had given her a project to do (object crud + ui), and helped her through it. She made pretty abysmal progress in a week. I ended up finishing it for her by rewriting basically all of her code (every single line except some function names, lone `end` or `}` statements, a few var declarations, blank lines, plus a couple of comments she copied over from my code).
This week I gave her a super easy project to do. It amounts to copying four files (which I listed), rename a few things to be Y instead of X, and insert two lines of code (which I provided) to hook it up. Everything after that just works. It should have taken her ... okay, maybe a few hours because she's slow and new to the language. but it would have taken me five to ten minutes, plus five minutes of testing.
She has spent THREE FUCKING DAYS ON THIS AND SHE'S STILL NOT DONE. SHE'S BLOODY USELESS!
She has kept not pulling changes and complaining that things are broken. Despite me telling her every time I push changes that affect her work (on. my. branch. ergh!)
She keeps not reading or not understanding even the simplest of things. I feel like MojoJojo every time I talk to her because of how often I repeat myself and say the same things again and again.
Now she's extremely confused about migrations. She keeps trying to revert a drop_table migration that she just wrote so she can re-create the table differently. Instead of, you know, just reverting back to her migration that creates the table. it's one migration further.
Migrations are bloody simple. they're one-step changes to the database, run in order. if you want to make a change to something you did a few steps back, you roll back those migrations, edit your shit, and run them again. so bloody difficult!
`rails db:rollback && rails db:rollback`
Edit file
`rails db:migrate`
So. hard.
I explained this to her very simply, gave her the commands to copy/paste, ... and she still can't figure it out. She's fucking useless.
It took me ten minutes to walk her though it on a screen share. TEN FREAKING MINUTES.
She hasn't finished a damned fucking thing in three weeks. She's also taking interview calls while working on this, so I know she totally doesn't care.
... Just.
Fucking hell.
USELESS FUCKING PEOPLE!35 -
Once I was totally exhausted and fatigued doing code...
Then i had cappuccino....
The next thing i saw was my complete project.3