Details
Joined devRant on 8/13/2016
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
-
Boss: “Do you think you can work on Saturday? We really need the help.”
Me: “Yes, of course.”
Boss: “Great, thank you.”
Me: “I’ll probably be late, though, as public transport is slow on the weekends.”
Boss: “Okay, when do you think you will be at the office?”
Me: “Monday”.17 -
Spent 1 hour 30 minutes trying to figure out why the Laptop's WIFI connection was not working on Ubuntu.
Realized it had a LAN plugged in connected to my desktop.
Pull my hair one by one please.
Shouldn't linux be intelligent enough to use the network adapter which has internet access?5 -
If programmers were doctors.
Doctor A: the patient is having heart attack
Doctor B: we have to reproduce the heart attack to be able to heal him
Doctor C: why dont we just remove the hesrt and install a new heart
Doctor D: human heart are bad, maybe we should use animal heart21 -
Fuck You blue car driver who is texting and just cut in front of me! I accidentally double tapped the wrong rant!4
-
This code review gave me eye cancer.
So, first of all, let me apologize to anyone impacted by eye cancer, if that really is a thing... because that sounds absolutely horrible. But, believe me, this code was absolutely horrible, too.
I was asked to code review another team's script. I don't like reviewing code from other teams, as I'm pretty "intense" and a nit-picker -- my own team knows and expects this, but I tend to really piss off other people who don't expect my level of input on "what I really think" about their code...
So, I get this script to review. It's over 200 lines of bash (so right away, it's fair game for a boilerplate "this should be re-written in python" or similar reply)... but I dive in to see what they sent.
My eyes.
My eyes.
MY EYES.
So, I certainly cannot violate IP rules and post any of the actual code here (be thankful - be very thankful), but let me just say, I think it may be the worst code I've ever seen. And I've been coding and code-reviewing for upwards of 30 years now. And I've seen a LOT of bad code...
I imagine the author of this script was a rebellious teenager who found the google shell scripting style guide and screamed "YOU'RE NOT MY REAL DAD!" at it and then set out to flagrantly violate every single rule and suggestion in the most dramatic ways possible.
Then they found every other style guide they could, and violated all THOSE rules, too. Just because they were there.
Within the same script... within the SAME CODE BLOCK... 2-space indentation... 4-space indentation... 8-space indentation... TAB indentation... and (just to be complete) NO indentation (entire blocks of code within another function of conditional block, all left-justified, no indentation at all).
lowercase variable/function names, UPPERCASE names, underscore_separated_names, CamelCase names, and every permutation of those as well.
Comments? Not a single one to be found, aside from a 4-line stanza at the top, containing a brief description of that the script did and (to their shame), the name of the author. There were, however, ENTIRE BLOCKS of code commented out.
[ In the examples below, I've replaced indentation spacing with '-', as I couldn't get devrant to format the indentation in a way to suitably share my pain otherwise... ]
Within just a few lines of one another, functions defined as...
function somefunction {
----stuff
}
Another_Function() {
------------stuff
}
There were conditionals blocks in various forms, indentation be damned...
if [ ... ]; then
--stuff
fi
if [ ... ]
--then
----some_stuff
fi
if [ ... ]
then
----something
something_else
--another_thing
fi
And brilliantly un-reachable code blocks, like:
if [ -z "$SOME_VAR" ]; then
--SOME_VAR="blah"
fi
if [ -z "$SOME_VAR" ]
----then
----SOME_VAR="foo"
fi
if [ -z "$SOME_VAR" ]
--then
--echo "SOME_VAR must be set"
fi
Do you remember the classic "demo" programs people used to distribute (like back in the 90s) -- where the program had no real purpose other than to demonstrate various graphics, just for the sake of demonstrating graphics techniques? Or some of those really bad photo slideshows, were the person making the slideshow used EVERY transition possible (slide, wipe, cross-fade, shapes, spins, on and on)? All just for the sake of "showing off" what they could do with the software? I honestly felt like I was looking at some kind of perverse shell-script demo, where the author was trying to use every possible style or obscure syntax possible, just to do it.
But this was PRODUCTION CODE.
There was absolutely no consistency, even within 1-2 adjacent lines. There is no way to maintain this. It's nearly impossible even understand what it's trying to do. It was just pure insanity. Lines and lines of insanity.
I picture the author of this code as some sort of hybrid hipster-artist-goth-mental-patient, chain-smoking clove cigarettes in their office, flinging their own poo at their monitor, frothing at the mouth and screaming "I CODE MY TRUTH! THIS CODE IS MY ART! IT WILL NOT CONFORM TO YOUR WORLDLY STANDARDS!"
I gave up after the first 100 lines.
Gave up.
I washed my eyes out with bleach.
Then I contacted my HR hotline to see if our medical insurance covers eye cancer.32 -
Screw Emojis!!
Client asks how many days will it take to implement feature XYZ.
I say 3 days. But Skype had other plans.23 -
At my company we need to change our passwords every month and every month I add a an extra exclamation mark at the end of my password. Now after 5 years there is an unbearable amount of exclamation marks so I tried to change my my password to 'beefstew'.
Apparently it wasn't stroganoff.9 -
Worst experience was my first job after study. They told me at the interview that the job has very low travel activity... "we are doing most of the projects in-house...just traveling to the customer now and then for kick offs or when the software has to be trained"
A half year later I had to travel every fucking week to the customer. Fixing shitty code from a freelancer who never worked in a team, in a language I've never used before (they told me the first day at the customer). Don't get me wrong, I love learning new stuff but this project and architecture was a totally fucked up mess. Flew every monday to the customer (had to get up at 4am monday morning to get the flight) and friday back. Quit the job after living 3 months from a fucking suitcase. -
My last night:
- Had nothing much to work on.
- Opened a porn site to spend sometime.
- Clicked on some really good video.
- Realized full screen isn't working on the page.
- Fired up JS console, spent the next 30 minutes trying to get the video part full screen. Failed!
- Opened up Google & navigated through stackoverflow looking for the fix. Still couldn't do it.
- Cursed the website for having a bad design.
- Left the site.
Bad UI = No Fuck.23 -
Got a job offer. Pays more than my current job (~13% increase) and allows me to commute. However, less freedoms. This is weird to me - the job is for a small firm (20 employees), and my current is huge (~25-30k). Now I can work from home when I need it, and flexible hours (aka, get in whenever I feel like it). New job had in contract "No remote working" and "Work hours are 0800-1600".
Think I'm gonna turn em down.. Fuck being locked down like that, honestly.15 -
This awkward moment when you go:
- Who the fuck wrote that shit?
And the other side of room whispers:
- You did...4 -
Today's my lucky day for job rejections...
"Unfortunately we have decided not to proceed with you as a candidate because the salary range you expect lies outside our budget."
That's very interesting indeed because in the very first interview (phone call) you asked me about that range and I gave it, straight and simple.
Then I had to do a coding challenge, which I usually refuse, but did anyway. It took about 15 hours. Let's not forget that it had nothing to do with the job I was applying for, but OK.
After that, a second interview, which took 1.5 hours and a third, which gobbled up 2 hours of my time.
Then you tell me that you're not willing to fork over the dosh, after having wasted 18.5 hours of my time!
Thank you very much, you anus blossoms!9 -
!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 -
College/university: gets a FAIL for plagiarising stack overflow. Serious offence
Working full time: gets PAID to plagiarise stack overflow. Everyday routine.11