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
-
The university system is fucked.
I've been working in this industry for a few years now, but have been self taught for much longer. I'm only just starting college and I'm already angry.
What does a college degree really mean anymore? From some of the posts I've seen on devRant, it certainly doesn't ensure professional conduct, work ethic, or quality (shout out to the brave souls who deal with the lack of these daily). Companies should hire based on talent, not on a degree. Universities should focus more on real world applications or at least offer such programs for students interested in entering the workforce rather than research positions. A sizable chunk of universities' income (in the U.S. at least) comes from research and corporate sponsorships, and educating students is secondary to that. Nowadays education is treated as a business instead of a tool to create value in the world. That's what I signed up for, anyway - gaining the knowledge to create value in the world. And yet I along with many others feel so restricted, so bogged down with requirements, fees, shitty professors, and shitty university resources. There is so much knowledge out there that can be put to instant practical use - I am constantly shocked at the things left out of my college curriculum (lack of automated tests, version control, inadequate or inaccurate coverage of design patterns and philosophies) - things that are ABSOLUTELY essential to be successful in this career path.
It's wonderful that we eventually find the resources we need, or the motivation to develop essential skills, but it's sad that so many students in university lack proper direction through no fault of their own.
Fuck you, universities, for being so inflexible and consistently failing to serve your basic purpose - one of if not the most important purpose on this earth.
Fuck you, corporations, for hiring and paying based on degree. Fuck you, management, for being so ignorant about the industry you work in.
Fuck you, clients, who treat intelligent people like dirt, make unreasonable demands, pull some really shady shit, and perpetuate a damaging stereotype.
And fuck you to the developer who wrote my company's antipattern-filled, stringy-as-all hell codebase without comments. Just. Fuck you.17 -
Dev manager: great news guys. We’ve built a new tool to do automated testing on apps. We’ve gotten rid of the old Appium solution we were using and built this new one.
Me: why not just use the inbuilt native stuff? Click to record works really well.
Manager: nah we thought it would be more flexible to build it ourself.
Me: ... ok ... moving on ... how does it work?
Manager: well this new .jar, you download it, pass in a config file, setup up your simulator and appium and the jar will do everything for you.
Me: ... wait you said you hate Appium? Now you’ve built a wrapper around it? And it doesn’t even set everything up, you’ve to do it all by hand?
Manager: oh we had too, would be too much effort to replace it. Don’t worry we can now write all our tests in .yaml config files instead of using Appium.
Me: so we’ve lost the ability of auto-complete and type ahead, everyone has to upskill on a new tool, it offers no new features over what’s available out of the box and we’ll have to deal with new bugs and maintenance and stuff our self ... because we need more flexibility?
Manager: oh don’t worry. The guy who built it is staying here. He’s going to deal with bug fixes and add features. He’s only one guy, but he’s really sharp, it’ll be great for us and the team.
Me: ... ... ...
*audible noise of soul breaking*
Me: ... ok thank you. I’ll look into this new tool3 -
No boss... For the fucking millionth time: unit tests are not a waste of time.
You keep testing everything manually and hoping that you tested everything every time and praying that there are no bugs IS THE FUCKING TIME WASTE
My boss just can't fucking wrap his head around automated tests... I'm trying hard... Gonna try harder...6 -
I got a call at 12:30 one night a few months back. Apparently some back-end scripts I edited to fix an automated test setup crashed around 75 test pc's and halted somewhere around 2000 tests. I quickly jumped on, fixed the issue, and got everything back online.
I was up all night certain I would get fired. First thing in the morning the client says welcome to the club some, of the best have done the same thing.2 -
The company i work for has a jenkins server (for people that don't know jenkins, it's an automated build service that gets the latest git updates, pulls them and then builds, tests and deploys it)
Because it builds the software, people were scared to update it so we were running version 1.x for a long time, even when an exploit was found... Ooh boy did they learn from that...
The jenkins server had a hidden crypto miner running for about 5 days...
I don't know why we don't have detectors for that stuff... (like cpu load being high for 15 minutes)
I even tried to strengthen our security... You know basic stuff LIKE NOT SAVING PASSWORDS TO A GOOGLE SPREADSHEET! 😠
But they shoved it asside because they didn't have time... I tried multiple times but in the end i just gave up...13 -
Today I fell down the rabbit hole.
I've been writing some automated tests which found an asymmetry in our algorithm which I think is caused by an off by 1 in even input dimensions.
Change input to odd dimensions, crash due to out of bounds exception.
Switch to debug mode to try to work out why we crash, failing asserts for default function arguments with no obvious reason beyond a helpful message saying they're unsupported.
2 -
I think I want to quit my first applicantion developer job 6 months in because of just how bad the code and deployment and.. Just everything, is.
I'm a C#/.net developer. Currently I'm working on some asp.net and sql stuff for this company.
We have no code standards. Our project manager is somewhere between useless and determinental. Our clients are unreasonable (its the government, so im a bit stifled on what I can say.) and expect absurd things from us. We have 0 automated tests and before I arrived all our infrastructure wasn't correct to our documentation... And we barely had any documentation to begin with.
The code is another horror story. It's out sourced C# asp.net, js and SQL code.. And to very bad programmers in India, no offense to the good ones, I know you exist. Its all spagheti. And half of it isn't spelled correctly.
We have a single, massive constant class that probably has over 2000 constants, I don't care to count. Our SQL projects are a mess with tons of quick fix scripts to run pre and post publishing. Our folder structure makes no sense (We have root/js and root/js1 to make you cringe.) our javascript is majoritly on the asp.net pages themselves inline, so we don't even have minification most of the time.
It's... God awful. The result of a billion and one quick fixes that nobody documented. The configuration alone has to have the same value put multiple times. And now our senior developer is getting the outsourced department to work on moving every SINGLE NORMAL STRING INTO THE DATABASE. That's right. Rather then putting them into some local resource file or anything sane, our website will now be drawing every single standard string from the database. Our SENIOR DEVELOPER thinks this is a good idea. I don't need to go into detail about how slow this is. Want to do it on boot? Fine. But they do it every time the page loads. It's absurd.
Our sql database design is an absolute atrocity. You have to join several tables together just to get anything done. Half of our SP's are failing all the time because nobody really understands the design. Its gloriously awful its like.. The epitome of failed database designs.
But rather then taking a step back and dealing with all the issues, we keep adding new features and other ones get left in the dust. Hell, we don't even have complete browser support yet. There were things on the website that were still running SILVERLIGHT. In 2019. I don't even know how to feel about it.
I brought up our insane technical debt to our PM who told me that we don't have time to worry about things like technical debt. They also wouldn't spend the time to teach me anything, saying they would rather outsource everything then take the time to teach me. So i did. I learned a huge chunk of it myself.
But calling this a developer job was a sick, twisted joke. All our lives revolve around bugnet. Our work is our BN's. So every issue the client emails about becomes BN's. I haven't developed anything. All I've done is clean up others mess.
Except for the one time they did have me develop something. And I did it right and took my time. And then they told me it took too long, forced me to release before it was ready, even though I had never worked on what I was doing before. And it worked. I did it.
They then told me it likely wouldn't even be used anyway. I wasn't very happy at all.
I then discovered quickly the horrors of wanting to make changes on production. In order to make changes to it, we have to... Get this
Write a huge document explaining why. Not to our management. To the customer. The customer wants us to 'request' to fix our application.
I feel like I am literally against a wall. A huge massive wall. I can't get constent from my PM to fix the shitty code they have as a result of outsourcing. I can't make changes without the customer asking why I would work on something that doesn't add something new for them. And I can't ask for any sort of help, and half of the people I have to ask help from don't even speak english very well so it makes it double hard to understand anything.
But what can I do? If I leave my job it leaves a lasting stain on my record that I am unsure if I can shake off.
... Well, thats my tl;dr rant. Im a junior, so maybe idk what the hell im talking about.16 -
boss: we should map all the possible ways to do things in the system so we can test them and make sure we fix the bugs.
Me: yeah, well, that is exactly what automated tests are for, every time we find a non-mapped way that breaks this we make a test out of it and fix, this ways we end up mapping the majority of ways.
Boss: yeah,yeah ... Let's sit down latter and map everything on a document.
I bet my ass we are never gonna have tests as a part of our workflow.3 -
Red flags in your first week of your software engineering job 🚩
You do the first few days not speaking to anyone.
You can't get into the building and no one turns up until mid day.
The receptionist thinks you're too well dressed to work in this building, thinks you're a spy and calls security on you.
You are eating alone during lunch time in the cafeteria
You have bring your own material for making coffee for yourself
When you try to read the onboarding docs and there aren't any.
You have to write the onboarding docs.
You don't have team mates.
When you ask another team how things are going and they just laugh and cry.😂😭
There's no computer for you, and not even an "it's delayed" excuse. They weren't expecting you.
Your are given a TI PC, because "that's all we have", even though there's no software for it, and it's not quite IBM compatible.
You don't have local admin rights on your computer.💀
You have to buy a laptop yourself to be able to do your job.
It's the end of the week and you still don't have your environment set up and running.
You look at the codebase and there are no automated tests.
You have to request access every time you need to install something through a company tool that looks like it was made in 2001.
Various tasks can only be performed by one single person and they are either out sick or on vacation.
You have to keep track of your time in 6 minute increments, assigned to projects you don't know, by project numbers everyone has memorised (and therefore aren't written down).
You have to fill in timesheets and it takes you 30 minutes each day to fill them in because the system is so clunky.🤮
Your first email is a phishing test from the IT department in another country and timezone, but it has useful information in it, like how to login to the VPN.
Your second email is not a phishing test, but has similar information as the first one. (You ignore it.)
Your name is spelled wrong in every system, in a different way. 2 departments decide that it's too much trouble, and they never fix the spelling as long as you work there. One of them fixes it after you leave, and annoys you for a month because you haven't filled out the customer survey.6 -
I'm a jr developer. I started off in automation testing and don't mind it but the testing codebase is cancer, doesn't follow basic Java conventions even basic naming conventions like camelcase, and the tests are super slow using hardcoded Thread.sleep(). Since the automation tests are not automated, I have to run manually. YES manually, every morning I wake up early at 7am to run the 2.5 hour long tests (7am because this before people get to work and when the application goes back online). I run this bitch and monitor them but most of them fail anyways. I also have to write a email report on the results which means I have to explain why shit is failing so I have to debug all this crap. This shit literally eats up an additional 2-3 hours of my work day everyday and the time is not even accounted for. ALSO, since it's running on my laptop, it makes my computer slow most of the day. If I have to debug, I can't have the browser be headless so fuckin chrome browsers be popping up every 2 minutes. I did this for legitimately 8 sprints until I decided enough was enough and bitched about it and the team told me I had no choice. I eventually got them to push towards automating it but it's still in progress so I'm still running this dumb shit. The contractors try to take advantage of me any way they can by giving me mindless bitch work they don't want and they know I don't usually say no since I'm a jr resource. I hate running the fucking automation tumor. Sometimes I go into the meeting rooms alone to scream.
I feel like I'm wasting my life away and not learning as much as I could somewhere else10 -
Oh, my boss never fails to amaze me...
Every fucking time he talks about changes to someone outside the team he says something like:
"we always gotta be prepared for breaks because it is always like that, you change something here and when you see you broke something there"
All in a manner that *tries* to bring tensions down.
And every time I explain to him why the fuck automated tests are important and wtf they do he always manage to understand it as a waste of time...
I'm never gonna give up, motherfucker.2 -
Once upon a time, one or two jobs ago, a really awesome engineer specced out a distributed search application in response to a business need. This company was managed pretty oldschool and required a ton of paperwork and approvals.
The engineer spent many weeks running tests and optimizing the hell out of this app cluster. It flew, and he had the data to prove it could handle production workloads (think hundreds of terabytes of data being processed every single day)
Part of the way he achieved this was having RAID0 on all of the servers to maximize I/O throughput. He didn't care much about data loss, since the application itself was fault tolerant on a much more granular level.
Management, hearing about this, absolutely flipped their shit and demanded RAID6 instead. This despite the conclusive data that the engineer had that proved RAID6 couldn't keep up.
He more or less got told to STFU.
Even this despite the fact that a RAID restripe would actually take many times longer than rebuilding the failed node from scratch (a process that took about 30 minutes by hand, and could probably be automated to be done in less than five), causing a longer exposure to actual data loss throughout the length of the days-long array rebuild time.
The ill-thought-out requirement added about 50% to the cost of the project (*many* more hard drives now required), beyond the original budget, and the subsequent bureaucratic wrangling resulted in a late product launch.
6 months or so later, after real customers were using this product, the app was buckling under around half of its expected workload. A friend of the engineer suggested to management to try RAID0. Sure enough, that resolved the I/O bottleneck.
This rage-inducing story has a happy ending, though! Said engineer left the company not long after this incident, citing it as a reason for his departure. He was immediately hired by another company, making integer multiples of his prior salary.
The product the company botched the launch of by ignoring his spec? It died a few months later. Maybe the poor customer experience was to blame? Maybe the late launch? Maybe it was another reason entirely.
Either way, millions of dollars of hardware now sat fallow. This was a black eye on the company all the way up to the C-level.
tl;dr: Listen to your engineers. You hired them for their expertise.5 -
Yeah, hiring people solely to write unit tests is a completely reasonable thing to do, i mean, its not like unit tests are a perfectly repetitive task that could easily be automated or anything...5
-
Blue Robotics
This company makes underwater thrusters for submarine applications. With their first thruster they made it easy to make a homemade submarine. The motor was powerful, the thruster just worked. They even had a promotional where they created an automated surfboard that made it from hawaii to somewhere in california with one of their thrusters pushing it there the entire way. It was a great product.
Then they created the next version. This was the same thruster, but it had an ESC(Electronic Speed Controller) sealed in an aluminum puck on top of the motor. This ESC could be controlled by servo controls, or by plugging it into an i2c bus. You could pull different stats off of the motor over i2c it sounded great. So my robotics team trusted this company and bought 8 motors at $220 - $250 bucks each. We lightly tested them since we had not even finished the robot yet. One week before the competition our robot got completely put together and we did our first few tests.
Long story short, Us and 22 other teams did roughly the same thing. We bought these motors expecting them to work, but instead the potted aluminum ESCs were found defective. Water somehow got into the completely resin sealed aluminum puck and destroyed the ESC. We didn't qualify that year due to trusting a competition sponsor to deliver a good product. I will admit that it was our fault for not testing them before going to the competition. Lessons were learned and an inherent distrust of every product I come across was developed. -
Our project at work goes live in 3 weeks.
The code base has no automated tests, breaks very often, has never had any level of manual testing
will not be releasing with any form of enforced roles or permissions in our first release now due to no time to enforce, however there is a whole admin api where you can literally change anything in our database including roles.
We also have teams in various countries all working separately on the same solution using microservices with shared nuget packages and they aren't using them properly.
Our pull requests are so big - as much as, 75 file changes - in our fe app that I can't keep up with it and I honestly have no idea if it even works or not due to no automated tests and no time to manually test.
We have no testing team, or qa team of any sort.
Every request into the system has to hit a minimum of 3 different databases via 3 different microservices so 1 request = 4 requests with the load on the servers.
We don't use any file streams so everything is just shoved in the buffer on the server.
Most of the people working on the angular apps cba to learn angular, no one across 2 teams cba to learn git. We use git so they constantly face problems. The guy in charge has 0 experience in angular but makes me do things how he wants architecturally so half the patterns make no sense.
No one looks at the pull requests, they just click approve so they may as well push directly to master.
Unfinished work gets put in for pull request so we don't know if the app is in a release state since aall teams are working independently, but on the same code base.
I sat down and tested the app myself for an hour and found 25 fe only issues, and 5 breaking cross browser issues.
Most of our databases are not normalised. Most of our databases make no sense. 99% of our tables have no indexing since there is no expertise with free time to do it.
No one there understands css properly. Or javascript.
Our. Net core microservices all directly use ef in the controller actions so there is no shared code there.
Our customer facing fe app is not dry because no tests so it was decided it was better this way.
Management has no idea on code state, it seems team lead is lieing to them about things like having any level of tests.
Management hire devs that claim to be experts but then it turns out they have basically no knowledge of what they were hired to do, even don't know what json is or the framework or language they are hired for, but we just leave them to get on with it and again make prs too big to review.
Honestly I have no hope that this will go well now but I am morbidly curious to watch. I've never seen anything like the train wreck that we are about to get experience.5 -
Was talking about how I implemented CI/CD in one of our projects as a starting point to others and how it worked by running tests and deploying to the server and one of my colleagues laughed about having to have tests at all, I explained and asked him what was he gonna do that morning, his answer:
"Well, I'm gonna test the system X and fix some bugs"
To what I replied:
"If you have automated tests you could have those tests automatic(?!) and they also help you finding bugs early"
Wtf do ppl have in mind that they prefer remediation over prevention and they end up wasting their time with shit that could be fully automated?2 -
Still on the primenumbers bender.
Had this idea that if there were subtle correlations between a sufficiently large set of identities and the digits of a prime number, the best way to find it would be to automate the search.
And thats just what I did.
I started with trace matrices.
I actually didn't expect much of it. I was hoping I'd at least get lucky with a few chance coincidences.
My first tests failed miserably. Eight percent here, 10% there. "I might as well just pick a number out of a hat!" I thought.
I scaled it way back and asked if it was possible to predict *just* the first digit of either of the prime factors.
That also failed. Prediction rates were low still. Like 0.08-0.15.
So I automated *that*.
After a couple days of on-and-off again semi-automated searching I stumbled on it.
[1144, 827, 326, 1184, -1, -1, -1, -1]
That little sequence is a series of identities representing different values derived from a randomly generated product.
Each slots into a trace matrice. The results of which predict the first digit of one of our factors, with a 83.2% accuracy even after 10k runs, and rising higher with the number of trials.
It's not much, but I was kind of proud of it.
I'm pushing for finding 90%+ now.
Some improvements include using a different sort of operation to generate results. Or logging all results and finding the digit within each result thats *most* likely to predict our targets, across all results. (right now I just take the digit in the ones column, which works but is an arbitrary decision on my part).
Theres also the fact that it's trivial to correctly guess the digit 25% of the time, simply by guessing 1, 3, 7, or 9, because all primes, except for 2, end in one of these four.
I have also yet to find a trace with a specific bias for predicting either the smaller of two unique factors *or* the larger. But I haven't really looked for one either.
I still need to write a generate that takes specific traces, and lets me mutate some of the values, to push them towards certain 'fitness' levels.
This would be useful not just for very high predictions, but to find traces with very *low* predictions.
Why? Because it would actually allow for the *elimination* of possible digits, much like sudoku, from a given place value in a predicted factor.
I don't know if any of this will even end up working past the first digit. But splitting the odds, between the two unique factors of a prime product, and getting 40+% chance of guessing correctly, isn't too bad I think for a total amateur.
Far cry from a couple years ago claiming I broke prime factorization. People still haven't forgiven me for that, lol.6 -
I know I'm writing the correct integration tests when each one I add uncovers a new bug.
Still, it would be nice if just one of them passed first time.1 -
My tech debt meltdown is happening right now. We are releasing our huge micro service based product next week with no automated testing of any sort. Our front end clients are relatively DRY. No tests and dry = can't change anything = hacks on top of hacks.
Why? Team lead won't listen to me and has beaten me down so I don't care anymore. If it's broken fuck it.2 -
Starting to feel like shit about my new job. Every task my boss gives me I return with a "sorry it can't be done" for one reason or another. At first it was because user interface testing is a nightmare, then it was because the API postman tests he wanted is for endpoints we haven't exposed so it can't be done and the automated login on postman and retrieval of cookie information can't be done through postman because it requires rendering the site in a browser. I feel worthless to the company but I also feel he keeps making up tasks for me without checking if they're actually useful to us or even possible first, rather than let me touch any of the real code.. I don't know if I should just quit tbh.15
-
Had some fun running automated UI tests today.
Background: My project is a cloud based tool for running automated tests against a 3rd party SaaS product, so when you start a test run, it opens a Firefox window and runs some selenium automation against the 3rd party product.
Our UI tests also open a Firefox window to log into our local env and run some selenium.
Today I tried to run 4 of our UI tests in parallel.
So each test case creates a Firefox instance, and each of those starts a test run which creates another Firefox instance, sometimes 2, depending on the process being tested.
In short, at one point I had 11 different Firefox windows open, all running selenium automation.
My laptop sounded like it was trying to take off... -
This week at work I spent 20 hours debugging automated tests to avoid manual testing that would've taken a few hours.5
-
Two brainfarts that resulted in... a lot of pain
I had been coding all day, ~6hrs. I was in the zone, so I hadn't saved to git. It was all uncommitted changes (you see where this is going...)
Brainfart#1: The code used the "Contact" class, but for some reason my hands typed "Product" in this ONE line.
Brainfart#2: I became aware of Brainfart#1, so I changed the variable from "Product" to "Contact". However, I instinctively pressed F2, "Rename Symbol", instead of just changing the variable I was using. Now ALL of the references to "Product" were to the "Contact" class instead, across all of our code.
I finished coding. I committed and pushed the changes, closed the IDE, and left the desk for a snack. When I came back, the automated tests were failing due to an import error. That's when I noticed my mistake. I couldn't do Ctrl+Z because I had closed the editor. I had to change the names one by one across all of our code. "Contact" and "Product" are probably our two most used classes 😭6 -
The moment when you have crafted a beautiful, flexible and well structured package.
Everything including the automated tests are flawless..
but you cant help but feel like something, somewhere is horrible wrong... :D -
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.7 -
I'm genuinely shocked at the number of people I see on here bashing automated testing as a waste of time, simply because my entire career has taught me the opposite (and it's usually only non-technical managers I see who don't want to see "time wasted" writing tests.)
I'm also just as genuinely curious - what do you guys do instead? Just don't test and deal with production issues as they occur? Pass it off to a separate UAT / human-based testing department and let them sign it off? Assume that because you're using Haskell / some other discipline it'll work if it compiles?14 -
"Manual testing is often quick and easy and satisfying – you can directly test your application, one can see the results immediately on your screen, and one can interact with the application “for real”, instead of in the sometimes-awkward scripted/mocked mode of unit tests. It’s a very natural instinct.
However, it’s also largely-wasted effort! A manual test only verifies the current state of the code base. As soon as you make a change, you’ve started to invalidate the results. If, however, you take the effort to encode the test in code as an automated test, it continues to be valid indefinitely into the future."
https://blog.nelhage.com/2016/12/... -
Wouldn't call it a software bug but related:
Was developing an order system to expand in the UK. We have been developing it for the last 2 years and always had a one nasty bug in the system... Whatever we do, it still appears... Tried debugging to find the source, tried covering with tests - nothing helped it was still there. We even rewrote the whole system 3 times and it still was there!
One day, we have been given a stupid request from our manager - take a black background and make it even more blacker... That was it and I went to the CEO with letter where I stated that we should remove the manager... As I'm the Senior there, he did ask me why and eventually removed the manager...
Oh my guys, I've never felt so good after removing a bug! Since then - our application went live, we had our first customers and we were happily rolling new updates. And the best part - there was no BUG! Everything we did just had undocumented features or missing links but we haven't really had a single bug that was not caught by our automated tests!
---
Moral of the story:
Not only software can have bugs. People also can be "bugs" while bugging you about every single details they think is not working correctly. -
First dev job is my current one.
I'm a software engineer in test, writing automated UI tests for web and mobile apps.
Its pretty great. I work from home with flexible hours. I have a boss but he doesnt manage my dev team, he just checks in to make sure I'm getting support, training and have all my questions answered. My dev team is myself and 2 other people, both of which are cool, and all the work is dev-driven.
Might just stay here until retirement, that sounds easy.2 -
The feeling when your scrum master or lead ask you run the automated tests against the application though they know the application is down or not working.
-
Some of my co-workers are so fucking dumb. Their thought process....
Let's re-run tests that are currently failing over and over until it works
😡
like bitch....fix it then run it! don't just run shit over and over to make yourself look busy.1 -
I love git stash.
It's helps a lot for doing refactors to me. I guess it's not the most complex workflow, but it wasn't obvious to me when I started with git. Let me explain.
Refactors. As you start writing the first lines of a refactor, you start to notice something: you're changing too many things, your next commit is going to be huge.
That tends to be the very nature of refactors, they usually affect different parts of code.
So, there you are, with a shitload changes, and you figure "hey, I have a better idea, let me first do a smaller cohesive commit (let's call it subcommit) that changes a smaller specific thing, and then I'll continue with the upper parts of the refactor".
Good idea, but you have a shitload of changes nearly touching every file in your working copy, what do you do with these changes? You git stash them.
Let's say you stash and try to do that smaller "subcommit". What sometimes happens to me at this point is that I notice that I could do an even smaller change inside this current "subcommit". So I do the same thing, I git stash and I work on that even smaller thing.
At some point I end up `git stash pop`ing up all these levels. And it it shows that git stash is powerful for this.
* You never lose a single bit of work you did.
* Every commit is clean.
* After every commit you can run tests (automated or manual) to see shit is still working.
* If you don't like some changes that you had git stashed, you can just erase them with git reset --hard.
* If a change overlaps between a stash you're applying and the last "subcommit", then
if they differ, git shows conflicts on the files,
if they are identical, nothing happens.
with this workflow things just flow and you don't need to wipe out all your changes when doing simpler things,
and you don't need to go around creating new branches with temp commits (which results in bloated temp commits and the work of switching branches).
After you finish the refactor, you can decide to squash things with git rebase.
(Note: I don't use git stash pop, because it annoys the fuck out of me when I pop and you I get conflicts, I rather apply and drop)4 -
After 3 months of working at my current and first job I inherited a spaghetti codebase with files as large as 1000 lines because my mentor left.
Everything works but dare to change a thing. No Unit tests or any sane practices. At least our CI/CD is automated. 😂
Now I am asked to bend the library backwards in order to integrate it with another product. No one helps me and I am slowly starting to feel devastated. 😩5 -
After building some automated regression tests to verify parts of the company website were working, it was discovered that a test case was missing.
Instead of a constructive meeting about fixing the issue and adding a test, I was reamed and my manager was reamed that we "missed this case".
Nevermind that the automation caught several issues before release in nearly every other aspect of coverage.
Nevermind that the missing test case was a useless feature added after the automation was completed.
Nevermind that automation was meant to be the last stop in the gate, not the first...
I was so livid after that meeting I nearly resigned on the spot. My manager was so livid over being told to write me up he was ready to resign. -
That feel when your job's codebase is well-maintained, extensively covered with unit, integration and full product automated tests, everything is run through continuous integration, and every change has to be scrutinized and reviewed by multiple people; so you have barely anything to devRant about :(
-
this really happened:
Interface Team Lead: "hey I want any time deployments and better QA"
Me: "ok sure. I have CI/CD, but yiu need to work in feature branches / tags, and make sure your code passes automated builds and unit tests"
Team Lead: "I dont have time to test it makes me unproductive! and creating a branch is an extra step which is going to set me back. Im telling the boss you are impacting performance!"
Me: "you want better deployments and QA, but you can even create a branch or tes your work?"
Team Lead: "We have deadlines!" -
Crazy deadlines> Director: "You need to design a new architecture that has failover, multi-AZ, automated deployments, CI/CD pipeline, automated builds/tests as well, for our new SaaS product. You have 3 days to complete it"
Me: "Ok cool. Do we have the new product developed? Can I have the spec docs of the new software, libs and packages required for the env?"
Product Lead: "No we dont have anything yet. The POC is on my local PC, but I dont know what packages are needed to run it"
Me: "So I cant design anything unless I have the minimum requirements to run the new software"
Director: "Just get it up and running in a live environment and we'll take it from there"
Me: *sigh*..this is going to be a big mistake -
We are all about structures, clean code and many other things that make our life easier, right?
Well... It's not all white and black...
As talked many times, projects can be rushed... Client budgets can be low at the start and only then grow...
Let me take an example:
Client X needs a tool that helps his team perform jobs faster. They have a $500 budget. So... Testing, clean architecture and so on - are not really a viable option. Instead, you just make it work and perform that task as needed. So the code has minimal patterns, minimal code structure, a lot of repetitive parts and so on.
Now... Imagine that 3 months pass by without any notice and clients are ultra happy with the product. They want more things to be automated. They contact developers and ask for more things. This time they have a bigger budget but short timeframe.
So once again, you ignore all tests, structure and just make it work. No matter what. The client is happy again.
A year passes and the client realizes that their workflow changed. The app needs total refactoring. The previous developer has no time for adjustments at this point and hires a new company. They look at the code and rants spill out of their mouth along with suicidal thoughts.
So... What would you do? Would you rant about "messy project" or just fix it? Especially since people now have a bigger budget and timeframe to adapt to changes.
Would you be pissed on such a project?
Would you flame on previous devs?
Would you blame anyone for the mess?
Or would you simply get in and get the job done since the client has a "prototype" and needs a better version of it?
---
Personally, I've been in this situation A LOT. And I'm both, the old and new dev. I've built tons of crappy software to make things work for clients and after years - they come back for changes/new things. You just swallow the pill and do what is needed. Why? Well, because it's an internal system and not used by anyone outside their office. Even if it's used outside the office - prototyping is the key. They didn't know if the idea would work or be helpful in any way. Now they know and want it done correctly.6 -
Any professional pentesters or someone working in cybersecurity as a profession? I need some advice. The company I intern with right now wants me to test their web applications for security (they really don't care so much about security). I just wanted to know is there a standard set of procedures or a checklist that is usually followed? I know automated testing is not all that effective against web applications but what are the steps you usually take?
As of now, I have run tests and am now performing a code review but it's in PHP and I'm not really good with it. I'd like to know what more is done as a standard please.2 -
A day in the life of @C0D4
Yay it's Tuesday.....
So morning goes something like coffee, yea no coffee no @C0D4, get to the office, get busy with normal morning routine - run the almost automated scripts I have to run - delete the 100+ emails I don't actually need from last night, read the 2 I do care about - yea 2 freakin emails out of 117 🤦♂️
But what ever that's what outlook rules are for... except I actually have to glimpse over them all just in case something of mine broke.
Go get another coffee,
Start working through the days tickets - ok cool nothing major to worry about, let's get back to writing tests from yesterday.
Well fuck that was a bad decision, no matter what I do this little fucker won't pass, yet doing this process step by step, detail for detail, it works - no issues, but automate this fucker and it screams its head off.
So fine, I give up and go to lunch,
Come back... spend next 3 hours on this 1 problem... 1 FREAKING problem 🤦♂️🥴🤦♂️🥴🤦♂️
This thing has beaten me, and for no apparent reason - it just doesn't like running under a test scenario.
Would have given up hours ago, except its a vital piece of code I'm trying to cover 😑 of course it is.
Well somewhere in there I managed to do a deployment for another project and change a few things in there.
This week is starting to look like hell,
Yay hump day tomorrow!!!!!
That's something, the week is coming to an end.... right? Please.... right!!!5 -
So working for a company and the dev team I’m apart of works on a legacy rails app. Technical debt is high, no automated tests, no proper routing and also running unsupported versions of the language.
I joined seven months ago and got the current team doing automated testing so that’s a plus, they bought this app four years ago and there’s been no language updates, testing, cleanup, security updates, nothing, just adding to bad code.
Now we’re looking to actually upgrade language versions, the language and the framework now this will cause a lot of stuff to break naturally due to how outdated it is.
So I started putting proper routes into place how things should of been when things were being built as we have some spare time I decided to go out of my way to clear up some of the technical debt to get ahead of the curb. Re-done an entire section of the app, massive speed improvements, better views, controller, model, comment clean up and everything exactly how it should be.
I push the PR,
*other dev* - “why are we doing all of these other changes”
*me* - “well to implement routes properly, we have to use the new routes I just did some extra cleanup along the way”
*today, me* - “can you lend me a hand with one of the routes the ID isn’t getting passed”
*today, other dev* - “this wouldn’t of happened if you didn’t redo all these files, let’s just scrap the changes”
…
Sooo, I’ve spend three weeks improving one section in the app, because I’m having issues with one route according to this dev I should scrap it? Wait come again, am I the only one in this team who cares about making this app better all round?
Frustrating…4 -
As I'm on a research/algorithm improvement project at work I'm working pretty much independently. As such I've set up an automated test framework and writing tests for any piece of code I touch.
Today as I was fixing a bug in production area I was demoing my tests to CTO and principal design engineer. They come from a hardware background and have pushed back against automated tests in the past but they were interested in what I was doing.
I WILL DRAG THEM KICKING AND FUCKING SCREAMING INTO THE WORLD OF AUTOMATED TESTS.1 -
Hennies I need your assistance!
My boss has put me in charge (wow yes I was surprised too) of figuring out what a good solution to our current testing nightmare would be. Therefore my questions for you are:
What kind of testing strategy do you work with at your job? Do you use any tools for it? How's the division of unit tests/service tests and/or UI tests?
I'd really appreciate you guys' input on what works (and what doesn't, in case you're living a nightmare with testing daily)10 -
Disclaimer: I am an assclown who makes cobbles shit together and doesn't have a strong/real foundational understanding in the shit I deal with.
So does anybody actually write their tests before they write their code? I see the term TDD (test driven development) bandied around everywhere.
I don't know what the fuck I'm doing or what the solution will be, nor am I confident in it until I've manually tested it seems to be working.
Then I usually write the automated tests if they are easy to do so.
i.e. I won't know what/how to test the thing.....until I make the damn thing
Is this a case of 'git gud' and have the problem "presolved" in your head, before you work on it such that you can already write tests first?
Or is this a case of "aGilE", where everybody says they're agile, maybe does a little bit of scrum (just the pieces they like/find useful, not the entire thing in a dogmatic/religious way), and possibly has never heard of the manifesto https://agilemanifesto.org/12 -
I recently started to use automated tests for everything and it is really great to not worry about every little change anymore.
But I think I'm not very good at it. The tests themselves are quite slow and I'm not sure if I'm covering everything the right way. Also, I'm very slow at writing the test cases.
SO I want to learn more about it. Do you have any recommended books on this topic? Anything about unit or feature tests and TDD, language specific (PHP) or general is appreciated -
Started working as a "working student" in an it company to write unit tests. (which then will be executed automatically - so automated unit tests)
Realised that I write more or less the same code just changing the names and some parameters (sometimes more if it's not an number but a bool for example but it's pretty much the same scheme)
So I bought a tool for 1$ to use "auto complete" on custom templates.(I type testgetbool and the tool replaces this to the test case only asking for the variable name.)
So now I'm writing automated automated tests 😁😅
(which is btw pretty boring but cost & time effective)2 -
This is why we can never have enough software developers
It's true. No matter how many people learn to program, there will never be enough people who know how to program. They don't have to be very good at it either. It is now a required skill.
Minimum wage in first world countries is way above 5$ per hour. A Raspberry PI 3B costs 40$, or at most 1 day of work for the worst paid jobs. And it will run for years, and do routine tasks up to thousands of times faster than any employee. With that, the only excuse that people still do routine tasks, is the inaccessibility of coder time.
Solution: everybody should know how to write code, even at the simplest level.
Blue-collar jobs: they will be obsolete. Many of them already are. The rest are waiting for their turn.
Marketing people - marketing is online. They need to know how to set up proper tracking in JS, how to get atomic data in some form of SQL, how to script some automated adjustments via APIs for ad budgets, etc. Right now they're asking for developers to do that. If they learn to do that, they'll be an independent, valued asset. Employers WILL ask for this as a bonus.
Project Managers - to manage developers, they need to know what they do. They need to know code, they have to know their way around repositories.
QA staff - scripted tests are the best, most efficient tests.
Finance - dropping Excel in favor of R with Markdown, Jupyter Notebooks or whatever, is much more efficient. Customizing / integrating their ERP with external systems is also something they could do if they knew how to code.
Operations / Category Management - most of it would go obsolete with more companies adopting APIs as a way to exchange important information, rather than phone calls and e-mails.
Who would not be replaced or who wouldn't benefit from programming? Innovative artists.
A lot of it might not be now now, but the current generation will see it already in their career.
If we educate people today, without advanced computer skills and some coding, then we are educating future deadbeats.
With all this, all education should include CS. And not just as a mandatory field or something. Make it more accessible, more interesting, more superficial if needed. Go straight to use cases, show its effectiveness in the easiest way possible. Inquisitive minds will fill in the blanks, and everyone else will at least know how to automate a part of their work. -
The time that I felt most like a Dev badass was when I had introduced an E2E test framework and added a bunch of helper classes to it so that our QA team could pick it up and write automated tests for the manual tests they had been doing for years.
Sure, the whole department got laid off after that because we had gotten a new CTO and all of my work was essentially for naught, but it made a lot of people enjoy showing up to work for the first time in a long time, and that was what mattered most to me -
!rant
[Update on previous rant at the bottom]
So I had the technical test last friday. I did not try to implement any automated test as it is not my forte.
I had three hours to showcase my knowledge of data structures and OOP so I did that.
The test was somewhat long actually, so I left out one part that I did not have time to implement: validation of input files.
Today I got feedback, everything went well, they liked my code and I only got two negatives: Error handling and automated tests xD
Now I'm going to the second phase: phone interviews and they are gonna asks the whys of my implementation.
I'll have to explain why I did not implement automated tests and the girl on the phone told me "they didn't like it much that you had no tests because tests are very important for us".
I guess I'll have to come clean and say that I'm not very strong on that but willing to learn, so I didn't want to risk it doing something I'm not really good at.
I hope it ends up well.
prev rant:
https://devrant.com/rants/1607302/...4 -
when a senior recommends you rewrite some code with their example snippet (which doesn't work), for the 3rd time, on a different ticket
i guess i should've called them out on the 2nd time this happened, instead of silently not doing so think i'd save them some dignity after telling them the first time they did this, their recommendation didn't pass automated tests4 -
I don't get the bug "joke" that's flying around. If you have 99 bugs and fix one, why would you have more? Do you not have automated tests?4
-
Our systems lead is trying to tell our software person how much adding unit tests would cost. It also sounds like he wants TDD to be added in after the fact. And he's bitching because the software guy won't move forward with it until we get it with the customer. He also wants all of them automated, but doesn't want to accept that that is going to cost a lot. Like a lot, a lot. This is a guy who doesn't know algorithms (had to explain dykstra to him), doesn't understand the tech stack we are using (I had to explain .net versions, the JIT compiler, and garbage collection to him), and seems not to understand hardware (I had to explain floating point math to him), yet he feels qualified to tell us how long it is going to take us to implement automated unit tests for major, complex features.
-
So I work in a so called agile team of 5 people, where on of the members has the role of tester. Now this person doesn't have much technical experience, if any, in regards to coding, so the purpose of the tester is primarily to fo automated UI tests and system testing. Am I in the wrong for questioning the importance and relevance of this role, or is it just because in my previous work experience, the developers had the responsibility for testing whatever was made, and I just have to get used to this new way of working?9
-
Slacking off on tests for medium size projects. I have one project that I consider a major achievement as of today, the NPM package @lbfalvy/react-await. It has like two tests and it does a _lot_ more than two things.
Don't get me wrong, I test it thoroughly, but not in an automated way.3 -
Does anyone here work with automated acceptance tests? I don't know a lot about them and I've been wondering if it's too time consuming to write them and if it's better to test manually2
-
Currently in our 4th cycle of manual regression testing for a release and still finding bugs. Automated tests? What are those? That sounds an awful lot like it would take time to implement. Time that could be spent fixing the bugs and getting the release out the door.
When release dates take priority over quality.... -
Funny how things comes around...
So... project start-up... everybody learning and designing the future new system. Then we get to a point that we saw that we'll probably need someone outside or dev team to setup all the environments CI/CD pipelines... Our PM said "what about we get a Devops guys to take care of that?" Most of our team members agreed but our Techlead said "Devops is not a job, it's a culture.". Ok, nice... I understand that point, but for a system of the size of the one that we're building...It would probably be a good idea to have someone to take care of that for us. BUT, he (the techlead) said that he will be taking care of all that himself (along with coding part of the backend).
RESULT: We're stuck in the point that we're unable to test our system in the correct environment, we've no pipeline for automated deploy of our sprints...
Guys, I think the Devops is no more then somebody that is going to take care of some tasks in the project, like the backend, the frontend, the tests, the management...2 -
Skipping jasmine tests- especially ones on partials (not the controller). Seriously, QA has automated test suites to test UI functionality. If it takes 30 mins to write the code and 3 hours to write the tests... it may just not be worth the effort when there already is automated testing.
Ugh I hate skipping them but you know how to test the UI? Use the UI. -
R&D Lead Architect: "We want this next gen platform to be all AWS."
Us: "Alright, can we talk about automated testing?"
R&D Lead Architect: "Sure, for automated tests you'll want to just dump events from your system into a flat file on S3. It's readable with Microsoft Excel."
Us now: still here.
R&D Lead Architect now: not here.
:) -
Me, taking a coding class in uni:
Purposely cramping everything in as few lines as possible, making the code barely readable, just to screw with the guy who had to correct this mess.
In my defence, the assignment they gave us was garbage. The task descriptions were often ambiguous or even contradictory to what actually was the case ("The InputStream will contain a string of csv data, each element starts in the next line" -> was a malformed single line string) and the automated tests they wrote to check our output where either completely unhelpful because of their meaningless error messages, or sometimes even plain wrong, telling us our output was wrong, even though it definitely wasn't. -
when you're the unlucky fuck and/or too stupid to get green builds so you get flamed when the flaky automated tests (from before your time, not written by you) rear their head and shit all over you
you then get flamed for not going out of your way for fixing them, as the team verbally agreed to do so, but very rarely if at all has anybody done so (it's not so easy trying to fix something when you don't have consistent steps to reproduce)1 -
Working as a Dev for a while now, I tell new people not to bother with it. There is never any job satisfaction as people in charge never understand the basics.
Instead of learning to write efficient code, figure out how to solve real business problems, work towards a maintainable flexible product to quickly deliver value on changing requirements, write automated tests to improve quality, maintainability and prevent live issues - basically do anything a good Dev strives for - you will just constantly end up working for people with no interest beyond the next couple days, on a shit code base that no one can understand, with people that don't want to learn anything about software design and just check boxes off.
Apart from pay this must be the worst career possible in a technical field.4 -
Okay. Here's the ONLY two scenarios where automated testing is justified:
- An outsourcing company who is given the task of bug elimination in legacy code with a really short timeframe. Then yes, writing tests is like waging war on bugs, securing more and more land inch after inch.
- A company located in an area where hiring ten junior developers is cheaper than hiring one principal developer. Then yes, the business advantage is very real.
That's it. That's the only two scenarios where automated testing is justified. Other such scenarios doesn't exist.
Why? Because any robust testing system (not just "adding some tests here and there") is a _declarative_ one. On top of already being declarative (opposed to the imperative environment where the actual code exists), if you go further and implement TDD, your tests suddenly begins to describe your domain area, turning into a declarative DSL.
Such transformations are inevitable. You can't catch bugs in the first place if your tests are ignorant of entities your code is working with.
That being said, any TDD-driven project consists of two things:
- Imperative code that implements business logic
- Declarative DSL made of automated tests that also describes the same business logic
Can't you see that this system is _wet_? The tests set alone in a TDD-driven project are enough to trivially derive the actual, complete code from it.
It's almost like it's easier to just write in a declarative language in the first place, in the same way tests are written in TDD project, and scrap the imperative part altogether.
In imperative languages, absence of errors can be mathematically guaranteed. In imperative languages, the best performance (e.g. the lowest algorithmic complexity) can also be mathematically guaranteed. There is a perfectly real point after which Haskell rips C apart in terms of performance, and that point happens earlier on than you think.
If you transitioned from a junior who doesn't get why tests are needed to a competent engineer who sees value in TDD, that's amazing. But like with any professional development, it's better to remember that it's always possible to go further. After the two milestones I described, the third exists — the complete shift into the declarative world.
For a human brain, it's natural to blindly and aggressively reject whatever information leads to the need of exiting the comfort zone. Hence the usual shitstorm that happens every time I say something about automated testing. I understand you, and more than that, I forgive you.
The only advice I would allow myself to give you is just for fun, on a weekend, open a tutorial to a language you never tried before, and spend 20 minutes messing around with it. Maybe you'll laugh at me, but that's the exact way I got from earning $200 to earning $3500 back when I was hired as a CTO for the first time.
Good luck!6 -
when it takes more effort to writing a bunch of dumbass mocks and stubs so you can have an automated test, than it does to manually test, because you're too retarded to figure out how the fuck easymock is supposed to work, and being awful at your job, also fuck java imports and easymock for being difficult to work with
shout out to my coworkers for requesting more automated tests
can't wait till it all gets deleted anyway because we're going to delete the code we're testing5 -
Robert Martin says in clean code, or maybe clean architecture, that one should separate the tests into what is hard and easy. GUI tests are hard and therefore brittle and so we should test against view models.
However on clean agile he says a story is not done until it passes automated acceptance tests which in my experience are always brittle and grow so large and brittle that things grind to a halt.
What am I missing? Are stable acceptance tests possible on the GUI? Should we test only an API?5 -
When you're working with a QA/test engineer that insists on manually testing code that have automated tests. Can any test engineera chime in here?
-
New version, new regression tests. It's the first time I'm trying to run them fully automated. Tests were ok separately, but as it turns out, "random" generated number is not OK for creating unique names if it's being created from datetime (yymmddmmss), and tests run within one minute.
Also, new version broke our hack of disabling browser pop-up confirmations. Fuck.1 -
FML so I have recently learned I am mandated (nodoby asked me if I wanted to do it, management just assumed I would) to help and train an offshore SQA team with 10 hours of jet lag to automate their tests on physical hardware because everything they do is manual and their environment is all mocked including hardware... there is barely any doc on how they test their shit or on what they even do. I need them to show me their shit work on goddamn zoom. And then once I manage to do this by some fucking miracle, I need to show them how to take over my already automated project.
Dudes cannot even code, how the fuck am I supposed to do this? Worse is I was told I can't impose our tested infrastructure and libs on them because "we have to give them flexibility" or some bullshit.
Fucking pay cheaply 5 people offshore to get fuck all done and then put the weight on my shoulders when you are surprised it does not work? You bunch of management fucks, eh?
Lucky I am getting some shiny offers elsewhere.3 -
Just wondering any of you has seen automated tests in a CI machine? Theyre not reliable enough to be running all the time because many times its just an empty error amd its tedious to investigate and wastes lots of time2
-
Just built out my first app using Cloudflare Workers, Typescript, and DurableObjects. Holy shit, this is nice stuff.
It's taken little to no time to build out:
* JSON API written in Typescript
* JWT verification against my OAuth backend (SAML support too)
* CI Automated Deployments including unit tests
* DurableObject support
* 3rd party HTTP calls + caching (built in to the framework!) to reduce network latency and hiccups.
* Cron-like tasks on each stored object so they can awaken the app on a schedule and update themselves as necessary
* Rapid deployment to new environments
The local testing with coordinated "miniflare" is dreamy too. -
I'll be learning how to build automated integration tests for a serverless infrastructure during the Superb Owl tomorrow. How about you?
Top Tags
Weekly Rant
View