Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Shared screen with a client over Skype. Showed them in Postman that their API wasn't working as expected. It was expecting a json. Instead it was giving error code 400 instead of 200.
"Error: No error. All OK"
I'll never forget the words of the client:
"Don't use all this fancy software, you don't know how to call APIs, open Internet Explorer or chrome and paste it in the bar. You'll see All OK, means all is okay."
*insert you dense mf meme here*20
Had a conference call for a fairly large internal project today. Everyone involved was there. Turns out the other subteams had done jack shit. Blablabla drafts and concepts bla, yeah right.
Then someone had the idea we needed an e-mail distribution list. But what's it gonna be called?
Suddenly *everyone* had an opinion and wanted their name used. And, in true "design by committee" fashion, everyone's ideas got merged.
Our list's name is now 30. fucking. characters. long. FUCK. you.
Luckily, I can leave the project this month. Can't wait...
I'm the biggest dumbass, the laziest procrastinator I know of..
Joined devRant in June 2017, got eligible for the stickers in a week's time, sent a mail requesting them, but never received it. Given the size of our community, I thought I'm way behind in the list and probably receive them in few months. After a year, I totally forgot about it.
But, the colossal stupid that I am, had also lost the key to my mailbox (the physical one). I never cared about the lost key, because who sends post these days !!!
When I finally got a duplicate key for my mailbox after 2 years, guess what I found.. a first class international mail from devRant which arrived on July 2017 🤦♂️🤦♂️🤦♂️, couple of weeks after I originally requested
But, yay... I finally got them..18
My girlfriend is amazing:
After a long uphill battle trying to finish a huge open source project I started months ago. She noticed I was getting a little deflated.
So she donated a small amount to the donation page to lift my spirits.
She wanted to do it secretly but didn't know that it wasnt anonymous.
The little things spur us on.41
Talk with a co-worker who has a bit of a motivational problem.
Him: if I had more fun, I would be more productive.
Me: you're not here for fun, that's why they pay us.
Him: how are you motivated?
Me: by money.
A bit later.
Him: do you plan for retirement some day?
Me: no. By then, there won't be retirement anymore. We will eat fried rats in the street.
He starts understanding why I'm wearing black metal shirts.10
Ran into a girl who I had a crush on in high school at a bar last week. Hanged out for a bit, but then I had to run catch the last train home.
Today I get a message from her that reads: "Hey, it was nice to meet you last week. Can I call you some time, there's something I want to tell you. 😉"
I think to myself -- sweet and say that I have no meetings today, call me whenever you can.
A couple of minutes later she calls me, and the first thing she says: "I have this app idea..."
fuck, shouldn't have hyped myself up.34
Last year I built the platform 'Tindex'. It was an index of Tinder profiles so people could search by name, gender and age.
We scraped the Tinder profiles through a Tinder API which was discontinued not long ago, but weird enough it was still intact and one of my friends who was also working on it found out how to get api keys (somewhere in network tab at Tinder Online).
Except name, gender and age we also got 3 distances so we could calculate each users' location, then save the location each 15 minutes and put the coordinates on a map so users of Tindex could easily see the current location of a specific Tinder user.
Fun note: we also got the Spotify data of each Tinder user, so we could actually know on which time and which location a user listened to a specific Spotify track.
Later on we started building it out: A chatbot which connected to Tinder so Tindex users could automatically send a pick up line to their new matches (Was kinda buggy, sometimes it sent 3 pick up lines at ones).
Right when we started building a revenue model we stopped the entire project because a friend of ours had found out that we basically violated almost all terms.
Was a great project, learned a lot from it and actually had me thinking twice or more about online dating platforms.
Below an image of the user overview design I prototyped. The data is mock-data.51
Feels pretty good when you chroot into your first LFS enviornment and nothing breaks (yet..). Also my toolchain seems to be compiling packages correctly so that's a plus :)
Boss: You'll need to make the presentation an hour earlier than usual. There'll be 20 people attending..
Me: Sure. Will everyone show up?
Boss: Oh yes, they'll show up.
*Reschedules other work at home*
*Gets 4 hours of sleep to wake up earlier*
*Shows up for the meeting 5 minutes earlier*
There literally wasn't a single person there. Everyone shows up at the normal fucking time and good old boss was 2 fucking hours late.
Guess what the presentation was for? To solve the fucking issue of why stuff never gets done on time and nothing works right. I think I might have a tiny fucking idea why, at this point.12
- Sure! What do you need?
Oh, it’s very simple, I just want to make a static webpage that shows a clock with the real time.
- Wait, why static? Why not dynamic?
I don’t know, I guess it’ll be easier.
- Well, maybe, but that’s boring, and if that’s boring you are not going to put in time, and if you’re not going to put in time, it’s going to be harder; so it’s better to start with something harder in order to make it easier.
You know that doesn’t make sense right?
Okay, so I want to parse this date first to make the clock be universal for all the regions.
- You’re not going to do that by yourself right? You know what they say, don’t repeat yourself!
But it’s just two lines.
- Don’t reinvent the wheel!
- One component per file!
- It happens, and you’ll get lost managing your files as well. You should use Webpack or Browserify for managing your modules.
- Yes, but some people still have previous versions of ECMAScript, so it wouldn’t be compatible.
Why is it called ECMAScript then?
- It’s called both ways. Anyways, after you install Webpack to manage your modules, you still need a module and dependency manager, such as bower, or node package manager or yarn.
What does that have to do with my page?
- So you can install AngularJS.
Oh, that’s great, so if I modify one sentence on a part of the page, it will automatically refresh the other part of the page which is related to the first one and viceversa?
- Exactly! Except two way data binding is not recommended, since you don’t want child components to edit the parent components of your app.
Then why make two way data binding in the first place?
- It’s backed up by Google. You just don’t get it do you?
I have installed AngularJS now, but it seems I have to redefine something called a... directive?
- AngularJS is old now, you should start using Angular, aka Angular 2.
But it’s the same name... wtf! Only 3 minutes have passed since we started talking, how are they in Angular 2 already?
- You mean 3.
Okay, I now know Angular 6.0, and use a component based architecture using only a one way data binding, I have read and started using the Design Patterns already described to solve my problem without reinventing the wheel using libraries such as lodash and D3 for a world map visualization of my clock as well as moment to parse the dates correctly. I also used ECMAScript 6 with Babel to secure backwards compatibility.
- That’s good.
- But did you use TypeScript?37
Mac: Suddenly turns off
Me: Fuck my code..F***
Mac: No response at all
Me: reset SMC etc etc
Mac: I am dead (no battery detection, dies after 10 min on power adaptor)
Me: Skips a heart beat..(Git, oh yea git)
**Takes Mac to store, After diagnosis**
Apple Freaking Genius (AG): Your Mac has a mother board problem it needs to be replaced.
Me: Hmm what is the problem exactly??
AG: Issues in logic board and some other components.
Me: How much?
AG: Out of warranty so $$$ (60% of original amount)
Me: (wtf?) Really
AG: It's entire motherboard replacement .. bla bla
**Bring it home > open > everything seems ok on multimeter as per circuit diagram > finally finds a voltage drop that is not consistent > minute short circuit > remove > check further > nothing else > reassemble > hit power button > starts fine > freaking battery detected > works fine**
0 $ repair
Fixes two more devices @ 0 $ in friend circle
Builds a raspberry pi backup laptop with 3d printed body..Ubuntu.. you know can't live without a computer
Okay, story time.
This rant is about the many mistakes I made at the time, specifically the biggest – but not the first – of which: publishing some preliminary results very early on.
So I posted a sarcastic question to the Software Engineering Stack Exchange, which was originally worded differently to reflect my frustration, but was later edited by mods to be more serious.
You can see the responses for yourself here: https://goo.gl/poHKpK
Most of the serious answers were along the lines of "multithreading is hard". The top voted response started with this statement: "1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is."
While I'll admit that my presentation was initially lacking, I later made an entire page to explain the synchronisation mechanism in place, and you can read more about it here, if you're interested:
But what really shocked me was that I had never understood the mindset that all the naysayers adopted until I read that response.
Because the bottom-line of that entire response is an argument: an argument against change.
Nexus does not and will not hold your hand. It will not repeat Node's mistakes and give you nice ways to shoot yourself in the foot later, like `process.on('uncaughtException', ...)` for a catch-all global error handling solution.
No, an uncaught exception will be dealt with like any other self-respecting language: by not ignoring the problem and pretending it doesn't exist. If you write bad code, your program will crash, and you can't rectify a bug in your code by ignoring its presence entirely and using duct tape to scrape something together.
Back on the topic of multithreading, though. Multithreading is known to be hard, that's true. But how do you deal with a difficult solution? You simplify it and break it down, not just disregard it completely; because multithreading has its great advantages, too.
Like, how about we talk performance?
How about distributed algorithms that don't waste 40% of their computing power on agent communication and pointless overhead (like the serialisation/deserialisation of messages across the execution boundary for every single call)?
How about vertical scaling without forking the entire address space (and thus multiplying your application's memory consumption by the number of cores you wish to use)?
Some will say that the performance gains aren't worth the risk. That the possibility of race conditions and deadlocks aren't worth it.
That's the point of cooperative multithreading. It is a way to smartly work around these issues.
If you use promises, they will execute in parallel, to the best of the scheduler's abilities, and if you chain them then they will run consecutively as planned according to their dependency graph.
If your code doesn't access global variables or shared closure variables, or your promises only deal with their provided inputs without side-effects, then no contention will *ever* occur.
If you only read and never modify globals, no contention will ever occur.
Are you seeing the same trend I'm seeing?
When someone says we shouldn't use multithreading because it's hard, do you know what I like to say to that?
"To multithread, you need a pair."18
Classes are classist.
Objects are objectifying.
Race conditions are racist.
Foreign keys are xenophobic.
Functions are ableist.
Thin clients are weightist.
Bitmasks perpetuate heteronormativity.
Code beautifiers promote unrealistic beauty expectations.
Test-driven development is victim blaming.
Forced commit pushes are rape.
Motherboards perpetuate gender roles.
And don't get me started on white space.9
Me: *Puts on headphones*
5 minutes later
College: Hey man you busy?
Me: *Takes off headphones*
Me: I am, but what's the issue?
Help him, Put headphones back on.
5 minutes later
Intern: I need help
Me: *Takes off headphones*
Me: Fine, I've got time
Help her, Put headphones back on.
Beginning to feel a little pissed.
5 minutes later
PM: Can i get your help quickly?
Me: Can i finish this quickly?
PM: It won't take long
Me: *Takes off headphones*
Help her out, put headphones back on.
An hour later
Team Leader: Are you done yet?
Me: *Takes off headphones*
Team Leader: How can you not be done yet?
Me: Ask everyone around you?
He bitches for about 30 minutes.
I decide not to put my headphones on and just float in the river of how pissed i am.
4 Fucken hours goes by, nobody wants jack shit.
Me: *Puts headphones on*
5 minutes later
Team Leader: Hey man can you help me out?
Me: *Takes off headphones*
Me: Sure Fine.
FUCK!!! EVERY! FUCKEN TIME!!!30
WTF Python!!! "Master" and "Slave" perfectly convey the concept. In the English language many words have different meanings based on their context. It's plainly obvious that no allusion to human slavery is meant in the context of software or hardware module relationships. I don't even think it is problematic. The real problem seems to be the people who are taking terms outside their intended space. Why are we linking a scar on human history to terminologies explaining technical relationships?
Then lets also ban 0 and 1 because it can offends non-binary peoples!22
Some empty-headed helpdesk girl skipped into our office yesterday afternoon, despite the big scary warning signs glued to the door.
"Hey, when I log in on my phone, the menu is looking weird"
"Uh... look at my beard"
"Just look at this beard!"
"Does this look like a perfectly groomed beard"
"Uh... it's pretty nice I guess"
"You don't have to lie"
She looks puzzled: "OK... maybe it could use a little trimming. Uh... a lot of trimming". "I still like it though" she adds, trying hard to be polite.
"I understand you just started working here. But the beard... the beard should make it clear. See the office opposite to this one?"
"Perfectly groomed ginger beards. It's all stylish shawls and smiles and spinach smoothies. Those people are known as frontend developers, they care about pixels and menus. Now look at my beard. It is dark and wild, it has some gray stress hairs, and if you take a deep breath it smells like dust and cognac mixed with the tears caused by failed deploys. Nothing personal, but I don't give a fuck what a menu looks like on your phone."
She looked around, and noticed the other 2 tired looking guys with unshaven hobo chins. To her credit, she pointed at the woman in the corner: "What about her, she doesn't seem to have a beard"
Yulia, 1.9m long muscled database admin from Ukraine, lets out a heavy sigh. "I do not know you well enough yet to show you where I grow my unkempt graying hairs... . Now get lost divchyna."
Helpdesk girl leaves the scene.
Joanna, machine learning dev, walks in: "I saw a confused blonde lost in the hallway, did you give her the beard speech?"
"Yeah" -- couldn't hold back a giggle -- "haha now she'll come to you"
Joanna: "No I already took care of it"
"She started about some stupid menu, so I just told her to smell my cup". Joanna, functional alcoholic, is holding her 4pm Irish coffee. "I think this living up to our stereotype tactic is working, because the girl laughed and nodded like she understood, and ran off to the design department"
Me: "I do miss shaving though"70
0. Plan before you code. Document everything. You won't remember either your idea or those clever implementations next week (or next month, or next year...).
1. Don't hack your way through, unless that's what you intend to do. Name your variables, functions etc. neatly: autocomplete exists!
Protip: Sometimes you want to check a quick language feature or a piece of code from one of your modules. Resist the urge to quickly hack in the test into your actual project. Maintain a separate file where you can quickly type in and check what you're looking for without hacking on your project (For example, in Python, you can open a new terminal or IDLE window for those quick tests).
2. Keep a quiet environment where you can focus. Recommend listening to something while coding (my latest fad is on asoftmurmur.com). Don't let anything distract you and throw your contextual awareness out of whack.
3. Rubber ducks work. Really. Talking out a complex piece of logic, or that regex or SQL query aids your mind greatly in grasping the concept and clearing the idea. Bounce off code and ideas with a friend or colleague to catch errors and oversights faster. Read more here: https://en.wikipedia.org/wiki/...
4. Since everyone else is saying this (and because it merits saying), USE VERSION CONTROL. Singular most important thing to software development aside from planning and documenting.
5. Remember to flout all of the above once in a while and just make a mess of a project where you have fun throwing everything around all over the place. You'll make mistakes that you never thought were possible by someone of your caliber :) That's how you learn.
Have fun, keep learning!3
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!197