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
Search - "long pr"
-
Manager: This button is too dark, you need to lighten it. Have you no sense of design?
Dev: …
Dev: Hows this for an adjustment?
Manager: Wayyyyy too light now, jesus you need glasses if you think that’s good.
Dev: …
Dev: How about now?
Manager: It’s close, make it just a little more dark. God why does this have to take so long, do I have to hold your hand through this entire process!
Dev: …
Dev: There that good?
Manager: Yes that’s perfect! Send me a PR immediately so I can approve, we need to get this out ASAP, it’s critical!!
Dev: I can’t.
Manager: ????
Dev: There’s no diff, you had me gradually adjust the colour back to exactly what it was originally.
Manager: THAT’S IMPOSSIBLE IT LOOKS COMPLETELY DIFFERENT. HOW DARE YOU INSULT ME LIKE THIS, I HAVE A MEETING I NEED TO GET OFF TO BUT WE WILL BE HAVING WORDS LATER ABOUT THIS INAPPROPRIATE BEHAVIOUR.
Dev: …16 -
Fuck you, devs who quote Knuth:
"Premature optimization is the root of all evil"
I agree with the spirit of the quote. I agree that long-winded arguments comparing microsecond differences in performance between looping or matching constructs in a language syntax is almost always nonsense. Slightly slower code can even be preferable if it's significantly clearer, safer and easier to maintain.
But, two fucking points need to be made to you lazy quickfix hipsters trying to sell your undercooked spaghetti code as "al dente", just fucking admit that you had no clue what you were doing.
So here we go:
1. If you write neat correct code in one go, you don't need to spend time to optimize it. Takes time to learn the right patterns, but will save you time during the rest of your career.
2. If you quote Knuth, at least provide the context: "We should forget about small efficiencies, say about 97% of the time [...] Yet we should not pass up our opportunities in that critical 3%"
YES THAT CRITICAL 3% IS WHERE YOU MESSED UP.
I'll forgive you for disgorging your codevomit into this silly PR.
BUT YOU'RE QUOTING KNUTH IN YOUR DEFENSE?
Premature optimization is the root of all evil... 6300 SQL queries to show a little aggregate graph on the dashboard... HE WOULD FUCKING SLAP YOUR KEYBOARD IN HALF IN YOUR FACE.3 -
API Guy.
He has a serious regex problem.
Regexes are never easy to read, but the ones he uses just take the cake. They're either blatantly wrong, or totally over-engineered garbage that somehow still lacks basic functionality. I think "garbage" here is a little too nice, since you can tell what garbage actually is/was without studying it for five minutes.
In lieu of an actual rant (mostly because I'm overworked), I'll just leave a few samples here. I recommend readying some bleach before you continue reading.
Not a valid url name regex:
VALID_URL_NAME_REGEX = /\A[\w\-]+\Z/
Semi-decent email regex: (by far the best of the four)
VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-.]+\.[a-z]+\z/i
Over-engineered mess that only works for (most) US numbers:
VALID_PHONE_REGEX = /1?\s*\W?\s*([2-9][0-8][0-9])\s*\W?\s*([2-9][0-9]{2})\s*\W?\s*([0-9]{4})(\se?x?t?(\d*))?/
and for the grand finale:
ZIP_CODE_REGEX = /(^\d{5}(-\d{4})?$)|(^[ABCEGHJKLMNPRSTVXY]{1}\d{1}[A-Z]{1} *\d{1}[A-Z]{1}\d{1}$)|GIR[ ]?0AA|((AB|AL|B|BA|BB|BD|BH|BL|BN|BR|BS|BT|CA|CB|CF|CH|CM|CO|CR|CT|CV|CW|DA|DD|DE|DG|DH|DL|DN|DT|DY|E|EC|EH|EN|EX|FK|FY|G|GL|GY|GU|HA|HD|HG|HP|HR|HS|HU|HX|IG|IM|IP|IV|JE|KA|KT|KW|KY|L|LA|LD|LE|LL|LN|LS|LU|M|ME|MK|ML|N|NE|NG|NN|NP|NR|NW|OL|OX|PA|PE|PH|PL|PO|PR|RG|RH|RM|S|SA|SE|SG|SK|SL|SM|SN|SO|SP|SR|SS|ST|SW|SY|TA|TD|TF|TN|TQ|TR|TS|TW|UB|W|WA|WC|WD|WF|WN|WR|WS|WV|YO|ZE)(\d[\dA-Z]?[ ]?\d[ABD-HJLN-UW-Z]{2}))|BFPO[ ]?\d{1,4}/
^ which, by the way, doesn't match e.g. Australian zip codes. That cost us quite a few sales. And yes, that is 512 characters long.47 -
I recently joined the dark side - an agile consulting company (why and how is a long story). The first client I was assigned to was an international bank. The client wanted a web portal, that was at its core, just a massive web form for their users to perform data entry.
My company pitched and won the project even though they didn't have a single developer on their bench. The entire project team (including myself) was fast tracked through interviews and hired very rapidly so that they could staff the project (a fact I found out months later).
Although I had ~8 years of systems programming experience, my entire web development experience amounted to 12 weeks (a part time web dev course) just before I got hired.
I introduce to you, my team ...
Scrum Master. 12 years experience on paper.
Rote memorised the agile manifesto and scrum textbooks. He constantly went “We should do X instead of (practical thing) Y, because X is the agile way.” Easily pressured by the client to include ridiculous (real time chat in a form filling webpage), and sometimes near impossible features (undo at the keystroke level). He would just nag at the devs until someone mumbled ‘yes' just so that he would stfu and go away.
UX Designer. 3 years experience on paper ... as business analyst.
Zero professional experience in UX. Can’t use design tools like AI / photoshop. All he has is 10 weeks of UX bootcamp and a massive chip on his shoulder. The client wanted a web form, he designed a monstrosity that included several custom components that just HAD to be put in, because UX. When we asked for clarification the reply was a usually condescending “you guys don’t understand UX, just do <insert unhandled edge case>, this is intended."
Developer - PHD in his first job.
Invents programming puzzles to solve where there are none. The user story asked for a upload file button. He implemented a queue system that made use of custom metadata to detect file extensions, file size, and other attributes, so that he could determine which file to synchronously upload first.
Developer - Bootlicker. 5 years experience on paper.
He tried to ingratiate himself with the management from day 1. He also writes code I would fire interns and fail students for. His very first PR corrupted the database. The most recent one didn’t even compile.
Developer - Millennial fratboy with a business degree. 8 years experience on paper.
His entire knowledge of programming amounted to a single data structures class he took on Coursera. Claims that’s all he needs. His PRs was a single 4000+ line files, of which 3500+ failed the linter, had numerous bugs / console warnings / compile warnings, and implemented 60% of functionality requested in the user story. Also forget about getting his attention whenever one of the pretty secretaries walked by. He would leap out of his seat and waltz off to flirt.
Developer - Brooding loner. 6 years experience on paper.
His code works. It runs, in exponential time. Simply ignores you when you attempt to ask.
Developer - Agile fullstack developer extraordinaire. 8 years experience on paper.
Insists on doing the absolute minimum required in the user story, because more would be a waste. Does not believe in thinking ahead for edge conditions because it isn’t in the story. Every single PR is a hack around existing code. Sometimes he hacks a hack that was initially hacked by him. No one understands the components he maintains.
Developer - Team lead. 10 years of programming experience on paper.
Writes spaghetti code with if/else blocks nested 6 levels deep. When asked "how does this work ?”, the answer “I don’t know the details, but hey it works!”. Assigned as the team lead as he had the most experience on paper. Tries organise technical discussions during which he speaks absolute gibberish that either make no sense, or are complete misunderstandings of how our system actually works.
The last 2 guys are actually highly regarded by my company and are several pay grades above me. The rest were hired because my company was desperate to staff the project.
There are a 3 more guys I didn’t mention. The 4 of us literally carried the project. The codebase is ugly as hell because the others merge in each others crap. We have no unit tests, and It’s near impossible to start because of the quality of the code. But this junk works, and was deployed to production. Today is it actually hailed as a success story.
All these 3 guys have quit. 2 of them quit without a job. 1 found a new and better gig.
I’m still here because I need the money. There’s a tsunami of trash code waiting to fail in production, and I’m the only one left holding the fort.
Why am I surrounded by morons?
Why are these retards paid more than me?
Why are they so proud when all they produce is trash?
How on earth are they still hired?
And yeah, FML.8 -
Manager: What’s taking so long on that PR?? It’s just some small styling adjustments
Dev: No it’s not you added an entire new calendar module that doesn’t work
Manager: Ok but besides that it’s just a small couple of css edits
Dev: You made styling changes in 50 files, half of which break our mobile responsiveness
Manager: Well then STOP talking to me and FIX IT if you’re so smart.
Dev: You also added a series of filters on a table in this same PR that cause th—
Manager: OK SO I GOT A BIT DISTRACTED THE FACT IS IT ALL NEEDS TO GET DONE SO IT DOESN’T MATTER IF IT’S ALL ON ONE PR SPLITTING THINGS UP INTO SMALL UPDATES IS JUST UNNECESSARY BUREAUCRACY AND IF YOU LIKE THAT THEN GO. WORK. FOR. THE GOVERNMENT!!!
Dev: …10 -
Why is the contributing manual of your open source project more thoughtfully cultivated than your code style guide and testing procedure?
Why the fuck do you care about the message in my PR, or even merge vs rebase of commits, when your spaghetti-tomatosource is so richly saturated with critically minced bugmeat?
Why are you standing there, shouting at me about your convoluted rules, in your little brown uniform? Why do I feel like the enemy when I contribute a useful fix, something which makes the code work better?
You know what, fuck all of you, you jilted acetous neckbeards, I will deploy my secret weapon, I will bypass the power you hold over your tiny fascist digital dominions.
If you play it like this, I will summon the nefarious vile side of Open Source. I will usurp your throne. I will stab out your crying eyes, rip out your conceited tongue, impale your lonely heart.
Tremble before me! I wield the almighty, legendary Fork!
The king is dead, long live the king!5 -
> make a change
> PR gets rejected
> IHATEFORALIVING! YOUR CHANGE IS NOT WORKING! EVERYTHING BREAKS!
> 3 hours long debugging session
> We find out a whole bunch of bugs
> Suddenly, everything works
> None of the bugs had ANYTHING to do with my change. In the instances where the app broke, my code wasn't even being called at all.
> My change was literally the one and only working thing
I wish life was like in The Office, when you just stop what you're doing and you drop the Jim stare at some camera3 -
I once reviewed a Pull Request made by a fairly junior developer. They had joined recently, and this was one of the first times they had to touch a bigger part of the code.
Due to a mix of inexperience, new (to them) coding standards and lack of git knowledge, they ended up with a mess of a PR, with a few thousand lines changed, and no way to split it off.
I ended up spending the best part of a day reviewing the whole thing and requesting changes.
Even with the long list of improvements, however, I wasn't sure they would get the magnitude of their fuckup.
So I decided to use a real-world, palpable way to show them what they had done: I went and printed the github diff for that PR. It rendered the glorious amount of 73 pages.
I'll never forget their face, and those of their teammates, when I barged into the room with a thick wad of paper and deposited them on their desk.
At least it worked. I never saw another big, ill-thought pull request from them again.3 -
TFW your client's git policies are so draconian that the dev teams use "develop" as trunk, and completely ignore the release process.
I wrote up 50 pages of git standards, documentation and procedure for a client. Bad indian director 9000 decides the admin (also Indian) who specializes in Clearcase and has no git or development experience is more qualified to decide and let's him set the policy.
FF to today:
- documentation, mostly contradictory, is copy pasted from the atlassian wiki
- source tree is the standard
- no force pushing of any branches, including work branches
- no ff-merge
- no rebasing allowed
- no ssh, because he couldn't figure it out...errr it's "insecure"
- all repos have random abbreviated names that are unintelligible
- gitflow, but with pull requests and no trust
- only project managers can delete a branch
- long lived feature branches
- only projects managers can conduct code reviews
- hotfixes must be based off develop
- hotfixes must go in the normal release cycle
- releases involve creating a ticket to have an admin create a release branch from your branch, creating a second ticket to stage the PR, a third ticket to review the PR (because only admins can approve release PRs), and a fourth ticket to merge it in
- rollbacks require director signoff
- at the end of each project the repo must be handed to the admin on a burned CD for "archiving"
And so no one actually uses the official release process, and just does releases out of dev. If you're wondering if IBM sucks, the answer is more than you can possibly imagine.11 -
This is something that happened 2 years ago.
1st year at uni, comp sci.
Already got project to make some app for the univ that runs in android, along with the server
I thought, omg, this is awesome! First year and already got something to offer for the university 😅
(it's a new university, at the time I was the 2nd batch)
Team of 12, we know our stuffs, from the programming POV, at least, but we know nothing about dealing with client.
We got a decent pay, we got our computers upgraded for free, and we even got phones of different screen sizes to test out our apps on.
No user requirement, just 2-3 meetings. We were very naive back then.
2 weeks into development, Project manager issues requirement changes
we have a meeting again, discussing the important detail regarding the business model. Apparently even the univ side hadn't figure it out.
1 month in the development, the project manager left to middle east to pursue doctoral degree
we were left with "just do what you want, as long as it works"
Our projects are due to be done in 3 months. We had issues with the payment, we don't get paid until after everything's done. Yet the worse thing is, we complied.
Month 3, turns out we need to present our app to some other guy in the management who apparently owns all the money. He's pleased, but yet, issued some more changes. We didn't even know that we needed to make dashboard at that time.
The project was extended by one month. We did all the things required, but only got the payment for 3 months.
Couldn't really ask for the payment of the fourth month since apparently now the univ is having some 'financial issues'.
And above all: Our program weren't even tested, let alone being used, since they haven't even 'upgraded' the university such that people would need to use our program as previously planned.
Well, there's nothing to be done right now, but at least I've learned some REALLY valuable lesson:
1. User Requirement is a MUST! Have them sign it afterwards, and never do any work until then. This way, change of requirements could be rejected, or at least postponed
2. Code convention is a MUST! We have our code, in the end, written in English and Indonesian, which causes confusion. Furthermore, some settle to underscore when naming things, while other chooses camel case.
3. Don't give everyone write access to repository. Have them pull their own, and make PR later on. At least this way, they are forced to fix their changes when it doesn't meet the code convention.
4. Yell at EVERYONE who use cryptic git commit message. Some of my team uses JUST EMOTICONS for the commit message. At this point, even "fixes stuffs" sound better.
Well, that's for my rant. Thanks for reading through it. I wish some of you could actually benefit from it, especially if you're about to take on your first project.3 -
How can you defend your ugly unstructured mess of a PR, when every spit-droplet infused spray of words from your mouth is full of syntax errors?
How can you call yourself a developer without being aware of basic logic? I ain't got no tolerance for double negations, not not true is just true, you doltish twat.
WHEN YOU TALK THERE IS A CLOUD OF RED SQUIGGLY LINES IN THE AIR FLOATING AROUND YOUR HEAD.
I mean what the fuck is up with eggcetera? Why are you just swapping out letters? What has the little ligature t in & ever done to you? Do I have to fucking replace & with 🥚 so your word diarrhea makes sense again?
NO. JUST PLEASE... STOP TALKING. YOU'RE RAPING LANGUAGE, AND IT WAS ALREADY BEATEN DEAD.
Unlike me, you have a degree in computer science... but how, how the fuck did you pass? How did neither your tongue nor code get stuck in a linter?
AND YOUR RESPONSE IS STILL: "YOU DON'T NEED TO LEARN WHEN YOU'RE FINISHED WITH SCHOOL" ... "WHAT DOES IT MATTER, IT WORKS, RIGHT?"
NO, IT'S NOT RIGHT.
You're lucky I love refactoring.
I'll start with a medical grade steel scalpel and a long sharp hook. Maybe I can clean up this brain a little. See if the tests turn green if I cut some of this gray matter away... plenty of unreachable statements, so many unnecessary loops...
Might have to start from scratch.8 -
For everyone happy to see Facebook getting negative PR, just remember, unless people decide that they are willing to pay a monthly subscription for social media, nothing is going to change long term.6
-
I am participating in a project i called "Game of Thrones"
We pretend that we are a team, but in reality everyone hate one another.
It took only 3 weeks for Team Leader to turn everyone against him.
He is constantly fighting for power with Architect who is terrible at his job, and doesn't listen to his advice even if they are good.
We hate Team Leader because he is an tyrant, who is ruling from high tower his peasants. His favorite task is to create various rules that everyone has to accept. You have to write "I accept" in a chat but this is the only choice. You cannot disagree.
Moreover there are developers from client side. They "committed" current project which is full of bugs and generally doesn't work. I don't know why they are still working there, but I presume every of them is working for 5+ years, so they are the only ones able to dig thru the spaghetti they made.
They constantly fight with us about the how code should be written, they commits are garbage but they are very peaky when it comes to ours PR.
They always drag our PR as long as they can. Even sometimes pointing they mistakes as ours.3 -
I can't take this anymore...
I'm reviewing n-th PR and I wanna gouge my eyes rn. This is the example I found in one of the PRs (and I could enumerate the examples for a long time...)
Mother****er piece of sh*t.11 -
I'm getting more and more triggered by my colleagues overusing words in seemingly random fashion.
The word 'perspective' comes up at least 6 times during a meeting, from an x perspective, from a y perspective. It would be fine in a design meeting but it's used _so fucking much_ I cringe every time I hear it.
Another one is 'standard', that gets put in front of every word nowadays, standard process, standard protocol, standard machine, standard pipeline. What does it mean? No clue, what does it add? Nothing.
'Please put this add the standard location.'
Where?
'The default one'
What?!
I remove it from documentation every chance I get.
Furthermore, some documentation changes make small pieces of information super long. A nice summary list of features? Make it at least 3 sentences for every bullet point. 1-sentence info with a reference link to more info? Scratch that let's include all information in that reference paragraph anyway. Sometimes they even expand English expressions for no reason, making them longer and harder to read.
WHYYYY
We always complain about shit documentation and yet we're oblivious to the fact that our own docs are so bloated. Stop repeating information, stop using useless adjectives, just put it all in 1 sentence and add dozens of code examples. One piece of code says more than a billion words.
I'm not innocent either. As a teen I was great at writing long pieces of text that seemed like a great read but were actually way too bloated for the information I needed to convey. It was great for reaching word limits.
Now I'm trying my absolute best to be as concise and to-the-point as possible because I know that nobody likes reading and people just want the information that they're looking for.
Even this rant is overly long, but thank god that it's just a rant and I can let off some steam.
Btw same thing goes for diagrams, too many icons, too much text, too many lines. When I try to submit a clean-as-fuck diagram I get asked to add more info/features to which I say No, we're already at the max.
I even got a PR for review that made some changes to add unnecessary information, I pointed it out and never heard anything from them again. I rejected the PR, and never saw a new one.
* Sigh *
It's just so strange to me, it's never clear to me why these things happen. I'm too much of a coward to point these things out unless they endanger the quality of the product. But maybe they just need somebody to tell it to them.6 -
Had a five hour long debate with one of our Senior Developers today about pull request etiquette.
His view was reviewers should always email or call him before adding comments to any of his requests and they should never block them as he should be allowed to code in "his own style" and should be able to approve his own pull requests.
I explained that we have code standards and an agreed PR workflow be needs to comply with.
He then started talking about meteors and plane crashes. Literally no helping some people.18 -
I was asked to fix a critical issue which had high visibility among the higher ups and were blocking QA from testing.
My dev lead (who was more like a dev manager) was having one of his insecure moments of “I need to get credit for helping fix this”, probably because he steals the oxygen from those who actually deserve to be alive and he knows he should be fired, slowly...over a BBQ.
For the next few days, I was bombarded with requests for status updates. Idea after idea of what I could do to fix the issue was hurled at me when all I needed was time to make the fix.
Dev Lead: “Dev X says he knows what the problem is and it’s a simple code fix and should be quick.” (Dev X is in the room as well)
Me: “Tell me, have you actually looked into the issue? Then you know that there are several race conditions causing this issue and the error only manifests itself during a Jenkins build and not locally. In order to know if you’ve fixed it, you have to run the Jenkins job each time which is a lengthy process.”
Dev X: “I don’t know how to access Jenkins.”
And so it continued. Just so you know, I’ve worked at controlling my anger over the years, usually triggered by asinine comments and decisions. I trained for many years with Buddhist monks atop remote mountain ranges, meditated for days under waterfalls, contemplated life in solitude as I crossed the desert, and spent many phone calls talking to Microsoft enterprise support while smiling.
But the next day, I lost my shit.
I had been working out quite a bit too so I could have probably flipped around ten large tables before I got tired. And I’m talking long tables you’d need two people to move.
For context, unresolved comments in our pull request process block the ability to merge. My code was ready and I had two other devs review and approve my code already, but my dev lead, who has never seen the code base, gave up trying to learn how to build the app, and hasn’t coded in years, decided to comment on my pull request that upper management has been waiting on and that he himself has been hounding me about.
Two stood out to me. I read them slowly.
“I think you should name this unit test better” (That unit test existed before my PR)
“This function was deleted and moved to this other file, just so people know”
A devil greeted me when I entered hell. He was quite understanding. It turns out he was also a dev.3 -
Github 101 (many of these things pertain to other places, but Github is what I'll focus on)
- Even the best still get their shit closed - PRs, issues, whatever. It's a part of the process; learn from it and move on.
- Not every maintainer is nice. Not every maintainer wants X feature. Not every maintainer will give you the time of day. You will never change this, so don't take it personally.
- Asking questions is okay. The trackers aren't just for bug reports/feature requests/PRs. Some maintainers will point you toward StackOverflow but that's usually code for "I don't have time to help you", not "you did something wrong".
- If you open an issue (or ask a question) and it receives a response and then it's closed, don't be upset - that's just how that works. An open issue means something actionable can still happen. If your question has been answered or issue has been resolved, the issue being closed helps maintainers keep things un-cluttered. It's not a middle finger to the face.
- Further, on especially noisy or popular repositories, locking the issue might happen when it's closed. Again, while it might feel like it, it's not a middle finger. It just prevents certain types of wrongdoing from the less... courteous or common-sense-having users.
- Never assume anything about who you're talking to, ever. Even recently, I made this mistake when correcting someone about calling what I thought was "powerpc" just "power". I told them "hey, it's called powerpc by the way" and they (kindly) let me know it's "power" and why, and also that they're on the Power team. Needless to say, they had the authority in that situation. Some people aren't as nice, but the best way to avoid heated discussion is....
- ... don't assume malice. Often I've come across what I perceived to be a rude or pushy comment. Sometimes, it feels as though the person is demanding something. As a native English speaker, I naturally tried to read between the lines as English speakers love to tuck away hidden meanings and emotions into finely crafted sentences. However, in many cases, it turns out that the other person didn't speak English well enough at all and that the easiest and most accurate way for them to convey something was bluntly and directly in English (since, of course, that's the easiest way). Cultures differ, priorities differ, patience tolerances differ. We're all people after all - so don't assume someone is being mean or is trying to start a fight. Insinuating such might actually make things worse.
- Please, PLEASE, search issues first before you open a new one. Explaining why one of my packages will not be re-written as an ESM module is almost muscle memory at this point.
- If you put in the effort, so will I (as a maintainer). Oftentimes, when you're opening an issue on a repository, the owner hasn't looked at the code in a while. If you give them a lot of hints as to how to solve a problem or answer your question, you're going to make them super, duper happy. Provide stack traces, reproduction cases, links to the source code - even open a PR if you can. I can respond to issues and approve PRs from anywhere, but can't always investigate an issue on a computer as readily. This is especially true when filing bugs - if you don't help me solve it, it simply won't be solved.
- [warning: controversial] Emojis dillute your content. It's not often I see it, but sometimes I see someone use emojis every few words to "accent" the word before it. It's annoying, counterproductive, and makes you look like an idiot. It also makes me want to help you way less.
- Github's code search is awful. If you're really looking for something, clone (--depth=1) the repository into /tmp or something and [rip]grep it yourself. Believe me, it will save you time looking for things that clearly exist but don't show up in the search results (or is buried behind an ocean of test files).
- Thanking a maintainer goes a very long way in making connections, especially when you're interacting somewhat heavily with a repository. It almost never happens and having talked with several very famous OSSers about this in the past it really makes our week when it happens. If you ever feel as though you're being noisy or anxious about interacting with a repository, remember that ending your comment with a quick "btw thanks for a cool repo, it's really helpful" always sets things off on a Good Note.
- If you open an issue or a PR, don't close it if it doesn't receive attention. It's really annoying, causes ambiguity in licensing, and doesn't solve anything. It also makes you look overdramatic. OSS is by and large supported by peoples' free time. Life gets in the way a LOT, especially right now, so it's not unusual for an issue (or even a PR) to go untouched for a few weeks, months, or (in some cases) a year or so. If it's urgent, fork :)
I'll leave it at that. I hear about a lot of people too anxious to contribute or interact on Github, but it really isn't so bad!4 -
Lead: how long do you think it would take to fix the bug?
Programmer: 20 mins with a testing
**Lead an hour later**
Lead: I don't see PR for the fix
Programmer: the fix broke all the unit tests so I am fixing them now. -
Long time lurker, I now have something to show you and it's something I've proudly made!
I've been working on OctoLenses lately, a Chrome extension allowing you to filter your PR and issues on Github. I find it really useful on a daily basis; and you might too
It can be used to:
- Monitor the PRs that need a review (or that have been reviewed successfuly)
- Find issues on open-source projects you like that you could take on
- Anything you can express with a Github search basically
It's good enough that I feel like I can share it with you, and I'd really like if you could take some of your time to give me a bit of feedback.
What do you like?
What you don't?
Which feature should I add?
Anything constructive basically :)
Thank you (and sorry for the self-promotion)!1 -
tldr: maintainers can be assholes
So there's this python package+cli tool that I found interesting while browsing github and thought of contributing to it. Now this repo has around 2000 issues and multiple open PRs so seemed like a good start.
So i submit 2 PRs implementing similar features on different sites (it is a scraping repo). This douche of a maintainer marks comments various errors in the code convention not being followed without specifying what they actually were. Now I had specified that i was new to this repo so and would need his help (I guess this is one of the jobs of the reviewer). This piece of shit comments changes in the pr with one or two word sentences like "again", "wtf" and occasionally psycopathic replies. That son of a bitch can't tell what's wrong like wtf dude, instead of having a long discussion over the comments section of the fucking pr why can't you just point out what exactly is wrong and I'll happily fix that shit, but no, you have to be a douche about out it and employ sarcasm. Well FUCK YOU TOO.1 -
So, I had to listen very badly in a scrum about my poor code quality. Just because I haven't used the latest version of the library in my gradle build file, I haven't used DTO in the response of few endpoints in the controller class instead I used entity,... Etc was the mistake.
I admit that I have a long way to improve myself and there is a lot to learn, but there should be a proper way to escalate the situation rather than publicly pointing out mistakes rudely.
He is a senior with 10+ years of experience who badly told me in the scrum and not only that whenever there is a change needed in my PR he takes the screenshot and puts it in our dev team group and shows the mistakes and gives the suggestions instead of writing comments on the github PR.
Not only that, if I inform in the daily updates that I took 2 hours for this and that task, he says it should be done in 20 to 30 minutes.
Upper management has given him a lot of respect because he is knowledgeable and knows the stuff but it doesn't mean he is entitled to behave like this and demoralise other juniors.
The matter is cool now but this incident happened to me a few months back and those days were really toxic for me at work.6 -
I am a good person. I can even say I am a good programmer. I have worked hard to get where I am and that shows perseverance. Although, where I am right now is not what I expected, I am somewhere. I can do something. I have good intentions.
Someday, I will build software which will be used by millions of people around the interwebs. And they will love me, for I will have made their lives better....in some way. Some will even consider paying me for it. Not because the well placed and non intrusive donate button I put there, but out of pure adoration and bare necessity to preserve someone as brilliant and precious as me. I shall be the definition of success. But I long for neither adoration nor wealth, for I am humble or at least that is how I will be perceived.
Like flies to the honey my success will attract big evil corporations to acquire my business. And I shall spit on their wretched face....at first. I would like to be wooed. Such display of integrity shall inspire generations of programmers. Let ye be inspired. There will be those who envy my achievements and they will be mocked and shunned by my true believers. But being the kind soul that I am, I will bring back my minions, for it could a PR nightmare.
All these events will take place in a not too distant future. Sure, I am going through a dark time now, it will pass. 'tis nothing but me transitioning from a lame ass PHP coder moth to this totally badass software engineer who is also a cool bro. This eclipse of my brain shall pass. My neurons will fire in all directions like photons from the sun during late winter, for it may overheat and we definitely don't want that.
I pray to the gods of engineering to grant my wishes. Trust me guys, you will be thanking yourselves when donate my money to charities that will help me set up. But that's another scheme. Amen.4 -
Legacy code that has a really long and convoluted way of integrating Dropbox authorisation to save files etc.
This happened in a meeting discussing where I’m at with the upgrade.
Me: This upgrade is going to take a while because of how outdated the app is. Also for assets uploaded by the user why don’t we just use active storage for this now as we have rails 6 now. Plus it will reduce a lot of code.
Other Dev: why would we do that? It’s a big change and will need testing.
Me: A lot of stuff is broken after the upgrade anyway and if we have a more built in simple way to do it why wouldn’t we? Also simplifying the code base is always good. The PR is already 1000+ files and we’re going to have to retest the app anyways.
Other Dev: *crickets*
I’m trying to make the app more smooth and streamlined and overall a better codebase as currently it’s shocking there and security holes galore, its like they don’t trust me with changing anything big haha honestly I think I’m the only one who wants to actually improve the application.2 -
Someone raised a PR for the opensource project "fast XML parser". Since this was a major change, it was difficult to review. I asked for the purpose and requested to break it into multiple PRs, where 1 PR should have related changes only. And any good change but unnecessary change can be avoided to scheduled for later.
We had long arguments for a month or two.
I don't know why but instead of breaking the PR, the contributor keep updating his PR for every commit someone made on the original repo.
He also stopped contributing for other changes, and commenting on other issues. (Change in the behavior)
Finally after 5-6 months, I had to close the PR as it was not active, having conflicts and not as per guidelines. -
me:task assigned is a small fix.Gonna finish Early sit back relax this sprint.
mail(next day):we've moved to microservices.setup as easy as gulp landscape:start
me:cool!shinny new stuff!seems easy!!
project:npm failed..please check module xxx..
me:fine.....
after long mail chain
project:npm failed unknown file not found
me:fine.....
after hours of googling and little github issue browsing
project:server running @ portxxx
me:yay finally happy life!!makes chnages, sent for review.
reviewer:code needs refactoring!!
me:make all changes..waits for faceless reviewer from another timezone!
reviewer:thumbs up.
me:i will make it in time!!!yes!!
jenkins:buid:failure
me:no still i wont give up...
debug finds out new bugs caused by unrelated code...make new PR the end is near,one day more will definitely merge!!!
mail:jenkins down for maintenance!
me:nooooo....waits till last minute gets thumbs up for merge, finally merged in the last second!!
all for 12 lines of code change.
:/
sad life -
!rant
27 days ago I asked here for advice on how to mentor software engineer student that was terrible at coding.
So, we are in the middle of the mentoring, my approach is for her to get used to normal engineering tools, in this occasion she is learning Git and "kanban" (basically we are using Clubhouse for this one) and Github PR submission and approval (I'm the one who approves them, naturally) by doing.
With git, things are hard because we cannot share a terminal session (via upterm) due to her using Windows on her laptop (WSL is an option for using upterm but her internet is so damn slow doing the configuration takes way too long), otherwise teaching her use git would be smoother than it is currently, with the other tools she is gaining a good grasp of them, it pleases me that the bottleneck is with Git itself.
She is working on a hangman game with Python, nothing fancy just the terminal. I made the stories with the requirements in Clubhouse for her to work on each as a unit removing some "thought process" of reading requirements and implementing solutions (at Uni it seems the professor writes a document of several pages detailing the background of the project and the requirements, I can see how it can become confusing for some students like her).
She will start Uni again this August 10th, there is a chance that our first "session" at this will end by then, my fear is that she forgets how to use the tools she learned, so I need to find a way to encourage her to keep using them somehow.3 -
My manager had someone else manage me for my whole time at the company so far. Nearly two years now. Anything I’d come to him with, he’d direct me to this other person.
Fair enough, dude’s really good and I learn a lot from him. I see why they trust him with so much. I think he’s a genius. I’ll never be that good. Embarrassed I’m only a few years his junior. Wonder why he’s okay with being a manager for employee pay. Don’t think about it much, normal corporate BS.
Well it got way more “normal” when his ass got laid off without notice. Feel terrible. Him and 70% of my branch’s full timers. Wonder how I got so lucky. Everyone’s gone. We barely have enough people to do a standup. They all had 5+ years on their belts minimum. Only the contractors are left.
Manager emergency meets with me. Tells me all his best staff are gone and I am now the only front end guy on the team. He tells me he is not confident in the fact I am responsible for all of the old guys work and he is worried. He thinks I can’t do it cause he thinks I suck. Fuck me man.
My manager is pissing himself realizing he has lost the only people keeping HIS job for him. He has no clue my skill level. He sees my PR’s take a bit longer to merge, yet doesn’t realize I asked that friend of mine who was managing me to critique my code a bit harder, mentorship if you will, so we’d often chat about how to make the code better or different ways of approaching problems from his brain, which I appreciated. He has seen non-blocking errors come through in our build pipelines, like a quota being reached for our kube cluster (some server BS idfk, all I know is I message this Chinese man on slack when I get this error and he refreshes the pods for me) which means we can only run a build 8x in one day before we are capped. Of all people, he should be aware of this error message and what is involved with fixing it but he sees it and nope, he reaches out to me (after the other guy had logged out already, of course) stating my merged code changes broke the build and reverts it before EOD. Next day, build works fine. He has the other guy review my PR and approve, goes on assuming he helped me fix my broken code.
Additionally, he’s been off the editor for so long this fool wouldn’t even pass an intro to JavaScript course if he tried. He doesn’t know what I’m doing because HE just doesn’t know what I’m doing. Fuck me twice man.
I feel awful.
The dude who got fired has been called in for pointless meetings TO REVIEW MY CODE still. Like a few a week since he was laid off. When I ask my manager to approve my proposals, or check to verify the sanity of something (lots of new stuff, considering I’m the new manager *coughs*) he tells me he will check with him and get back to me (doesn’t) or he tells me to literally email him myself, but not to make any changes until he signs off on them.
It’s crazy cause he still gets on me about the speed of stuff. Bro we got NOTHING coming from top down because we just fired the whole damn corp and you have me emailing an ex-employee to verify PATCH LEVEL CHANGES TO OUR FUCKING CODE.
GET ME OUT5 -
I was always into computers, ever since I was a kid. Played a lot of videogames on Windows 98 and XP, and a lot of my earliest drawings were level ideas for those games. My first encounters with code were with game creation software like GameMaker, but I barely touched the code proper outside of editing a few variables from other people's code. After that I basically forgot all about it and spent most of my teen years being a shutin.
Skip ahead to my last year of high school without much idea on what to do. I was good at math when I wasn't being a lazy shit, so between that and what my parents expected of me, I was prepared to go to university for civil engineering. However, two things changed that decision, the first being a great IT professor, when me and a friend were so far ahead, he started assigning us some harder work, and suggested we study computer science at university. The second was a super jank and obscure open-source early 2000's game that somehow still has a thriving community and is actively being developed. I stumbled upon it by chance, and after playing for a while, I submitted a balance change on the GitHub repo. Even though it was just a single variable change, that time I got it. That time I saw how powerful programming could be and what could be done with it. I submitted PR after PR of new features, changes and bugfixes, by the time I left there I had a somewhat solid grasp of the fundamentals of programming, and decided to enrol in the computer science degree.
Enrolling was possibly the best decision I ever made (not america; debt isn't an issue), as well as giving me actual social skills, every course I took just clicked. The knowledge I already somewhat intuitively had a vague grasp on from videogames, general computer use and collaborating with russian coders who produced the jankiest shit that was still somehow functional was expanded upon and consolidated with a high-quality formal education. Four years later and I'm fresh out of uni, it was a long road between when the seed was first planted in my mind and now, but I've finally found out what I want to do with my life.
won't know for sure until i find a job though ffs -
Junior Dev about 18months in my current job and I've got a problem
Started to feel not wanting to code at work, despite working on a greenfield project thats critical and using new tech. I get a little defensive about PR's over stupid small things (PR was once rejected due to auto indentation "not to standard").
Talked with boss (who I get on well with and like) and thinks my problem is I've lost confidence coding. Trys to get more senior Dev to on side to help me out more.
Same senior Dev is really close with other junior on my team - pair on alot of stuff all the time, have lunch and spend free time together, and will work way past working hours just to try and finish something that day (even though it's not due that day).
(Probs working ~60h weeks, where as I'm ~42h and contracted for 37h. I'll work on if I need to but tries to have balance)
Senior and other junior tend to ignore tickets on the board, do the work and then when I pick it up they say "I did that last night". No docs, no PR for me to ask about how it was done (as they merged it themselves). (They have previously completely refactored my branch in the past overnight then not told me atall)
I'm not saying its favouritism here, but I'm not happy with the situation. I feel I can't ask questions as they are always together or they discuss the problem themselves and just give me the answer (not really acknowledging my points). I dont tend to ask for help from this senior Dev now as I don't feel it's worthwhile learning wise for me.
Other people in the team are great but working on other aspects so not a direct one-to-one alignment (others are DB Dev & principal senior dev)
Furthermore I'm wanting to possibly work on full stack web or more architecture stuff, both which are not in my current teams remit (backend up to API).
So - what do I do? Try and remedy the situation in the current team as best as or look for a new teams as cut my losses.
I'm torn between the 2 and I'm unsure how to get out this rut. I feel I need to find a solution to this soon though
(Sorry for the long rant folks)4 -
hey devs, hope you all are doing good..
I was frustated by my salary.. I mean in this job I am good but I didn't got the expected growth..
So I find a job .. but before resigning because I know my boss is cool atleast he will listen .. so I leave him a message that I wanted to do more.. and got the other offers.. He said no worries.. we will match your package.. but now you can be associate TL and handle the team also..
I took the offer..
atleast I am satisified. The thing is new team is mostly are dumbo :( Will see how long I can pull..
or I am hoping my next rants will be something like.. I will join as junior dev pr same salary.. just take me out from this fucking TL role.. because I know what team is going to do.. someone stuck.. ask TL.. someone have internet issue ask TL.. don;t know css.. ask TL.. dont know logic.. ask TL. its look like I have to be google for team
Anyways will see how it goes.. I wish me luck
Ohh yeah if you are in TL roles.. could you share your experience please2 -
Compromise.
I think that sums up development pretty much.
Take for example coding patterns: Most of them *could* be applied on a global scale (all products)… But that doesn't mean you *should* apply them. :-)
Find a matching **compromise** that makes specific sense for the product you develop.
Small example: SOLID / DRY are good practices. But breaking these principles by for example introducing redundant code could be a very wise design decision - an example would be if you know full ahead that the redundancy is needed for further changes ahead. Going full DRY only to add the redundancy later is time spent better elsewhere.
The principle of compromise applies to other things, too.
Take for example architecture design.
Instead of trying to enforce your whole vision of a product, focus on key areas that you really think must be done.
Don't waste your breath on small stuff - cause then you probably lack the strength for focusing on the important things.
Compromise - choose what is *truly* important and make sure that gets integrated vs trying to "get your will done".
Small example: It doesn't really matter if a function is called myDingDong or myDingDongWithBells - one is longer, other shorter. Refactoring tools make renaming a function an easy task. What matters is what this function does and that it does this efficiently and precise. Instead of discussing the *name* of the function, focus on what the function *does*.
If you've read so far and think this example is dumb: Nope... I've seen PR reports where people struggled for hours with lil shit while the elephant in the room like an N+1 problem / database query or other fundamental things completely drowned in the small shit discussion noise.
We had code design, we had architecture... Same goes for people, debugging, and everything else.
Just because you don't like what weird person A does, doesn't mean it's shit.
Compromise. You don't have to like them. Just tolerate them. Listen. Then try to process their feedback unbiased. Simple as that. Don't make discussions personal - and don't isolate yourself by just working with specific persons. Cause living in such a bubble means you miss out a lot of knowledge and insight… or in short: You suck because of your own choices. :-)
Debugging... Again compromise: instead of wasting hours on debugging a problem, ASK for help. A simple: Has anyone done debugging this before or has some input for how to debug this problem efficiently?... Can sometimes work wonders. Don't start debugging without looking into alternative solutions like telemetry, metrics, known problems etc.
It could be a viable, better long term solution to add metrics to a product than to debug for hours ... Compromise. Find a fitting approach to analyze a problem instead of just starting a brute force approach.
....
Et cetera et cetera. -
Today i wake up and i expect some bit of sanity in my job. Our CTO Respects no processes and stuff. I check PR's that are requested for review.
PR i 391 files long and it's not node_modules commited :|1 -
#Suphle Rant 1: Laravel closing the gap
This is the first of a series of long overdue rants regarding Suphle, because I have had so so much to grumble about over the last ~2 years building it. A bit of introduction: I compiled a list of all the challenges I faced in my time as a salaried PHP developer. I also gathered issues complained about by other developers in a laravel group I'm part of, and decided to solve them at the framework level since they're avoidable. I also borrowed impressive features encountered in my time working with other languages and invented a new one, as well. I quit my job last July, still haven't get a new one yet cuz office workload kept conflicting with Suphle development. I concluded all work and testing on it back in August/September but it's yet to be officially released since the docs is still in progress.
Anyway, yesterday, I stumbled upon what is IMO the most progressive /tangible update I've seen in all my time following Laravel updates. It's called [precognition](don't have enough rep to post the PR link but you can search on their repo), and contains features that are actually beneficial to both developer and end user. It also turns out to be functionality that was part of Suphle's bragging rights. Their DX is still tacky but I'm devastated cuz it's a matter of time before they work it out. Makes me wonder what the quality of all I've built would be in a year if it doesn't become big enough to attract frequent contribution. I guess there's only so much one can do against a community.
Later that evening, I found a developer from my country on twitter who claims to be making a decent living. A little snooping around his profile informed me he's building his own back end framework but in NodeJS. I know with every degree of certainty that what he'll eventually do can't hold a candle against Suphle in overall functionality or thoroughness. Not a dick measuring contest but when your motive isn't significant innovation, you'll neither plan properly nor even know what exactly to build. You'll just reinvent the wheel as an academic exercise
Yet, I can't help but have that sinking feeling he's winging it, while making a windfall with his dozens of freelance projects. It kind of feels like I shortchanged myself, and Suphle's shelf life will suffer the same fate as a hobby project for 10 stars (which I don't even have yet!!). I reached out to him to rub minds together but he ignored. More pain.
I'll get over this and return to work on the docs, but from the look of things, the end isn't an appealing or expected /deserved one -
I have been working in the same PR for 2 months. Many metamorphosis of it i would say 😂 I even made it all the way to prod and had to be reverted coz it was causing straight chaos. I have worked on some pretty complex features in the past year, this the smallest yet most complicated ask i have ever received. Orleans really put my patience to test and here i am, right now completely unable to write any code. I am just here planning my vacation in 4 weeks time.1