Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuckBuy Now
Search - "hardcoding"
I plan to write a book about my previous company because I had such a magical experience in that fairy land. I spent three years with indigenous tribes out of touch from the modern human civilization. They take pride in their culture and their use of MS Excel and SVN technologies.
Over the years, these tribes discovered how to organize a queuing system through Skype group chats. If a tribe member wants to update the spreadsheet, they will enter their name in the group chat until it forms a queue (name1 > name2 and so on..) and once they're done, they enter "Done" in the group chat.
It's amazing how these tribes came up with such an efficient and systematic approach of wasting their lives! Researchers are baffled with this newly uncovered secret that some of them believe it could be the work of an advanced alien civilization. There's just no way humans could have thought of that.
These tribes have a lot to teach us. Hell, I know it taught me some knowledge I wouldn't otherwise find in the modern world. During my stay there, I learned the following:
1. Why hell is good after all.
2. How to fake a coma.
3. How to recover from a stroke in 5 minutes.
4. The art of astral projection during a meeting.
5. Is that a subliminal message or are you passive aggressive?
6. What clients want = anal fisting.
7. How to stealthily check your pulse when talking to someone really stupid.
8. "Sent emails will be received" - a tribe member.
9. Hardcoding a dollar sign + shell command to make it work.
10. How to make a scrum meeting last for two hours.
11. How to collect bus tickets like a peasant for transportation reimbursement.
12. What's that smell and why does he keep sniffing it? A colleague's expired lunch.
13. Why it's wrong to confront a colleague who's always three hours late.
14. How to play Nintendo Switch in two big screens and a projector in the boardroom with glass walls.
15. Pretending this life is virtual reality.
16. Why you're not in GTA and running everyone over with your car is bad.
17. Vivisection for dummies.
18. Summoning the devil for entertainment.
19. Devil worship during working sessions.
20. The kama sutra of assasination.
21. How to speed up the dying process.
22. Is it a stiff client or rigor mortis?
23. How to control your laughter when someone is crying.
24. How to control your laughter when someone just died.
25. Your manager is not a pocket pussy, stop it.
26. Why some clients don't die of old age.
27. Easy occult symbols for your bullet journal.
28. How to insert subliminal messages for mass suicide in your members' Trello boards.
29. 82 handy methods of torture.
30. Can you get a maternity and paternity leave at the same time if you're a single parent?
31. How to reason with your inner demons.
32. That laptop costs too much to break it on someone's face.
33. Masturbation while working from home.
34. "Honesty system" = We don't have the resources to automate this.
35. How to get reincarnated as a cockroach.
36. That creature with a tiny voice is human too. Yep, she's a team member.
37. Why does that Hodor look-alike keep touching you?
38. Gee. That IT bitch's face is shaped like a half moon.
39. How to program by clicking buttons.
40. Does your manager count as a human sacrifice?
41. How to encourage your colleagues to sacrifice a Chinese co-worker to an active volcano on their outing.
42. Playing porn in a colleague's wireless bluetooth speaker.
43. Tinder swiping during meetings.
44. Using a ticket management system in the dev environment.
45. How to estimate and then change that estimate later on to fit your actual hours.
46. How to shoot down that ungrateful fuck.
47. How to dissolve your team after you've disappeared.
48. How to tell if you're actually dead.
49. How to plan a massacre for some mental stimulation.
50. Eating with a one liter bottle of muriatic acid on your desk and convincing your colleagues that it burns fat and they should try mixing it with their coffee.
And so much more. My heart is still heavy from all these wonderful experiences that I decided to write a book about it. The world should know about this.16
In fact I'm a sinful dev, so that I can't easily decide which one is worst. From indenting with tabs, or using nano instead of vim/emacs, to hardcoding database credentials on server, to many hacks and workarounds I use as actual "fixes" when the deadline is upon me and I've tried all I could. But it always led only to my own regret. For instance, my latest sin was that I prefered Debian over Arch and used proprietary graphic drivers to speed up my new setup. But ended up with a curse from St. Ignucius. (check my last rant)
But my worst sin probably goes to when I was "printf-debugging" some issue for a GSM controller on a raspberry pi. I forgot to remove one little print line and deployed the new "fixed" version. I didn't follow that project after that for like a month or so, when the client posted back the device and said that "it just doesn't work anymore". It seemed that raspbian didn't boot beacause the sd card was curroptted. I dd'ed through the card and I noticed that there are billions of lines of "DEBUG:: reading stream from 192.some.shitty.ip", took almost all over the 32G sdcard. Just as I suddenly remembered the cursed line I just added a month ago, I declared the sd card dead with no hesitation, dunce-commented the line (so the history would remember), implemented a time out for the thread containing it, setup a journald unit for my service and removed the redirection of process output to a log file, found a new sd card and installed everything again, and finally posted back the new "fix" to the client.
Moral: Never comfort yourself for the sins you have commited in the past kids, they certainly will come back to you. And also not to do any io especially write to a file on an SD card with ext fs, in a potentially infinite loop with no timeout.
P.S: I'd posted my last rant just before the new week rant last nigh. I really liked the St. Ignucius meme so decided to create a new one. He's very adorable :)3
Colleague: We need to deliver it today so let's hardcode some values in the code to make it work
Me: Ok you do it. I don't even want to see it!3
Got in trouble yesterday for deploying to a QA environment and NOT sudo vimming a file to change the hardcoded email recipient... Maybe, the dev who wrote that file should use our configuration files instead of hardcoding it!
I found out the importance of time complexity. It might not seem like a big difference between O(1) and O(2). But there's a big difference hardcoding 500 lines and 1000 lines of data.
I made a navigation app for school using dijkstra's algo. However it had no data available so I had to hardcode it. Long story short, there was a ton of hardcoding. Always try to improve the time complexity of the code you write.2
I wasn't happy with one of our UI views for editing a database query that consisted of about 50 fields ("editing" being the operative term here, not just viewing. It had to be two-way). Everything was hardcoded and defined manually, with each block of ~10 lines being repeated and mostly identical apart from the occasional double inline field and name of the variable. It had "just ended up that way" over time due to the variable names in the UI being different than the names of the variables that came from the API.
I decided to overhaul it all where I defined the different input components and which fields should be included, then made a function which would generate the page based on these definitions. It was about 500 lines of modularized functions and classes where the class for the actual view was about 50 lines- compared to the 1400+ lines of the previous version.
But, it didn't work. It should, but it "just didn't". There was no error. All I got was a blank, solid white page. I could make a drastic change or try something completely different and I would get the same error, same blank page. API fetch succeeded, value assignments succeeded, the object exists, but if you iterated it it was... empty.
I started getting really discouraged that I had made it too abstract. Maybe I actually made it more complex and unreadable than before. Maybe just hardcoding it all was the better solution after all. Maybe I had gone against KISS and overdesigned it.
I was up pretty late and everyone had gone home. When the last guy left there was that mood where "yeah if I can't make this work we'll just use the current version...".
Turns out I had tried iterating over a property of the set of fields to render, rather than the entire collection. In the old method the variables were a member of an object, but now they were its own object, a change I had made to isolate the set of values which were to be viewed/edited and make them easier to pass back and forth. This member existed since I hadn't cleaned it out yet, but it was empty.
I had been banging my head against this for a whole day and I was ready to admit I had made a mistake and wasted my time before discarding it all, but then I backspaced this one property and the interface went from empty to rendering perfectly and with all functionality intact. I swear god rays were coming out of my screen.
So I got into this project weeks before golive. Client did full scale testing and opened floodgates to hardcoding did by the 3rd party guys. Fixed more than 30 issues manually. Weeks later found out a better way to scan everything via notepad++. Lol
hello folks, any help would appreciated :). serious question about designing/developing a rest backend.
here is a little insight: I want to reduce the endpoints for many CRUD operations as I can. So for that approach I defined a set of "dynamic" routes like /:moduleName/list, /:moduleName/update and so on.
Now I want to also reduce hardcoding as much stuff as I can for the front end. like I want forms/view/components to know which fields can be sent in the "/:moduleName/xxx" endpoints from above. So I'm thinking to make some /:moduleName/list/map, /:moduleName/update/map endpoints that tells the frontend which fields/keys can be sent for X or Y operation.
regarding design/security concerns Is that a good approach? do you know any other approach that's like to what I want to achieve?6
I want to ask for your opinion guys, because I don't know if I am right or wrong.
So, some days ago, my brother sent me some code to check out for an automation that he does for testing purposes, since he's a QA (I am a programmer). He should be able to send XML data to a server and depending on the process that he tests, the data is different every time. I saw a strange thing, he hardcodes the XML tags and concatenates them with data which I find stupid. So I proposed him to use a template to generate XML data, because I think it's more flexible and easier, making data and presentation separate. That way if in the future he wants to start using JSON he could do it in no time. I made the code in a separate file which he imports and uses it's functions (they are two so no need for classes) and uses them to load the template and render it as he passes the data as a hash table. He insists that concatenating data and XML tags is easier and simpler and I can't wrap my mind how could that be true. I gave him an example in which the data structure for a process is changed and he have to open the file and change the XML tags or the structure and he still says that's simpler.
What is the right decision in this situation. Keep in mind that I simplified the process a lot and it actually involves sending the data and reporting the results, but they are not important here since I am talking only about generating data.