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
-
Fuck the memes.
Fuck the framework battles.
Fuck the language battles.
Fuck the titles.
Anybody who has been in this field long enough knows that it doesn't matter if your linus fucking torvalds, there is no human who has lived or ever will live that simultaneously understands, knows, and remembers how to implement, in multiple languages, the following:
- jest mocks for complex React components (partial mocks, full mocks, no mocks at all!)
- token cancellation for asynchronous Tasks in C#
- fullstack CRUD, REST, and websocket communication (throw in gRPC for bonus points)
- database query optimization, seeding, and design
- nginx routing, https redirection
- build automation with full test coverage and environment consideration
- docker container versioning, restoration, and cleanup
- internationalization on both the front AND backends
- secret storage, security audits
- package management, maintenence, and deprecation reviews
- integrating with dozens of APIs
- fucking how to center a div
and that's a _comically_ incomplete list; barely scratches the surface of the full range of what a dev can encounter in a given day of writing software
have many of us probably done one or even all of these at different times? surely.
but does that mean we are supposed to draw that up at a moment's notice some cookie-cutter solution like a fucking robot and spit out an answer on a fax sheet?
recruiters, if you read this site (perhaps only the good ones do anyway so its wasted oxygen), just know that whoever you hire its literally the luck of the draw of how well they perform during the interview. sure, perhaps some perform better, but you can never know how good someone is until they literally start working at your org, so... have fun with that.
Oh and I almost forgot, again for you recruiters, on top of that list which you probably won't ever understand for the entirety of your lives, you can also add writing documentation, backup scripts, and orchestrating / administrating fucking JIRA or actually any somewhat technical dashboard like a CMS or website, because once again, the devs are the only truly competent ones - and i don't even mean in a technical sense, i mean in a HUMAN sense of GETTING SHIT DONE IN GENERAL.
There's literally 2 types of people in the world: those who sit around drawing flow charts and talking on the phone all day, and those WHO LITERALLY FUCKING BUILD THE WORLD
why don't i just run the whole fucking company at this point? you guys are "celebrating" that you made literally $5 dollars from a single customer and i'm just sitting here coding 12 hours a day like all is fine and well
i'm so ANGRY its always the same no matter where i go, non-technical people have just no clue, even when you implore them how long things take, they just nod and smile and say "we'll do it the MVP way". sure, fine, you can do that like 2 or 3 times, but not for 6 fucking months until you have a stack of "MVPs" that come toppling down like the garbage they are.
How do expect to keep the "momentum" of your customers and sales (I hope you can hear the hatred of each of these market words as I type them) if the entire system is glued together with ducktape because YOU wanted to expedite the feature by doing it the EASY way instead of the RIGHT way. god, just forget it, nobody is going to listen anyway, its like the 5th time a row in my life
we NEED tests!
we NEED to know our code coverage!
we NEED to design our system to handle large amounts of traffic!
we NEED detailed logging!
we NEED to start building an exception database!
BILBO BAGGINS! I'm not trying to hurt you! I'm trying to help you!
Don't really know what this rant was, I'm just raging and all over the place at the universe. I'm going to bed.20 -
The code is a freaking mess. Shared behavior, terrible variable/method naming, misleading module naming, dynamic polymorphic spaghetti, whitespace errors, no consistency, confusing even if you understand what the code is doing, ... . It should never have passed code review. It probably wasn't code reviewed.
The comments are sparse and useless. Quality level: // This is bridge.
The documentation does not exist.
Testing steps for QA are missing several steps, including setup, so actually using the feature is bloody challenging. If one thing is wrong, the feature just doesn't show up (and ofc won't tell you why).
The specs for the feature are outdated and cover only 4 of 19+ cases. And are neigh useless for those 4.
The specs for the report I'm fixing don't even check the data on the report; it just checks for one bit of data on each row it creates -- a name -- which is also the same on each row. gg.
The object factories (for specs) are a mess, and often create objects indirectly, or in backwards order with odd post-create overwriting to make things work. Following the factories is a major chore, let alone fixing or extending them.
The new type has practically zero test coverage.
The factory for the new type also only creates one variant -- and does so incorrectly.
And to top it all off: the guy who wrote the feature barely ever responds. If he does, he uses fewer words than my bird knows, then stops responding. I've yet to get a useful answer out of him. (and he apparently communicates just fine, according to my micromanager.)
But "it's just fixing a report; it'll be easy!"
Oh, fuck off.8 -
Hiring process is fucking broken ok?
We all do have something else to do, nobody wants to do "homework" for 4 fucking hours. Which let's be real, isn't 4 hours. It's always more. I try to squeeze it in a least amount of time which means mistakes will be made. I always try to show my knowledge of the language and it's features. But, you didn't do X. That's it, that is a no from us.
Dude, I just wrote a high production grade small project with 90%+ test coverage and you are telling me that those 2 small shit I made is a big deal? Fuck off
Most companies I worked with have a code full of shit and here I present to you, with a poetry and it's a no because of X?
My bet is that if I ever started to work there I would find a code that isn't tested and is in shit state
\rant4 -
21 lines of business logic (including whitespace and comments)
9 lines of build config
386 lines of tests (and tests for the tests)8 -
That feeling when you’ve got a reputation of preciseness etc, and the code you just submitted for review has so many silly little mistakes you just want to do that ostrich thing. Gosh, how can I suddenly suck at my job this bad?
Okay, the changes affect EVERYTHING in our codebase (a major change in core business logic), and there is no way I could’ve tested every possible case by myself without a decent coverage of automated tests - which we obviously don’t have. So yet another argument for it (damn management, won’t you listen?!)… but still, some of the mistakes found during code review make me seem like a complete idiot.9 -
My biggest problem with Visual Studio Code is that every fucking piece of shit dev thinks it's their duty to introduce it to me. STOP. Just stop this shit, alright? Wanna use vscode? Fine, just don't tell me it's the best tool and I MUST use it instead of the tools I'm used to. I'm tired of this bullshit.
Every new project, every new team. Starting from js/java/.net monke and ending with PMs, I must hear this bullshit about god blessed IDE that I must use, because "why you need intellij/webstorm/rider? just install vscode and some plugins. we all use it in our project and it's ok".
FUCK YOU! Refactoring is not just renaming variables and extracting blocks of code into functions. If you want terminal integrated into your text editor with highlighting and LSP support, so be it. I want an IDE with rich refactoring tools, code analysis and good completion, database viewing/modeling support, good build tools support, good UI for git and git-diff, good test and code coverage support. I don't want your semi-IDE, bloated with hundreds of bugged third-party plugins, which I must spend a week on to configure and merry with each other before using.
JUST STOP this crap and let people use the tools they are proficient/comfortable/productive with.18 -
Killing people is bad. But, there should be a law to allow killing people who don't write proper unit tests for their code. And also those "team leaders" who approve and merge code without unit tests.
Little backstory. Starts with a question.
What is the most critical part of a quoting tool (tool for resellers to set discounts and margins and create quotations)? The calculations, right?
If one formula is incorrect in one use case, people lose real money. This is the component which the user should be able to trust 100%. Right?
Okay. So this team was supposed to create a calculation engine to support all these calculations. The development was done, and the system was given to the QA team. For the last two months, the QA team finds bugs and assigns those to the development team and the development team fix those and assigns it back to the QA team. But then the QA team realizes that something else has been broken, a different calculation.
Upon investigation, today, I found out that the developers did not write a single unit test for the entire engine. There are at least 2000 different test cases involving the formulas and the QA team was doing all of that manually.
Now, Our continuous integration tool mandates coverage of 75%. What the developer did was to write a dummy test case, so that the entire code was covered.
I really really really really really think that developers should write unit tests, and proper unit tests, for each of the code lines (or, “logical blocks of code”) they write.20 -
gradle is infuriating.
firstly there are so limited resources to understand how it's building a java/android code. everything happens by magic and hit+trial
secondly the plugins and the tasks works in mysterious ways. sometime they work when applied in the project root's gradle file, other times they work when applied in module's gradle file, nd other times they need configuration at both levels.
then there are gradle tasks like build ,test, assemble , clean etc. these are less of an action and more of an alias to run a bundle of actions.
then we have 3rd party plugins which attach themselves to these "fat-actions" and run before/after them
and finally we have the fuckup from the java world where the only available code coverage plugin is jacoco and IT FUCKING SUCKS!!! it is a test environment plugin, it should impact test tasks , but somehow it's fucking with the assemble taskin such a manner, that the jars ans aar files generated via plugin are giving runtime errrors. yes , runtime! as if we are back in the messed up js world of "everything is good unless running live"
even if it was a compile time eeror, i would have considered. but runtime?!! fucking runtime error?! i barely understand this shit, there is absolutely no info available as to which classes are being used to create a build and how, and i am supposed to fix this? wtf?!4 -
In my company we are constricted to have 100% of f̶a̶k̶e̶ coverage with unit test.
Obviously the test suites are not performing and it takes more than 8 minutes to run 3335 tests.
I know that what I'm going to say is super mainstream but there is nothing comparable to the relief that comes from seeing all tests in green after you did a lot of small changes around the code on Friday.4 -
My fellow developer was given a responsibility of writing unit test cases.
And instead of mocking the db calls he ended up making actual calls to db and adding realtime data to firestore everytime a test runs. Also he used mocha for the same. When i told him that we need to mock the db calls he said he will use sinon.js for the same and for code coverage his plans were to use istanbul.
I was like FUCKKKKKKK. , why the fk you aren't using jest. I mean whyyyyyyyy. WHAT THE FK4
Top Tags
Weekly Rant
View