Details
Joined devRant on 7/6/2017
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
-
- Cookie warnings
- Autoplay videos
- "It's better on the app!"
- Surprise paywall
- Newsletter popups
- "Sorry, this content is not available in your region!"
- Lazily paraphrasing another website without disclosing the source in an obvious way
- Anti-adblock popups
- "Become a pro-member today: starting at $4.99/month!"
- "Sign up here to get my free e-book! :)"
- "keep reading" button to load the rest of the damn article
- "We have a podcast!"
- ...
I hate the current state of the web.13 -
User: *Clicks on staging environment*
Giant Warning Dialog: YOU ARE CURRENTLY ENTERING THE STAGING ENVIRONMENT
Users: Ok
App: *Completely different colour, I’m talking bright unsightly yellow*
User: Ok
Giant Yellow and Red Flashing Banner at the Top of the Screen: WARNING YOU ARE CURRENTLY USING STAGING, THIS AREA IS FOR TESTING ONLY
User: The production environment sure is acting strange today. It’s a weird colour and I don’t recognize any of the data, it’s all just dummy filler data. I better create a ticket for the dev team to check o—….. no wait I’ll send an email CC everyone including the CEO and sound the alarm production is currently down and filled with giant warning messages.
Manager: OH MY GOD PRODUCTION IS DOWN DID YOU HEAR ABOUT THIS??? WHAT THE FUCK COULD THESE WARNING MESSAGES BE THAT’S ONLY SUPPOSED TO HAPPEN ON STAGING! THE CEO IS BREATHING DOWN MY NECK YOU NEED TO GET THIS FIXED IMMEDIATELY!!!!!!!
Dev: …13 -
This is so fucking relatable.
Everytime there's atleast one dumbass in the organisation who frequently does this exact thing.
9 -
Given a couple of lines of code, I can predict with an 80% accuracy which of my team mates wrote it.9
-
Manager: We need to setup the security in the Mexico server
Dev: You mean that 3rd party firewall add on?
Manager: Yes
Dev: And set up the billing on the Mexico account?
Manager: Yes
Dev: lol, sure thing I’ll create the ticket
Manager: What’s so funny?
Dev: Nothing
Ticket: Build wall and get Mexico to pay for it.15 -
I've seen a job vacancy that asks for the following characteristics in a developer:
- extraverted, do'er (as opposed to thinker), out-of-the-box, curious, sees solutions and not problems, structural thinking vs. theoretical thinking, loves change, acts immediately, makes choices under stress, critically questions themselves if things go wrong
What the [censored] kind of programmer is that? Sounds more like a wannabe brogrammer type.
A typical, real programmer is introverted (for he is introspective, detail-minded and is therefore good at inspecting problems and finding solutions for them).
Seeing problems is not a bad thing, it's in fact necessary to be able to identify issues and not act like your typical manager who only wants to rush to solutions. He thinks deeply and theoretically before he takes action. Theory is the foundation of identifying a problem.
What programmer is stress-resistant? It's not normal for the human brain to be able to deal with stress; this is why switch-tasking is so hard.
Question yourself if things go wrong? Perhaps, but this sounds more like trying to shove the blame around.
Since we live in a rigid computer world with rigidly-defined protocols (say, HTTP), it is often useful to think in a conventional way. Out-of-the-box? Sure, if you're being innovative, or sure, as a tangential characteristic.
In my professional opinion, this vacancy reeks of bad corporate culture.. and the biggest alarm bell I find is: "There is free beer!" Err.. yeah. Anyway.17 -
So today in discord one guy cracked this banger:
"Engineering in a nutshell"
Engineer A: *explains for 20minutes how to solve the problem in a very complex way*
Engineer B: "Or you could just put a screw here"
A: Dude that can't....
A: Fuck you you're right
B: you're welcome
Applicable in any engineering department, software included! xD8 -
1. I join a company.
2. I get deeply involved in "how to run the company", and get nice compliments from both coworkers & management about my skills in conveying startup/scaleup advice & necessities to upper management.
3. With my ego inflated through all the sweet talk, I think "ah, what the hell, let's do this again", and I accept a Lead/CTO promotion. I have to join board meetings, write reports on quarterly plans and progress.
4. I get unhappy/stressed/burned-out because I really just want to be a developer, not a manager/executive.
5. Upper management understands, I give up my lead position, lock myself back into my coding cave.
6. I get annoyed because the requirements I receive become more and more disconnected from reality, half of the teams seem to have decided to stop using agile/scrum, the testing pipeline breaks all the time, I get an updated labor contract from HR by mail which smells like charred flesh, etc
7. The annoyances become too much to do ANY work. I yell at the other devs outside of the entrance of my cave. There is no answer, only a few painful moans and sighs.
8. I emerge from my cave. The city has turned into a desolate wasteland. The office is a burning ruin, the air sharp and heavy with black soot. Disemboweled corpses of developers litter the poisoned soil.
Product Managers dressed in stained ripped suits scream at each other while they try to reinforce concrete barricades with scotch tape and post-its. *THUMP* Something enormous is trying to break through. "Thank God, bittersweet, you're still alive! The stakeholders! They have mutated! We couldn't meet the promised deadlines! We've lost the whole mobile app department, and that kid there is the last of the backenders and he's only an intern! You're here to save us, right? RIGHT?".
In the corner, between the overflowing coffee machine and a withered cactus, a young boy has collapsed onto the floor. His face is covered in moldy coffee grounds, clasping on to his closed macbook for dear life, wide-open eyes staring into the void, mumbling: "didn't backup the database, and It's all gone" over and over.
A severely dented black Tesla with a dragging loose bumper breaks through the dried up vertical herb garden and the smoothiebar, and comes to a halt against the beanbags in a big cloud of styrofoam balls.
The CEO limps out, leaking blood all over the upholstery. He yells to the COO: "The datacenter is completely flooded with sewage! I saved the backup tapes though", holding a large nest of tangled black magnetic tape mixed with clumps of mud above his head.
9. I collect my outstanding salary and sell any rewarded options/shares for a low dumping price, take a 5 month holiday, and ask a recruiter about opportunities in a different city.14 -
Thursday: Hey wife…. I finished my project and tomorrow I should have a very easy day, just watching Slack.
Friday: Database— corrupted bin logs, major production outages.
Wife: 😡I can never believe you when you say you’ll have an easy day.3 -
A seasoned colleague just wrote this and I think it was very valuable:
On tech debt:
So the big challenge with technical debt is making non-technical management (CEO, COO, CFO, directors) understand what it means, and just how it operates. Sometimes it actually makes good sense to incur technical debt to get to market sooner, just as it sometimes makes sense to borrow money to get cash now and repay that loan later with (hopefully) resulting greater revenues from that investment. But just like a loan, tech debt always has to be paid some day. The longer the tech debt goes, the more expensive it gets. And also like a loan, the cost compounds, like compound interest on a loan. Tech debt should always be chosen with a clear plan to pay it off at some point in the not too distant future. The longer one waits to pay it, the more expensive it gets.7 -
Universal law of side projects:
The motivation to invest more time in side projects is inversely proportional to the free time you have!
When you have a deadline, you want to work on 10 new things, as soon as you are completely you just want to a lazy sloth!4 -
So HR invited us to a mandatory hour long talk on why rest and relaxation is important for work efficiency.
On a Saturday.
You can’t make this shit up.15 -
I am fed up working with unskilled software developers. Or to be more specific, working with people who have no idea of sofware architecture.
Most people I've worked with have simply no idea what they are doing in the broad picture, they can only follow patterns they see and implement their feature in the same way. They can't think about the abstract concepts which should be the foundation of the project.
They fail to write unit tests which are maintainable. They write one fucking test per method which is testing 50 things at the same time, making it often impossible to understand what is being tested.
They think putting stuff in private methods makes their class better and is some kind of separation of concerns.
They write classes and afterwards create interfaces for these classes named {Class}Interface, shoving all the methods into that interface. They think it's good design to do so.
They are unable to think about the reasons why things are done the way they are done and that you don't do stuff for the sake of doing stuff, but to achieve certain goals like interchangeability.
They don't undestand how to separate business logic from the application code.
They have no sense for naming things beautifully. They don't see how naming things is a major part of good software architecture.
They get layer concepts wrong and then create godlike {EntityName}Service classes, which do everything related to a particular entity.
They fail to shape the boundaries within a software project, entangling stuff which should live in individual modules.
All I want is to work in a team with professionals.2 -
I've been trying out no-code solutions for a while and I have found some awesome products out there that are super easy to setup and get running, but fuck me, I never thought I would find something so magnificent, so well planned and executed and fits into a tiny package.
No bloatware, no package dependencies, no nothing.
https://github.com/kelseyhightower/...9 -
Me: Optimize a sort & match method in backend because users complain it's a bit slow.
Coworker: These algorithms are both O(n), so they're identical *closes PR*
Me: *start zoom call* "Heeeeeeeeeey Iiiiiiiiiii wouuuuuuuld liiiiiiiiike toooooo diiiiiisscuuuuus thaaaaaaaat puuuuuuulllll reeeeeequuuueeest yooooouuuuu cloooooossseeeed"
Coworker: "wtf are you doing, why are you talking so slow"
Me: "No matter whether I talk fast or slow, the information still reaches you in O(n) time, so why are you complaining"
I fucking hate it when people misunderstand the purpose of (or abuse) big O notation. It's an estimate of how an algorithm SCALES once the set increases in size, in which case you leave out both less significant terms and constant factors.
But those terms and factors are important when you're talking about the DIRECT PERFORMANCE of the algorithm on fixed-size sets, instead of SCALING to larger sets.
1n and 10n are both O(n), but 10x performance on a job that used to take 10 minutes is still significant.19 -
Question: Why did the DataBase Administrator divorce his wife?
.
.
.
.
Answer: She had "one-too-many" relations6 -
Why is it that pretty much zero package & framework maintainers understand semantic versioning?
1. If you do a complete rewrite of your package, but the resulting API is identical, you don't need to bump to the next major version. As a user, I'm thankful for your increased performance or cleaner internal code, but it doesn't really affect my update process.
2. If your package required some-framework 6.0.0, and now ALSO supports some-framework 7.0.0 but is still compatible with 6.0.0, you don't need to bump to the next major version. As a user, I can now upgrade the framework, and know that the package will keep working, but otherwise it doesn't really affect me.
3. Following your versioning along with the framework/language version is super annoying, especially if your library really doesn't need to differentiate between framework versions because it's not actually utilizing new framework functionality.
4. On the other hand, if you stop supporting a certain language, framework or shared library version, or change the public methods, exceptions, fields, etc, you MUST bump to a new major version.
Yet everyone gets this wrong.
For example, many of Laravel's underlying subpackages (for collections, filesystem, database, config, http, mail, etc) do not change their code in a breaking way, or do not even change at all between major framework versions.
Yet they follow along with the major framework version.
Now if someone makes a library "laravel-elasticsearch" which uses the support libraries and collections from laravel, they need to update their package to move along with the versions as well, and often they choose to number their library along with the framework in turn.
This means that to update the framework, you also need to update over 9000 dependencies.
FOR NO FUCKING REASON. THE ONLY CHANGE IN THOSE FUCKING DEPENDENCIES IS TO UPDATE COMPOSER.JSON TO BE COMPATIBLE WITH THE FUCKING FRAMEWORK.
Meanwhile, Laravel itself breaks repeatedly on minor/patch version updates, because breaking changes slip through their review process.
Ugh.3 -
1. You don't code to add a feature or whatever. You do it to solve Users' problems. It's a User-centric system.
2. You read more code than you write. So help yourself and write code intended to be read.
3. If people don't know you did something, you did nothing!
4. Never answer a call at 3 am if you're not paid to be on night call-duty. You'll become the guy who answers at 3 am.
5. Remember the big difference between you and me is that I failed to do stuff more times than you have tried to do.
6. When you start shaving the yak, stop!10 -
A friend of mine removed a paywall deleting the DOM element that covered the page and all functionality from the site was intact.9
-
To be a good developer, you must thrive in chaos, and have an insatiable desire to turn it into order.
All user input, both work tasks and actual application input, is pure fucking chaos.
The only way to turn that input into anything usable, is to interpret, structure and categorize it, to describe the rules for transformation as adequately as you can.
Sometimes companies create semi-helpful roles to assist you with this process. Often, these people are so unaware of the delicacy of the existing chaos, that any decision they make just ripples out in waves leaving nearly irreparable confusion and destruction in its path.
So applications themselves also slowly wear down into chaos under pressure of chaotic steak-holders which never seem to be able to choose between peppercorn or bernaise sauce for their steaks.
Features are added, data is migrated between formats, rules become unclear. Is ketchup even fucking valid, as a steak sauce?
The only way to preserve an application long term, is refactoring chaos into order.
But... the ocean of chaos will never end.
You must learn to swim in it.
All you can hope to do is create little pools of clarity where new creative ideas can freely spawn.
Ideas which will no doubt end up polluting their own environment, but that's a problem for tomorrow.
So you must learn to deal with the infinite stream of perplexed reactions from those who can't attach screenshots to issue reports.
You must deflect dragging conversations from those who never quite manage to translate gut feeling into rational sentences.
You must learn to deal with the fact that in reality there are no true microservice backends. There are no clean React frontends. There are no normalized databases. Full test coverage, well-executed retrospectives, finished sprints -- they are all as real as spherical cows in a vacuum.
There is no such thing as clean code.
There is only "relatively cleaner code", and even then there are arguments as to why it would be "subjectively relatively cleaner code".
Every repository, every product, every team and every company is an amalgamation of half-implemented ideals, well-intended tug of war games, and brilliantly shattered dreams.
You will encounter fragmented shards of perfect APIs, miles of tangled barbed documentation, beheaded validator classes, bloody mangled corpses of analytical dashboards, crumbled concrete databases.
You must be able to breathe in those thick toxic clouds of rotting technical and procedural debt, look at your reflection in the locker room mirror while you struggle yourself into a hazmat suit, and think:
"Fuck yes, I was born for this job".24 -
Wanna mess with users? Take
“OK” and “Cancel”.
You know what looks visually the same but means the opposite?
“NO” and “Confirm”.
Deploy that little ui update overnight and watch the world burn.20
