Details
-
AboutI'm not very interesting
-
SkillsPython
-
LocationUK, Dorset
Joined devRant on 5/5/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
-
There's this guy where I work who's one of the senior linux engineers. To me, he's like a linux god. He knows how to solve the most difficult problems and somehow copes with all the stress/workload. Next to that, he's only one year older than me!
Whenever I'm at work, I consider myself a junior, which I actually am. I also, as said earlier, see this senior guy as a fucking linux god and consider myself to be an absolute newbie around him but he is the most kind/friendly guy ever.
But then, today, something happened which made me feel like a god in front of him, a very, very weird feeling.
For him, doing his stuff is the most normal thing in the world while for me, it's still a learning process.
For me, programming is the most normal thing in the wold, while for him, it's still something he just knows the very basics of.
He asked me if I knew something about javascript/jquery. Said yes as I often program/script in javascript.
Explained me what he wanted to get done, it was a very simple thing for me but after hours of online searching, his lack of javascript knowledge still got him nowhere.
Told him I'd give him a working script in 30 minutes. Emailed it to him in 10.
He seemed/reacted the way I always do when he solves something I have no clue how to solve.
It was really weird to witness *him* being amazed of something that *I* made/did.
Today was a good day where I saw that one person's limitations can be anothers' most easy thing, even if that another person sees that one person as a god.13 -
MS buys Github?
GitHub Starter
GitHub for Students
GitHub Home Basic
GitHub Home Premium
GitHub Professional
GitHub Enterprise
GitHub Business
GitHub Ultimate
GitHub 2018 R2
...40 -
This one guy REALLY WANTED to work on the hardware (aka arduino in this case) part.
After hours of trying (with 8 guys) of get it to work on windows which just didn't happen, he still refused to even live boot into a Ubuntu machine.
At the end of the day one of the members went to sit down with him to talk about it and the guy finally gave in.
Two seconds into Ubuntu and arduino was successfully up and running!
Then, every day whenever he didn't get something, he'd just do nothing for the entire day while claiming to be working. The team leader sat down with him and I did too, offering him to sit next to me for a day to see how backend stuff went (I was the backender).
Did it but it just went back to the same old bullshit.
I honestly don't mind it if you find it difficult to ask for help but if you, after numerous chances and conversations, still don't do shit, sorry but fuck off.
He was a nice guy and blamed his autism for it but that's just not how it works.9 -
** The most hilarious authentication implementation I've ever seen **
They stored password in cleartext, but never mind, this is sadly quite common.
For some reasons credentials were also case insensitive (maybe to avoid silly tickets from CAPS LOCK lovers?).
Then I had a look to the query executed during the login:
SELECT * FROM users WHERE username LIKE ? AND password LIKE ?;
So I tried logging in with user "admin" and password "%"... and it worked!
I laughed all the day.30 -
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 -
"You gave us bad code! We ran it and now production is DOWN! Join this bridgeline now and help us fix this!"
So, as the author of the code in question, I join the bridge... And what happens next, I will simply never forget.
First, a little backstory... Another team within our company needed some vendor client software installed and maintained across the enterprise. Multiple OSes (Linux, AIX, Solaris, HPUX, etc.), so packaging and consistent update methods were a a challenge. I wrote an entire set of utilities to install, update and generally maintain the software; intending all the time that this other team would eventually own the process and code. With this in mind, I wrote extensive documentation, and conducted a formal turnover / training season with the other team.
So, fast forward to when the other team now owns my code, has been trained on how to use it, including (perhaps most importantly) how to send out updates when the vendor released upgrades to the agent software.
Now, this other team had the responsibility of releasing their first update since I gave them the process. Very simple upgrade process, already fully automated. What could have gone so horribly wrong? Did something the vendor supplied break their client?
I asked for the log files from the upgrade process. They sent them, and they looked... wrong. Very, very wrong.
Did you run the code I gave you to do this update?
"Yes, your code is broken - fix it! Production is down! Rabble, rabble, rabble!"
So, I go into our code management tool and review the _actual_ script they ran. Sure enough, it is my code... But something is very wrong.
More than 2/3rds of my code... has been commented out. The code is "there"... but has been commented out so it is not being executed. WT-actual-F?!
I question this on the bridge line. Silence. I insist someone explain what is going on. Is this a joke? Is this some kind of work version of candid camera?
Finally someone breaks the silence and explains.
And this, my friends, is the part I will never forget.
"We wanted to look through your code before we ran the update. When we looked at it, there was some stuff we didn't understand, so we commented that stuff out."
You... you didn't... understand... my some of the code... so you... you didn't ask me about it... you didn't try to actually figure out what it did... you... commented it OUT?!
"Right, we figured it was better to only run the parts we understood... But now we ran it and everything is broken and you need to fix your code."
I cannot repeat the things I said next, even here on devRant. Let's just say that call did not go well.
So, lesson learned? If you don't know what some code does? Just comment that shit out. Then blame the original author when it doesn't work.
You just cannot make this kind of stuff up.105 -
You are lonely because ->
You don't have a partner because ->
You are a nocturnal person because ->
Night might be the best time for development because ->
You are too much obsessed with programming because ->
You are lonely because ->
...8 -
As a developer, sometimes you hammer away on some useless solo side project for a few weeks. Maybe a small game, a web interface for your home-built storage server, or an app to turn your living room lights on an off.
I often see these posts and graphs here about motivation, about a desire to conceive perfection. You want to create a self-hosted Spotify clone "but better", or you set out to make the best todo app for iOS ever written.
These rants and memes often highlight how you start with this incredible drive, how your code is perfectly clean when you begin. Then it all oscillates between states of panic and surprise, sweat, tears and euphoria, an end in a disillusioned stare at the tangled mess you created, to gather dust forever in some private repository.
Writing a physics engine from scratch was harder than you expected. You needed a lot of ugly code to get your admin panel working in Safari. Some other shiny idea came along, and you decided to bite, even though you feel a burning guilt about the ever growing pile of unfinished failures.
All I want to say is:
No time was lost.
This is how senior developers are born. You strengthen your brain, the calluses on your mind provide you with perseverance to solve problems. Even if (no, *especially* if) you gave up on your project.
Eventually, giving up is good, it's a sign of wisdom an flexibility to focus on the broader domain again.
One of the things I love about failures is how varied they tend to be, how they force you to start seeing overarching patterns.
You don't notice the things you take back from your failures, they slip back sticking to you, undetected.
You get intuitions for strengths and weaknesses in patterns. Whenever you're matching two sparse ordered indexed lists, there's this corner of your brain lighting up on how to do it efficiently. You realize it's not the ORMs which suck, it's the fundamental object-relational impedance mismatch existing in all languages which causes problems, and you feel your fingers tingling whenever you encounter its effects in the future, ready to dive in ever so slightly deeper.
You notice you can suddenly solve completely abstract data problems using the pathfinding logic from your failed game. You realize you can use vector calculations from your physics engine to compare similarities in psychological behavior. You never understood trigonometry in high school, but while building a a deficient robotic Arduino abomination it suddenly started making sense.
You're building intuitions, continuously. These intuitions are grooves which become deeper each time you encounter fundamental patterns. The more variation in environments and topics you expose yourself to, the more permanent these associations become.
Failure is inconsequential, failure even deserves respect, failure builds intuition about patterns. Every single epiphany about similarity in patterns is an incredible victory.
Please, for the love of code...
Start and fail as many projects as you can.30 -
So im making an app that tracks you real time and sends spooky pictures of your frequented locations (scp 1471, if anyone is familiar with scps), and totally forgot about that it self triggers daily, so when i wanted to check the time, i nearly shat myself. The google logo makes it infinitely more scary.11
-
Today I felt sorry for my boss.
Story behind it:
My boss always encourages me to do the right thing. One of those right things is to enforce quality gates in our build pipelines which, as many of you know, means that the build fails if certain quality parameters are not met. Now an external vendor team merged the code this past thursday for a large feature that they had been working on and our build failed majestically throwing out the statistics and the offending files and lines of code.
All hell broke loose and there were escalations and what not and people working extra hours and over the weekend to try and get it right. So, I get a call from my boss earlier today to explain to me how important it is to release the feature and how it's going to be very bad if we don't. He was trying to justify his ask which was to lower the quality criteria and let the build pass for this week. Of course the dev in me was furious but then I realized it's not him but the corporate culture. Why would he or anyone would risk losing their jobs over the quality of code?
If you work at a place where IT is a support function of the company's primary business, I understand the moral compromises you guys have to make sometimes to keep the ball rolling. Thank you for your effort to make the world a better place.
So, thank you boss for all your support. I know it's not always up to you to decide on things but keep up the good work.4 -
>you love Google
>you're writing a CV
>you have big ego
>your CV looks like that one
>you're probably me28