My biggest dev sin is not writing any unit tests for devRant :/

Yesterday: Senior dev messages out a screenshot of someone using an extension method I wrote (he didn’t know I wrote it)..

SeniorDev: “OMG…that has to be the stupidest thing I ever saw.”
Me: “Stupid? Why?”
SeniorDev: “Why are they having to check the value from the database to see if it’s DBNull and if it is, return null. The database value is already null. So stupid.”
Me: “DBNull is not null, it has a value. When you call the .ToString, it returns an empty string.”
SeniorDev: ”No it doesn’t, it returns null.”
<oh no he didn’t….the smack down begins>
Me: “Really? Are you sure?”
SeniorDev: “Yes! And if the developer bothered to write any unit tests, he would have known.”
Me: “Unit tests? Why do you assume there aren’t any unit tests? Did you look?”
<at this moment, couple other devs take off their head phones and turn around>
SeniorDev:”Well…uh…I just assumed there aren’t because this is an obvious use case. If there was a test, it would have failed.”
Me: “Well, let’s take a look..”
<open up the test project…navigate to the specific use case>
Me: “Yep, there it is. DBNull.Value.ToString does not return a Null value.”
SeniorDev: “Huh? Must be a new feature of C#. Anyway, if the developers wrote their code correctly, they wouldn’t have to use those extension methods. It’s a mess.”
<trying really hard not drop the F-Bomb or two>
Me: “Couple of years ago the DBAs changed the data access standard so any nullable values would always default to null. So no empty strings, zeros, negative values to indicate a non-value. Downside was now the developers couldn’t assume the value returned the expected data type. What they ended up writing was a lot of code to check the value if it was DBNull. Lots of variations of ‘if …’ , ternary operators, some creative lamda expressions, which led to unexpected behavior in the user interface. Developers blamed the DBAs, DBAs blamed the developers. Remember, Tom and DBA-Sam almost got into a fist fight over it.”
SeniorDev: “Oh…yea…but that’s a management problem, not a programming problem.”
Me: “Probably, but since the developers starting using the extension methods, bug tickets related to mis-matched data has nearly disappeared. When was the last time you saw DBA-Sam complain about the developers?”
SeniorDev: “I guess not for a while, but it’s still no excuse.”
Me: “Excuse? Excuse for what?”
<couple of awkward seconds of silence>
SeniorDev: “Hey, did you guys see the video of the guy punching the kangaroo? It’s hilarious…here, check this out.. ”

Pin shoulders the mat…1 2 3….I win.

Boss: "I looked at a testing suite. It is $2,500 a license and I'm buying 60 licenses. You should probably get familiar with it."
LeadDev: "Um, we already use NUnit, and it's free."
Boss: "Hmm...I'd better add Pluralsight training in the budget so you can learn about the new program."
LeadDev: "Oh, no...we need new laptops more than we need software."
Boss:"New laptops? Not my budget. When we buy this new software, everyone is going to use it"
LeadDev: "Everyone? How will you monitor it's usage?"
Boss: "I'll have networking send me captures of all the running tasks on the dev machines. The test suite better be running. Writing good tests will be our #1 priority."
LeadDev: "Um, we already write tests using NUnit."
Boss: "I don't understand what you are saying. I need something I can visualize. This UI testing suite is exactly what I need."
LeadDev: "Maybe the testing suite would be better suited for you and QA?"
<click..click>
Boss: "Submitted the budget. There will be a test server available for you to configure. This whole project costs over $100,000, so don't screw it up. Any questions?"
LeadDev: "Oh...well...what server ..."
Boss: "Dang...sorry, I'm taking off the rest of the afternoon. We'll talk about this more on Monday. Get started on those Pluralsight videos. I'll expect a full training and deployments by next week. Have a great weekend!"

"Let's do some pair programming! It will be fun!"

... Fuck no.

Either I start coding and you open a beer, or the other way around. And sure, I do not mind doing each other's code reviews. I respect your feedback.

But I can't look over your shoulder while you misspell keywords. When I write code, I search, try, debug and play at a high speed.

I'm an impressionist/surrealist writing messy passionate functions, breaking lots of things with broad paintbrush strokes before finishing it into detailed perfection. I remember all the places in the code I need to work on, and cover everything with tests.

You're a baroque coder, sometimes even a hyperrealist, with your two-finger 10 wpm typing, writing code strictly line-by-line, decorating every statement with the right checks & typehints in advance. You can not keep two functions in your head at the same time. You write tests reluctantly, but you hate that I barely plan. You plan everything, including your pee breaks.

As a coworker I respect you.

But there is no bigger hell than pair programming with you.

How everyone uses stackoverflow:
1. Work on some project
2. Spot a bug
3. Try to solve the bug and fail.
4. Write a question for SO.
5. Post question on SO.
6. Get the answer and some points.

How I use stackoverflow:
1. Work on some project
2. Find a bug
3. Try to fix the bug and fail
4. Write a question on SO
5. Get scared that I might be downvoted.
6. Spend 45 minutes optimizing the structure of the question.
7. Try additional tests to cover all possible scenarios.
8. Still scared to click post.
9. Scrap everything and restart line by line writing further details of each step in your question.
10. Find the bug myself.
11. Click cancel on the question that took me 3+ hours to write.
12. Cry.

The project where I realized I wanted to go from chemist to pro dev.

I built a flow-chemistry spectrometer with monitoring backend in Haskell.

Spectroscopy is where you add a reagent to a glass tube, it changes color, and by measuring the exact color it tells you how much of something (for example, a toxin) is present in the sample.

I had to do that a lot on factory samples, writing down measurements using pen & paper.

I'm lazy so I decided to do the logical thing: Automate it. I bought a second hand spectrometer, stripped the casing, did a shitload of glassblowing and hooked up tubes to the production pipelines, so I could get samples, mixing them in the correct ratio with reagents in continuous flows using valves.

I ended up using 2 home-crafted arduino-like boards (etching PCBs is fun!).

One to calibrate the mixture against known samples and control solenoid valves to continuously cycle through various reagents and deionized flushing water, the other to record the measurements and send them to a server running a Haskell/Yesod API.

The server collected the information into InfluxDB (A time series database), displaying all data on a graphite dashboard.

Eventually I wrote Haskell plugins for most of the chemistry processes, from pH & temperature measurements to polymer property and pigment tests (they made a lot of printer ink).

Then I was fired because they didn't need chemists anymore, and the code "could be maintained by the intern" (poor guy)...

But I did find out that I loved functional programming, chemistry automation projects, and crafting my own electronics during that time.

Not writing unit tests.

Everyone reading this is guilty of it.

Anyone who says otherwise is lying.

I was writing tests at work and rather enjoying myself.

Boss insisted we all go home early because "holiday halfsies," so I semi-unhappily pack up and go home. At home, I write tests for a personal project instead.

Dev life.

Every day.

I am a PHP developer.

Yeah, "another PHP is awful" rant... no, not really.

It's just unsuitable for some ambitious projects, just like Ruby and Python are.

First of all, DO NOT EVER use Laravel for large enterprise applications. The same goes for RoR, Django, and other ActiveRecord MVCs.

They are all neat frameworks for writing a todo app, as a better-than-wordpress flexible blogging solution, even as a custom webshop.

Beyond 50k daily users, Active Record becomes hell due to it's lazy fat querying habits. At more than a million users... *depressed sigh*.

PHP is also completely unsuitable for projects beyond 5M lines of code in my opinion. At more than 25M lines... *another depressed sigh*.

You can let your devs read Clean Code and books about architecture patterns, you can teach them about SOLID & DRY, you can write thousands of tests... it doesn't matter.

PHP is scaffolding, it's made of bamboo and rope. It's not brick or concrete. You can build quickly, but it only scales up to a certain point before it breaks in multiple places.

Eventually you run into patterns where even 100% test coverage still doesn't guarantee shit, because the real-life edge cases are just too complex and numerous.

When you're working on a multi-party invoicing system with adapters for various tax codes, or an availability/planning system working across timezones, or systems which implement geographical routefinding coupled to traffic, event & weather prediction...

PHP, Python, Ruby, etc are just missing types.

Every day I run into bugs which could have been prevented if you could use ADTs in a generic way in PHP. PHP7 has pretty good typehints, and they prevent a lot of messy behavior, but they aren't composable. There is no way to tell PHP "this method accepts a Collection of Users", or "this methods returns maybe either an Apple or a Pear, and I want to force the caller to handle both Apple/Pear and null".

Well, you could do that, but it requires a lot of custom classes and trickery, and you have to rewrite the same logic if you want to typehint a "Collection of Departments" instead of "Collection of Users" -- i.e., it's not composable.

Probably the biggest issue is that languages with a (mostly) structural type system (Haskell, Rust, even C#/JVM languages to some degree, etc) are much slower to develop in for the "startup" era of a project, so you grab a weak, quick prototyping language to get started.

Then, when you reach a more grown up phase, you wish you had a better type system at your disposal...

Sometimes I'm lazy and if I'm writing unit tests and there's a complicated case to test I'll just skip it.

I'm drunk and I'll probably regret this, but here's a drunken rank of things I've learned as an engineer for the past 10 years.

The best way I've advanced my career is by changing companies.

Technology stacks don't really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it's not going to be the same as webdev or embedded. But all fields have about 10-20 core principles and the tech stack is just trying to make those things easier, so don't fret overit.

There's a reason why people recommend job hunting. If I'm unsatisfied at a job, it's probably time to move on.

I've made some good, lifelong friends at companies I've worked with. I don't need to make that a requirement of every place I work. I've been perfectly happy working at places where I didn't form friendships with my coworkers and I've been unhappy at places where I made some great friends.

I've learned to be honest with my manager. Not too honest, but honest enough where I can be authentic at work. What's the worse that can happen? He fire me? I'll just pick up a new job in 2 weeks.

If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.

pour another glass

Qualities of a good manager share a lot of qualities of a good engineer.

When I first started, I was enamored with technology and programming and computer science. I'm over it.

Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all.

The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)

Related to above, writing good proposals for changes is a great skill.

Almost every holy war out there (vim vs emacs, mac vs linux, whatever) doesn't matter... except one. See below.

The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me.

If I ever find myself thinking I'm the smartest person in the room, it's time to leave.

I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.

We should hire more interns, they're awesome. Those energetic little fucks with their ideas. Even better when they can question or criticize something. I love interns.

sip

Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us.

Tech stack matters. OK I just said tech stack doesn't matter, but hear me out. If you hear Python dev vs C++ dev, you think very different things, right? That's because certain tools are really good at certain jobs. If you're not sure what you want to do, just do Java. It's a shitty programming language that's good at almost everything.

The greatest programming language ever is lisp. I should learn lisp.

For beginners, the most lucrative programming language to learn is SQL. Fuck all other languages. If you know SQL and nothing else, you can make bank. Payroll specialtist? Maybe 50k. Payroll specialist who knows SQL? 90k. Average joe with organizational skills at big corp? $40k. Average joe with organization skills AND sql? Call yourself a PM and earn $150k.

Tests are important but TDD is a damn cult.

Cushy government jobs are not what they are cracked up to be, at least for early to mid-career engineers. Sure, $120k + bennies + pension sound great, but you'll be selling your soul to work on esoteric proprietary technology. Much respect to government workers but seriously there's a reason why the median age for engineers at those places is 50+. Advice does not apply to government contractors.

Third party recruiters are leeches. However, if you find a good one, seriously develop a good relationship with them. They can help bootstrap your career. How do you know if you have a good one? If they've been a third party recruiter for more than 3 years, they're probably bad. The good ones typically become recruiters are large companies.

Options are worthless or can make you a millionaire. They're probably worthless unless the headcount of engineering is more than 100. Then maybe they are worth something within this decade.

Work from home is the tits. But lack of whiteboarding sucks.

About 11 months I posted that my wife was pregnant. I now have upgraded to son 1.0. All without writing any tests!

Looks like I'm getting fired on Wednesday :)

Long story:

*I add first unit tests to project.

*Boss adds new functionality and breaks all the tests so I can't compile and write more for what I'm working on.

*Boss is very fragile and cannot handle any comment that can possibly be taken as a slight against him.

Me: "I wanted to ask what our policy on unit tests is please? Because we haven't really said how we are treating unit tests, and everyone myself included is not thinking about them. I also haven't added tests when I fixed bugs and this time your changes broke the tests"

Boss 10 minutes later: "I want to speak to you in private".

Boss: "you are too forceful and direct. You said I should have added tests."

Me: "yeah but I didn't mean in a nasty way"

Boss getting louder and more aggressive: "You are too forceful"

Me: "I didn't mean it in a bad way"

Boss: "I didn't want to add tests for that!"

Me: "then why add any tests?"

Boss: "Fine we are not having this conversation now!"

*Boss storms out

I decided I can't speak to the guy about anything without upsetting him spoke to the manager before I quit because I can't work like this.

That resulted in a meeting with my boss, his boss and the head of HR where I ended up savaging him and told them I can't bring up anything as I can never tell if it will offend him and that I spend ages writing emails and trying to document communications because I just can never tell if I will upset him. Also that I cannot bring up any ideas because I can't tell if he will somehow get offended and that I can't even write code because if I change something he wrote at some point he will get angry.

My boss claims that I am extremely forceful and disrespectful and that I am constantly insulting him and his decisions.

We go back over a ton of shit and I refute everything he says. In the end I have to have a meeting with him on Wednesday where we either get things straight, he fires me or I quit.

I think at this point that our relationship is too fucked for him to be my team lead on a 6 man team.

Side note I keep bringing forth ideas because we have one database shared between 6 Devs, no pull requests (apart from mine and another new guy), no test driven development, no backlog, no team driven story pointing, no running tests before merging, no continuous integration setup, no integration tests, no build step on merge, no idea of if we are on track to our deadline other than his gut feeling, no actual unit tests backend - just integration with a test db, no enthusiasm to learn in the team and no hope.

At one of my former jobs, I had a four-day-week. I remember once being called on my free Friday by an agitated colleague of mine arguing that I crashed the entire application on the staging environment and I shall fix it that very day.

I refused. It was my free day after all and I had made plans. Yet I told him: OK, I take a look at it in Sunday and see what all the fuzz is all about. Because I honestly could fathom what big issue I could have caused.

On that Sunday, I realized that the feature I implemented worked as expected. And it took me two minutes to realize the problem: It was a minor thing, as it so often is: If the user was not logged in, instead of a user object, null got passed somewhere and boom -- 500 error screen. Some older feature broke due to some of my changes and I never noticed it as while I was developing I was always in a logged in state and I never bothered to test that feature as I assumed it working. Only my boss was not logged in when testing on the stage environment, and so he ran into it.

So what really pushed my buttons was:

It was not a bug. It was a regression.

Why is that distinction important?

My boss tried to guilt me into admitting that I did not deliver quality software. Yet he was the one explicitly forbidding me to write tests for that software. Well, this is what you get then! You pay in the long run by strange bugs, hotfixes, and annoyed developers. I salute you! :/

Yet I did not fix the bug right away. I could have. It would have just taken me just another two minutes again. Yet for once, instead of doing it quickly, I did it right: I, albeit unfamiliar with writing tests, searched for a way to write a test for that case. It came not easy for me as I was not accustomed to writing tests, and the solution I came up with a functional test not that ideal, as it required certain content to be in the database. But in the end, it worked good enough: I had a failing test. And then I made it pass again. That made the whole ordeal worthwhile to me. (Also the realization that that very Sunday, alone in that office, was one of the most productive since a long while really made me reflect my job choice.)

At the following Monday I just entered the office for the stand-up to declare that I fixed the regression and that I won't take responsibility for that crash on the staging environment. If you don't let me write test, don't expect me to test the entire application again and again. I don't want to ensure that the existing software doesn't break. That's what tests are for. Don't try to blame me for not having tests on critical infrastructure. And that's all I did on Monday. I have a policy to not do long hours, and when I do due to an "emergency", I will get my free time back another day. And so I went home that Monday right after the stand-up.

Do I even need to spell it out that I made a requirement for my next job to have a culture that requires testing? I did, and never looked back and I grew a lot as a developer.

I have familiarized myself with both the wonderful world of unit and acceptance testing. And deploying suddenly becomes cheap and easy. Sure, there sometimes are problems. But almost always they are related to infrastructure and not the underlying code base. (And yeah, sometimes you have randomly failing tests, but that's for another rant.)

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.

rant? rant!

I work for a company that develops a variety of software solutions for companies of varying sizes. The company has three people in charge, and small teams that each worked on a certain project. 9 months ago I joined the company as a junior developer, and coincidentally, we also started working on our biggest project so far - an online platform for buying groceries from a variety of vendors/merchants and having them be delivered to your doorstep on the same day (hadn't been done to this scale in Estonia yet). One of the people from management joined the team working on that. The company that ordered this is coincidentally being run by one of the richest men in Estonia. The platform included both the actual website for customers to use, a logistics system for routing between the merchants, the warehouse, and the customers, as well as a bunch of mobile apps for the couriers, warehouse personnel, etc. It was built on Node.js with Hapi (for the backend stuff), Angular 2 (for all the UIs, including the apps which are run through a WebView wrapper), and PostgreSQL (for the database). The deadline for the MVP we (read: the management) gave them, but we finished it in about 7 months in a team of five.

The hours were insane, from 10 AM to 10 PM if lucky. When we weren't lucky (which was half of the time, if not more), we had to work until anywhere from 12 PM to 3 AM, sometimes even the whole night. The weekends weren't any better, for the majority of the time we had to put in even more extra hours on the weekends. Luckily, we were paid extra for them, but the salary was no way near fair (the majority of the team earned about 1000€/mo after taxes in a country where junior developers usually earn 1500€/month). Also because of the short deadline given to us, we skipped all the important parts like writing tests, doing CI, code reviews, feature branching/PR's, etc. I tried pushing the team and the management to at least write tests and make feature branches/PRs, but the management always told me that there wasn't enough time to coordinate and work on all that, that we'll do that after launching the MVP, etc. We basically just wrote features, tested them by hand, and pushed into the "test" branch which would later get tested and merged into master.

During development, one of the other juniors managed to write the worst kind of Angular code you could imagine - enormous amounts of duplication, no reusable components (every view contained the everything used in the view, so popups and other parts that should logically be reusable were in every view separately), fuck - even the HTML was broken (the most memorable for me were the "table > tr > div > td" ones, but that's barely scratching the surface). He left a few months into the project, and we had to build upon his shit, ever so slightly trying to fix the shit he produced. This could have definitely been avoided if we did code reviews.

A month after launching the MVP for internal testing, the guy working on the logistics system had burned out and left the company (he's earning more than twice the salary he got here, happy for him, he is a great coder and an even better team player). This could have been avoided if this project had been planned better, but I can't really blame them, since it was the first project they had at this scale (even though they had given longer deadlines for projects way smaller than this).

After we finished and launched the MVP, the second guy from management joined, because he saw we needed extra help. Again I tried to push us into investing the time to write tests for the system (because at this point we had created an unstable cluster fuck of a codebase), but again to no avail. The same "no time, just test it manually for now, we'll do that later when we have time" bullshit from management.

Now, a few weeks ago, the third guy from management joined. He saw what a disaster our whole project was. Him joining was simply a blessing from the skies. He started off by writing migrations using sequelize. I talked to him about writing tests and everything, and he actually listened. He told me that I'm gonna be the one writing them, and also talked to the rest of management about it. I was overjoyed. I could actually hear the bitterness in the voices of the rest of management when they told me how to write the tests, what to test, etc. But I didn't give a flying rat's ass, I was hapi.

I was told to start off by writing a smoke test for the whole client flow using Puppeteer. I got even happier, since I was finally able to again learn new things (this stopped at about 4 or 5 months into the project).

I'm using jest as the framework and started writing the tests in TypeScript. Later I found a library called jest-extended, but it didn't have type defs, so I decided to write them and, for the first time in my life, contribute to the open source community.

I might have posted this before. But I am going to post it again. Because emojis.

Me: 😁 Software lead I have finished coding the thing.
SL: 😀 Cool, good job. That is going to really help out the analysts.
Software Manager: 😐 hey I noticed you have coded a new thing and pushed it to integration.
Me: 😁 Yes.
SM: 😐 Well how do you know when it's done?
Me: 😑 . . . When you run it and it does the thing?
SM: 😐 Did you write test steps?
Me: 😕 Yeah . . . they're in the issue ticket.
SM: 😐 Yeah but how do you know those are right?
Me: 😕 Because I wrote the thing and the test steps?
SM: 😐 did you put any steps in our acceptance test procedure?
Me: 😕 No.
SM: 😐 why not?
Me: 😧 Because the acceptance test procedure tests requirements. There is no requirement for this functionality.
SM: 😑 Then why did you do it?
Me: 🤔 Because it was an internal request from the analysis team. There is no customer impact here.
SM: 😑 I really think we should write a requirement.
SL: 🤔 But what requirement is he going to attach this to?
SM: 😑 We don't have to attach it to a requirement. We can just test it once and remove it.
Me: 😒 SM, you know we never remove anything from the acceptance test procedure.
SM: 🙂 We do sometimes.
SL: 🤔 When was that I have worked here for twenty years and we have never removed a test from that document.
SM: 😑
SL: 😒
SM: 😑
SL: 😒
Me: 🤐
SM: 😧 I really think there should be an acceptance test written.
SL: 😧 Looks like you're writing an acceptance test.
Me: 😒 Alright as long as y'all're payin'. Shit I was just tryin' to save y'all money.

*acceptance test written and sent to peer review*

Peer: 😐 The requirement tested section doesn't have any requirements spelled out.
Me: 😅 No.
Peer: 🤔 Why?
Me: 😓 Because there is no requirement associated with this test.
Peer: 🤔 Then why are we adding an acceptance test?
Me: 😡 WELL AIN'T THAT A GOOD GOD DAMN QUESTION!?

TL;DR: don't fuck with your IT guy.

One of the guys in our office treats his laptop like shit, has dropped it a number of times and had managed to break the screen. There was a nice crack diagonally corner to corner across the screen with a nice black splotch around it making a good chunk of his screen unusable. Servicing the laptop would be too expensive and would mean being without the machine for several weeks forced to use a Mac.

I offered to replace the screen for him since I have experience doing laptop repairs. Once the screen arrived I kept the laptop for the evening and spent an hour replacing the screen. I left a note telling him he owed me $60 for my time.

He sees the note, laughs and says "I'll buy you lunch."

Not only does this guy only keep his word when offering to buy lunch about 10% of the time, when he does actually do it he charges it on the company card so it isn't really him paying for it. So I spent my lunch break writing up a little Python app which randomly fucks with his mouse and keyboard.

I sent him a message that I needed to run some tests on his new screen tonight so I'll be able to install it and set it to run on boot.

The app does things like:
Jiggle the mouse
Minimize all windows to show the desktop
Double click
Right click

Can't decide if I want to add in reboots as well.

I figure I'll leave it going until I get $60 worth of entertainment out of it.

We have this guy who is responsible for software testing, user support and stuff. Not a programmer but with good technical base knowledge. He was interested in writing automated tests, and I told him he might take some time to learn and help us there. In the last months I had to answer and explain a gazillion questions about our codebase and coding in general and it took me lot of time. But last week he showed me his first test suite which was actually good code and showed a lot of understanding of all aspects of this. This was more satisfying than anything on work ever.

When your colleague is having the time of his life writing unit tests

I've had my share of incompetent coworkers. In order of appearance:

1. A full stack dev. This one guy never, and I mean NEVER uses relationships in their tables. No indexing, no keys, nada. Couple of months later he was baffled why his page took ten seconds to load.

2. The same dev as (1). Requirement was to create some sort of "theme" feature for a web app. Hacked it by putting !important all over the place.

3. The same dev again. He creates several functions that if the data exists returns a view, and if it doesn't, "echo '0'". No, not return 0 or return false or anything, but fucking echo. This was PHP. If posted a rant about this a few months ago.

4. Same dev, has no idea what clean code is. No, not just reusable functions, he doesn't even get indenting right. Some functions have 4 spaces, some 2 tabs, some 6 tabs! And this is inside the same function. God wait until he tries Python...

5. Same dev now suggests that he become the PM. GM approves (very small company). Assigns me to travel to a client since they needed "technical assistance about the API". Was actually there to lead a UAT session.

Intermezzo, that guy went from fullstack dev to PM to sales (yes, one who calls clients to offer products) to business development, to product analyst in the span of two years.

After a year and a half there, I quit.

6. New company, a "QA engineer" who also assumes the role as the product owner. Does absolutely no tests other than "functional tests" in which he NEVER produces any form of documentation. Not even a set of test cases. He goes by "intuition".

7. Same guy as (6), hands me requirements for a feature. By "hands me" I mean he did that verbally. No spec documents, no slack chat, no Trello card. I ended up writing it as a card in Trello. Fast forward to the due date, he flips out because that wasn't what he wanted. Showed him the card. He walked away, without thinking of a solution how this mess should be handled.

Despite all this, I really don't want him (6&7) to leave the company. The devs get really stressed out at this job and he does make a really good person to laugh with/at.

Not writing tests.

Yes we exist.

tl;dr: spent 12 hours creating an api for a job interview challenge. Got rejected after 4 weeks with no real feedback, and all I can do is rant!

So I was in the interview process with a company that was a great fit for my background.

Got through a couple of phone screens, and was given a coding challenge consisting of writing a web API with a couple of endpoints and a filter function.

I'm like, ok no problem, I happen to have created apis for some mobile apps in the past, and I pick Django rest framework to get the job done.

Implemented it on a Sunday, wrote a medium size Readme.md and some unit tests and submit. Took almost four weeks and a partial resubmission to get a rejection with no specific feedback.

Now I'm shamelessly butthurt and I have nothing else to do but rant! Worse part is I looked back at the code and in my opinion is solid AF, so I put it on my public GitHub cause fuck it!

Every 2 months without fail:

Manager: I don’t understand what the point of writing tests is. They only ever pass and when they fail we just fix them so they pass again! It’s completely redundant!!! An exercise in absolute futility!

Dev: …

People who try to justify not writing unit tests are the same as those who try to justify not using a condom.

You'll be sorry later.

it's funny, how doing something for ages but technically kinda the wrong way, makes you hate that thing with a fucking passion.

In my case I am talking about documentation.

At my study, it was required to write documentation for every project, which is actually quite logical. But, although I am find with some documentation/project and architecture design, they went to the fucking limit with this shit.

Just an example of what we had to write every time again (YES FOR EVERY MOTHERFUCKING PROJECT) and how many pages it would approximately cost (of custom content, yes we all had templates):

Phase 1 - Application design (before doing any programming at all):
- PvA (general plan for how to do the project, from who was participating to the way of reporting to your clients and so on - pages: 7-10.
- Functional design, well, the application design in an understandeable way. We were also required to design interfaces. (Yes, I am a backender, can only grasp the basics of GIMP and don't care about doing frontend) - pages: 20-30.
- Technical design (including DB scheme, class diagrams and so fucking on), it explains it mostly I think so - pages: 20-40.

Phase 2 - 'Writing' the application
- Well, writing the application of course.
- Test Plan (so yeah no actual fucking cases yet, just how you fucking plan to test it, what tools you need and so on. Needed? Yes. but not as redicilous as this) - pages: 7-10.

- Test cases: as many functions (read, every button click etc is a 'function') as you have - pages: one excel sheet, usually at least about 20 test cases.

Phase 3 - Application Implementation
- Implementation plan, describes what resources will be needed and so on (yes, I actually had to write down 'keyboard' a few times, like what the actual motherfucking fuck) - pages: 7-10.
- Acceptation test plan, (the plan and the actual tests so two files of which one is an excel/libreoffice calc file) - pages: 7-10.
- Implementation evalutation, well, an evaluation. Usually about 7-10 FUCKING pages long as well (!?!?!?!)

Phase 4 - Maintaining/managing of the application
- Management/maintainence document - well, every FUCKING rule. Usually 10-20 pages.
- SLA (Service Level Agreement) - 20-30 pages.
- Content Management Plan - explains itself, same as above so 20-30 pages (yes, what the fuck).
- Archiving Document, aka, how are you going to archive shit. - pages: 10-15.

I am still can't grasp why they were surprised that students lost all motivation after realizing they'd have to spend about 1-2 weeks BEFORE being allowed to write a single line of code!

Calculation (which takes the worst case scenario aka the most pages possible mostly) comes to about 230 pages. Keep in mind that some pages will be screenshots etc as well but a lot are full-text.

Yes, I understand that documentation is needed but in the way we had to do it, sorry but that's just not how you motivate students to work for their study!

Hell, students who wrote the entire project in one night which worked perfectly with even easter eggs and so on sometimes even got bad grades BECAUSE THEIR DOCUMENTATION WASN'T GOOD ENOUGH.

For comparison, at my last internship I had to write documentation for the REST API I was writing. Three pages, providing enough for the person who had to, to work with it! YES THREE PAGES FOR THE WHOLE MOTHERFUCKING PROJECT.

This is why I FUCKING HATE the word 'documentation'.

how I feel when I'm the only one writing unit tests for the project.

As a Java developer, reasons to kill other programmers:

- static mutable variables
- WRITING to static mutable variables
- API call with Framework X didn't work. Add Framework Y along with X and try that. Wrap X in try/catch statement. Catch block fires framework Y.
- six, seven, ten levels of nested code. Zero thought put in organization
- 6K LOC Java files
- spring (singleton? Maybe) object assigning values in static mutable (see pt.1)
- a couple of unit tests in code base that no longer work. Zero unit tests in new code
- unit testing disabled in CI pipeline
- empty catch blocks
- pass mutable data between threads. Modify in various places concurrently.

Writing more infrastructure than product.

Look, my application requests and transforms data from a single external API endpoint, it's just one GET request...

But I made an intelligent response caching middleware to prevent downtime when the parent API goes down, I made mocks and tests for everything, the documentation is directly generated from the code and automatically hosted for every git branch using hooks, responses are translated into JSONschema notation which automatically generate integration tests on commit, and the transformations are set up as a modular collection of composable higher order lenses!

Boss: Please use less amphetamine.

Refactoring and writing tests for code that was code written by intern and is on production about one year

You can believe or not but it’s just one of those stories. It’s long and crazy and it probably happened.

A few years ago I was interviewed by this big insurance company. They asked me on linkedin and were interested. They didn’t specify who they were so I didn’t specify who I am either.

After they revealed who they are I was just curious how they fuck they want to spend those billions of dollars they claimed in their press notes about this fucking digital transformation everyone is talking about. The numbers were big.

I got into 3 or 4 phone/skype interviews without technical questions and I was invited to see them by person.
I know that it would be funny because they didn’t asked me for CV so they didn’t know anything about me and I was just more curious how far I can get without revealing myself.

They canceled interview at midnight and I was in the middle of Louis de Funès comedies marathon so I didn’t sleep whole night. I assumed they would just reschedule but then they phoned me at 8 am if I can come because they made mistake.

So at first talk I was just interviewed by some manager I knowed after 5 minutes he would be shitty as fuck and demand stupid things in no time because he is not technical. He was trying to explain me that they got so great people and they do everything so fast.

From my experience speed and programming are not the things that match. ( for reference of my thought see three virtues of a GREAT programmer )

So I just pissed them off by asking what they would do with me when I finish this transformation thingy next year. ( Probably get rid off and fire at some point were my thoughts )

Then I got this technical interview on newest gold color MacBook pro - pair programming ( they were showing off how much money they have all the time ).
The person asked me to transform json and get some data in javascript .

Really that was the thing and I was so bored and tired that I just asked in what ES standard I can code.
The problem was despite he told me I can do anything and they are using newest standards ( yeah right ) the “for of” loop didn’t worked and he even didn’t know that syntax existed. So I explained him it’s the newest syntax pointing mozilla page and that he need to adjust his configuration. Because we didn’t have time for that I just did it using var an function by writing bunch of code.
When he was asking me if I want to write some tests probably because my code looked ugly as fuck ( I didn’t sleep for more then 24 hours at that point and wanted to live the building as fast as I can) I told I finished and there is no time for tests because it’s so simple and dumb task. The code worked.

After showing me how awesome their office is ( yeah please I work from home so I don’t care ) I got into the talk with VP of engineering and he was the only person who asked me where is my CV because he didn’t know what to talk about. I just laughed at him and told him that I got here just by talking how awesome I am so we can talk about whatever he wants.
After quick talk about 4 different problems where I introduced 4 different languages and bunch of libraries just because I can and I worked with those he was mine.

He told me about this awesome stack they’re building with kubernetes and micro services and the shitty future where they want to put IOT into peoples ass to sell them insurance and suddenly I got awake and started to want that job but behind that all awesomeness there was just .NET bridge with stack of mainframes running COBOL that they want to get rid off and move company to the cloud.

They needed mostly people who would dump code to different technology stack and get rid of old stack ( and probably those old people ) and I was bored again because I work more in r&d field where you sometimes need to think about something that don’t exist and be creative.

I asked him why it would take so much time so he explained me how they would do the transformation by consolidating bunch of companies and how much money they would make by probably firing people that don’t know about it to this day.

I didn’t met any person working permanently there but only consultants from corporations and people hired in some 3rd party company created by this mother company.

They didn’t responded with any decision after me wasting so much time and they asked me for interview for another position year after.
I just explained HR person how they treat people and I don’t want to work there for any money.

If You reached this point it is the end and if it was entertaining thank YOU I did my best.

Have a nice day.

I've found sites like Udemy/Khanacademy/Codecademy/Brilliant/Edx to be very useful — possibly more useful than expensive education.

But they still need:

1. Better correction/update mechanisms. Human teachers make mistakes and material gets outdated, and while online teachers are rectified faster than classroom teachers, the procedure is still not optimal. Knowledge should be a bit more like a verified wiki.

2. Some have great interactive coding environments, some have great videos, some have awesome texts, some have helpful communities. None has it all. In the end, I don't want to learn a new language by writing code in my browser. It could all be integrated/synced to the point where IDEs have plugins which are synced to online videos, with tests and exercises built in, up to a social network where you could send snippets for review and add reviews to other people's code.

3. Accreditation. Some platforms offer this against payment, but I think those platforms often feel very old school (pun intended), with fixed schedules, marks and enrollments. Self paced is a must.

4. Depth is important. Current online courses are often a bit introductory. We need more advanced courses about algorithms, theoretical computer science, code design, relational algebra, category theory, etc. I get that it's about supply/demand, but we will eventually need to have those topics covered.

I do believe that for CS, full online education will eventually win from the classroom — it's still in its infancy, but has more potential to grow into correct, modern education.

I'm editing the sidebar on one of our websites, and shuffling some entries. It involves moving some entries in/out of a dropdown and contextual sidebars, in/out of submenus, etc. It sounds a little tedious but overall pretty trivial, right?

This is day three.
I learned React+Redux from scratch (and rebuilt the latter for fun) in twice that long.

In my defense, I've been working on other tasks (see: Alerts), but mostly because I'd rather gouge my freaking eyes out than continue on this one.

Everything that could be wrong about this is. Everything that could be over-engineered is. Everything that could be written worse... can't, actually; it's awful.

Major grievances:
1) The sidebars (yes, there are several) are spread across a ridiculous number of folders. I stopped counting at 20.
2) Instead of icon fonts, this uses multiple images for entry states.
3) The image filenames don't match the menu entry names. at all. ("sb_gifts.png" -> orders); active filenames are e.g. "sb_giftsactive.png"
4) The actions don't match the menu entry names.
5) Menu state is handled within the root application controller, and doesn't use bools, but strings. (and these state flags never seem to get reset anywhere...)
6) These strings are used to construct the image filenames within the sidebar views/partials.
7) Sometimes access restrictions (employee, manager, etc.) are around the individual menu entries, sometimes they're around a partial include, meaning it's extremely difficult to determine which menu entries/sections/subsections are permission-locked without digging through everything.
8) Within different conditionals there are duplicate blocks markup, with duplicate includes, that end up render different partials/markup due to different state.
9) There are parent tags outside of includes, such as `<ul>#{render 'horrific-eye-stabbing'}</ul>`
10) The markup differs per location: sometimes it's a huge blob of non-semantic filthiness, sometimes it's a simple div+span. Example filth: section->p->a->(img,span) ... per menu entry.
11) In some places, the markup is broken, e.g. `<li><u>...</li></u>`
12) In other places, markup is used for layout adjustments, such as an single &nbsp; nested within several divs adorned with lots of styles/classes.
13) Per-device layouts are handled, not within separate views, but by conditionally enabling/disabling swaths of markup, e.g. (if is_cordova_session?).
14) `is_cordova_session` in particular is stored within a cookie that does not expire, and within your user session. disabling it is annoying and very non-obvious. It can get set whether or not you're using cordova.
15) There are virtually no stylesheets; almost everything is inline (but of course not actually everything), which makes for fun layout debugging.
16) Some of the markup (with inline styling, no less) is generated within a goddamn controller.
17) The markup does use css classes, but it's predominately not for actual styling: they're used to pick out elements within unit tests. An example class name: "hide-for-medium-down"; and no, I can't figure out what it means, even when looking at the tests that use it. There are no styles attached to that particular class.
18) The tests have not been updated for three years, and that last update was an rspec version bump.
19) Mixed tabs and spaces, with mixed indentation level (given spaces, it's sometimes 2, 4, 4, 5, or 6, and sometimes one of those levels consistently, plus an extra space thereafter.)
20) Intentional assignment within conditionals (`if var=possibly_nil_return_value()`)
21) hardcoded (and occasionally incorrect) values/urls.

... and last but not least:
22) Adding a new "menu sections unit" (I still haven't determined what the crap that means) requires changing two constants and writing a goddamn database migration.

I'm not even including minor annoyances like non-enclosed ternaries, poor naming conventions, commented out code, highly inefficient code, a 512-character regex (at least it's even, right?), etc.

just.

what the _fuck_

Who knew a sidebar could be so utterly convoluted?

The rants I read here make me want to be a better developer. I started writing tests, linting code and ensuring 'quality code' because of the devrant community. Being a self taught developer, you never really have anyone to thank. But today I would like to appriciate you all for the rants, comments and advice that make us developers become better at our craft.

I just released a tiny game for iPhone!

It's basically an attempt to mix 'Heroes of Might & Magic' and mtg.

In the screenshot my terminal says 'helloworld.cpp'. That's right, this is my first c++ program and I don't care how crappy you think this game is, I'm super proud of myself!

I've always worked in data science where managers assume I know how to code because there's text on my screen and I can query and wrangle data, but I actually didn't know what a class was until like 3 years into my job.

Making this game was my attempt to really evolve myself away from just statistics / data transforms into actual programming. It took me forever but I'm really happy I did it

It was brutal at first using C++ instead of R/Python that data science people usually use, but now I start to wonder why it isn't more popular. Everything is so insanely fast. You really get a better idea of what your computer is actually doing instead of just standing on engineers' shoulders. It's great.

After the game was 90% finished (LOL) I started using Swift and Spritekit to get the visuals on the screen and working on iPhone. That was less fun. I didn't understand how to use xCode at all or how to keep writing tests, so I stopped doing TDD because I was '90% done anyway' and 'surely I'll figure out how to do basic debugging'. I'll know better next time...

I'm fixing a security exploit, and it's a goddamn mountain of fuckups.

First, some idiot (read: the legendary dev himself) decided to use a gem to do some basic fucking searching instead of writing a simple fucking query.

Second, security ... didn't just drop the ball, they shit on it and flushed it down the toilet. The gem in question allows users to search by FUCKING EVERYTHING on EVERY FUCKING TABLE IN THE DB using really nice tools, actually, that let you do fancy things like traverse all the internal associations to find the users table, then list all users whose password reset hashes begin with "a" then "ab" then "abc" ... Want to steal an account? Hell, want to automate stealing all accounts? Only takes a few hundred requests apiece! Oooh, there's CC data, too, and its encryption keys!

Third, the gem does actually allow whitelisting associations, methods, etc. but ... well, the documentation actually recommends against it for whatever fucking reason, and that whitelisting is about as fine-grained as a club. You wanna restrict it to accessing the "name" column, but it needs to access both the "site" and "user" tables? Cool, users can now access site.name AND user.name... which is PII and totally leads to hefty fines. Thanks!

Fourth. If the gem can't access something thanks to the whitelist, it doesn't catch the exception and give you a useful error message or anything, no way. It just throws NoMethodErrors because fuck you. Good luck figuring out what they mean, especially if you have no idea you're even using the fucking thing.

Fifth. Thanks to the follower mentality prevalent in this hellhole, this shit is now used in a lot of places (and all indirectly!) so there's no searching for uses. Once I banhammer everything... well, loads of shit is going to break, and I won't have a fucking clue where because very few of these brainless sheep write decent test coverage (or even fucking write view tests), so I'll be doing tons of manual fucking testing. Oh, and I only have a week to finish everything, because fucking of course.

So, in summary. The stupid and lazy (and legendary!) dev fucked up. The stupid gem's author fucked up, and kept fucking up. The stupid devs followed the first fuckup's lead and repeated his fuck up, and fucked up on their own some more. It's fuckups all the fucking way down.

I jump on an existing scala project.

git pull && sbt compile test

Tests are failing.

Me: "Hey team, the tests are failing."

Team member: "That cannot be. They were passing for the the last run."

Me: "Did you run them locally?"

Team member: "No, on Jenkins. It was fine."

I check Jenkins.

Me: "What do you mean it's fine. The last successful deployment was on the end of May."

Team member: "The Pull Request checker always went through successfully."

I check how our Jenkins tasks are configured. It's true that the Pull Request Checker runs successfully yet due to a "minor misconfiguration" (aka "major fuckup") the Pull Request Checker only tests a tiny subset of the entire test suite.

Team members were were fine if their Pull Request got the "Success" notification on bitbucket's pull request page. And reviewers trusted that icon as well.

They never checked the master run of the Jenkins task. Where the tests were also failing for over a month.

I'm also highely confused how they did TDD. You know, writing a test first, making it green. (I hope they were just one specific test at a time assuming the others were green. The cynic in me assumes they outsourced running the tests to the Jenkins.)

Gnarf!

Team member having run the tests locally finally realizes: "The tests are broken. Gonna fix them."

Wow. Please, dear fellow developers: It does not kill you to run the entire test suite locally. Just do it. Treat the external test runners as a safety net. Yet always run the test suite locally first.

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.

I hate, HATE MYSELF!! I am an awful developer. I am an awful person.
I am trying so hard. To be a better person. To be a better developer. But, as a person I am again finding it difficult to empathize. At work, I really want to explore MERN stack but that I have to do it out of working hours. And damn! work is too much, I don't get time.
I need to work on a new project, for 2 months the discussions with MILLION TEAMS ARE GOING ON!!! NOTHING!! NOBODY HAS ANY IDEA!! THEY MIGHT FIRE ME!! I AM STRESSED!!
IT'S 1AM HERE AND I AM WRITING UNIT TESTS!! I want to cry. I want a partner maybe who can support me or maybe it's my mood swings.

writing library code is hard.

there are sooo many details that go into writing good libraries:

designing intuitive and powerful apis
deciding good api option defaults, disallowing or warning for illegal operations

knowing when to throw, knowing when to warn/log
handling edge cases
having good code coverage with tests that doesn't suck shit, while ensuring thry don't take a hundred years to run

making the code easy to read, to maintain, robust
and also not vulnerable, which is probably the most overlooked quality.

"too many classes, too little classes"

the functions do too much it's hard to follow them
or the functions are so well abstracted, that every function has 1 line of code, resulting in code that is even harder to understand or debug (have fun drowning in those immense stack traces)

don't forget to be disciplined about the documentation.

most of these things are
deeply affected by the ecosystem, the tools of the language you're writing this in:

like 5 years ago I hated coding in nodejs, because I didn't know about linters, and now we have tools like eslint or babel, so it's more passable now

but now dealing with webpack/babel configs and plugins can literally obliterate your asshole.

some languages don't even have a stable line by line debugger (hard pass for me)

then there's also the several phases of the project:

you first conceive the idea, the api, and try to implement it, write some md's of usage examples.

as you do that, you iterate on the api, you notice that it could better, so you redesign it. once, twice, thrice.

so at that point you're spending days, weeks on this side project, and your boss is like "what the fuck are you doing right now?"

then, you reach fuckinnnnng 0.1.0, with a "frozen" api, put it on github with a shitton of badges like the badge whore you are.

then you drop it on forums, and slack communities and irc, and what do you get?

half of the community wants to ban you for doing self promotion

the other half thinks either
a) your library api is shitty
b) has no real need for it
c) "why reinvent the wheel bruh"

that's one scenario,

the other scenario is the project starts to get traction.

people start to star it and shit.
but now you have one peoblem you didn't have before: humans.

all sorts of shit:

people treating you like shit as if they were premium users.

people posting majestically written issues with titles like "people help, me no work, here" with bodies like "HAAAAAAAAAALP".

and if you have the blessing to work in the current js ecosystem, issues like "this doesn't work with esm, unpkg, cdnjs, babel, webpack, parcel, buble, A BROWSER".
with some occasional lunatic complaining about IE 4 having a very weird, obscure bug.

not the best prospect either.

I'm working in a blockchain company for $180 as a junior programmer and there is a mid-senior guy who get ~8 times more than me. So we got a project to make a backend API with its tests. When I was partly completed my part of the project I asked that "mid-senior" to share his code with me. Nothing was done, and he asked me to push my changes to git so he could start to do something (view at my code and start copying). BUT. He couldn't even pull from git. He couldn't use that fucking Visual studio's team explorer and even the solution explorer. Ok, he was working with VS for the first time, but I did too. I cloned the repo gave him the environment to start "working" and get back to my work. After that nothing changed, he was writing each one-lined if block for half hour and the code was very dirty. Finally I've got his laptop and started to writing his part by teaching him all the programming. You may say I'm mad. I really do, I think that I did all project. This is sad... How can people get this much by being this far from the programming? We need really high quality programmers.

(Best read while listening to AEnima by Tool, loudly)

Dear Current Workplace,

Fuck you, for the reasons enumerated below.

Fuck your enterprise grey blue offices, the stifling warm air of a hundreds of bodies and sub par "development laptops".

Fuck your shitty carbonated water machines which were a cost saving measure over decent drinkable water.

Fuck your fake "flexi time", "you can do home office whenever you want" bullshit. You're still inviting me to mandatory meetings at 09:00 regularly.

Fuck your shitty, in house, third part IT provider sister company. They're the worst of all worlds. If it was in company, we'd get to give out to them, if it was an external company we'd fire them. And yes, when I quit I will quote the dumpster fire that is our corporate VPN as a major factor.

Fuck your cheery, bland, enterprise communication. Words coming under the corporate letterhead seem to lose all association with meaning. Agile, communication, open are things you write and profess to respect, but it seems your totally lack understanding of their meaning.

Fuck your client driven development. Sometime you actually have to fix the foundations before you can actually add new features. And fuck you management who keep on asking "why are there so many bugs and why is it always taking longer to deliver new releases". Because of you, you fucknuts, Because you can't say "NO" to the customer. Because you never listen to your own experienced developers.

Fuck your bullshit "code quality is important to us" line. If it's so important, then let us fix the heap of shit you're selling so that it works like a quasi functional program.

Fuck you development environment which has 250 projects in a single VS solution. Which takes 5mins plus to compile on a quad core i7 with 32 gb of ram.

Fuck this bullshit ball of mud "architecture". I spend most of my time trying to figure out where the logic should go and the rest of the time writing converters between different components. All because 7 years ago some idiot "architect" made a decision that they didn't have to live with.

Actually, fuck that guy in particular. Yeah, that guy who was the responsible architect for the project for 4 years and not once opened the solution to look a the code.

Fuck the manual testing of every business process. Manual setup of the entities takes 10mins plus and then when you run, boom either no message or some bullshit error code.

Fuck the antiquated technology choices which cause loads of bugs and slow down development. Fuck you for forcing me to do manual tests of another developers code at 20:00 on a Friday night because we can't get our act together to do this automatically.

Fuck you for making sure it's very clear I'm never going to be anything but a code monkey in this structure. Managers are brought in from outside.

Fuck you for being surprised that it's hard to hire competent developers in this second rate, overpriced town. It's hard to hire anywhere but this bland shithole would have anyone with half a clue running away at top speed.

Fuck you for valuing long hours and loyalty over actual performance. That one guy who everyone hated and was totally incompetent couldn't even get himself fired. He had to quit.

Fuck you for your mediocrity.

Fuck you for being the only employer for my skill-set in the region; paying just well enough that changing jobs locally doesn't make sense, but badly enough that it's difficult to move.

Fuck you for being the stable "safe" option so that any move is "risky".

Fuck your mediocrity.

Fuck you for being something I think about when I'm not at work. Not only is it shit from 9 to 5 you manage to suck the joy out of everything else in my life as well?

Fuck you for making me feel like a worse developer every day I work here. Fuck you for making every day feel like a personal and professional failure. Fuck you for making me seriously leave a career I love for something, anything else.

Fuck you for making the most I can hope for when I get up in the morning is to just make it until the night.

They've literally left me with nothing to do. I'm doing nothing. I can't be happy doing nothing.

To illustrate the chaos: Everyone on the team was trying to figure out some defect. No one knows what is going on in the code. It's unlike anything I've ever seen.

I found an API call with a misspelled endpoint. It was wrong since the code was written two months before. There's no way it ever worked. Obviously no one tested the code because they would have immediately seen that the call returned a 404 every time.

I fixed it. That was my only PR in about a month. It was literally one character.

The next week that PR got reverted. Apparently the app works better if the API call fails. No one said what goes wrong if the request is made, just that it "causes problems."

That's how bad it is. No one knows why anything does or doesn't work. People write code that doesn't work, never test it, and the application works better in some unspecified way if that code never gets executed.

The last straw for me was when an architect told us that if we want to improve our skills we need to learn how to read and debug stuff like this.

1) Not to be immodest, but I'm good at figuring out bad code.
2) Just because I can doesn't mean I want to do it all day instead of actually developing software
3) He trivialized the really important skill, not making a mess like this in the first place. If his idea of skill is to sling crap without tests at the wall and then debug it, how is he an architect?

I tried really hard but I can't keep a good attitude. I don't want to become toxic, but why would I consider working that way? I try my best to be good at this. Writing decent code means a lot to me. It should mean a lot to them. Their code is costing them hundreds of thousands of dollars. Maybe millions.

I can't write good code and add value if all I do is debug bad code.

So I'm out. I'm going to another project. Have a nice life.

How I spend my days at work working with legacy code:

* Writing tests before I do anything
* Noticing that i cannot write tests because of antipatterns. Lots of them.
* Refactoring to make at least a tiny bit testable.
* Then writing tests.
* More rewriting and refactoring
* Finally adding that one feature my boss asked me for
* Writing tests for that new feature (my do that before implementing)
* Explaining to my boss why it took me so long and agreeing on stopping writing tests.
* 2 days later: explaining why i still broke something.

But in the end my code works just fine.
my colleagues handle things differently. They just ignore problems as long as at least one feature works a bit.

"We don't have time for writing tests"
"Yeah we could write them but only if the client paid us for that"
"You can just test new features manually!"

- Most devs of our mobile team.

Every day they're fighting with bugs and when they're fixed, a couple more pop out of nowhere.

Dear god help me.

Write only one unit test, so I don't feel bad for not writing unit tests.

I have to refactor code from an intern. He's VERY lucky that he already left the company.

If I'd say he programms like the first human that would be very insulting to that first human.

It looks like code at first sight, but when you try to understand what he was doing to achieve his goal you get a brainfuck. Duplicate code, unused code, dumb variable names like blRszN.

He wrote unittests like "expects Exception to be thrown or Server returns Statuscode 500".
Yes, Exception, the generic one.

THESE FUCKING TESTS ARE GREEN BECAUSE YOU DID NOT ACTUALLY TEST SOMETHING.
GREEN IN THIS CONTEXT MEANS: YOUR PRODUCTION CODE IS A BIG PILE OF SHIT.

I already removed 2 bugs in a test which caused another exception than the "expected" one and the test does still not reach the actual method under test.

Dumb fucktard.

The sad thing: The fuckers who did the code reviews and let this shit pass are still here writing code.

Staying up all night writing tests trying to get 100% code covfefe

TeamLeader: I need you to stop disagreeing with the decision of the management, the people in there are taking their decision for a reason.

IHateForALiving: When integration tests were failing, the management decided to comment out the ingration tests; god knows how many bugs slipped by.
When users had problems with the idiotic migration process the management designed, the management decided to remove down migrations; it took two weeks before the QA team started screaming, as all their machines were filled with garbage data.
I was writing type definitions for my code, you removed it. You effectively ensured the only person capable of working on that particular piece of code would be me.
I have been proposing for 8 months to make a unified scheduled jobs system, you all decided to create at least 5 different -and incompatible- implementations, at least 4 of them are total garbage with setTimeout, there's no way to ever unify them and God willing they never break, if they do there's NO WAY to find out even where tf they're hidden in the code.
Every time you were making one of those bad decision I was the only one warning you of the problems you were creating. The idiotic change of the day is going MongoDB+Angular: I can keep a low profile if you want, but when this blows up you can be damn well sure I'll handle my 2 weeks notice because there's no way on earth I'll be stuck with the aftermath of you lot taking technical decisions you are clearly unable to manage.

"I'm almost done, I'll just need to add tests!"

Booom! You did it, that was a nuke going off in my head.

No, you shouldn't just need to add tests. The tests should have been written from the get go! You most likely won't cover all the cases. You won't know if adding the tests will break your feature, as you had none, as you refactor your untested mess in order to make your code testable.

When reading your mess of a test case and the painful mocking process you went through, I silently cry out into the void: "Why oh why!? All of this suffering could have been avoided!"

Since most of the time, your mocking pain boils down to not understanding what your "unit" in your "unit test" should be.

So let it be said:

- If you want to build a parser for an XML file, then just write a function / class whose *only* purpose is: parse the XML file, return a value object. That's it. Nothing more, nothing less.
- If you want to build a parser for an XML file, it MUST NOT: download a zip, extract that zip, merge all those files to one big file, parse that big file, talk to some other random APIs as a side-effect, and then return a value object.

Because then you suddenly have to mock away a http service and deal with zip files in your test cases.

The http util of your programming language will most likely work. Your unzip library will most likely work. So just assume it working. There are valid use cases where you want to make sure you acutally send a request and get a response, yet I am talking unit test here only.

In the scope of a class, keep the public methods to a reasonable minimum. As for each public method you shall at least create one test case. If you ever have the feeling "I want to test that private method" replace that statement in your head with: "I should extract that functionality to a new class where that method public. I then can create a unit test case a for that." That new service then becomes a dependency in your current service. Problem solved.

Also, mocking away dependencies should a simple process. If your mocking process fills half the screen, your test setup is overly complicated and your class is doing too much.

That's why I currently dig functional programming so much. When you build pure functions without side effects, unit tests are easy to write. Yet you can apply pure functions to OOP as well (to a degree). Embrace immutability.

Sidenote:

It's really not helpful that a lot of developers don't understand the difference between unit, functional acceptance, integration testing. Then they wonder why they can't test something easily, write overly complex test cases, until someone points out to them: No, in the scope of unit tests, we don't need to test our persistance layer. We just assume that it works. We should only test our businsess logic. You know: "Assuming that I get that response from the database, I expect that to happen." You don't need a test db, make a real query against that, in order to test that. (That still is a valid thing to do. Yet not in the scope of unit tests.)

Ticket: This API param doesn’t work.
Ticket Size: 1 story point / extra small baby fries

Found the issue almost immediately: some fucked up date math. Or at least backwards as hell. I don’t know. I don’t care.

There’s no spec for it, and writing it is a bitch. None of the API test helpers are designed for end-to-end tests. Why? I don’t care. They’re stupid. They all just break. And the API does weird shit like fucking redirects to an HTML page. Which is… i don’t know. They mix up API and embedded sessions a bunch, so who knows if this is right or broken as fuck.

I can’t deal with this shit anymore.
It’s just mountains of fucking garbage. Every time I dig into anything, anywhere in this codebase, or, let’s be honest: the entire goddamn company, it’s just more fucking garbage. The code is garbage. The specs are garbage. The people are garbage. The woke crap they love so much is garbage. The industry is garbage. The macs we’re required to use are garbage. The strongly-encouraged editor is garbage. The new hires are garbage. The legendary devs are garbage. The VPN is garbage — still haven’t gotten it to fucking work outside of fucking Safari, which is also garbage. The meetings are garbage. The “culture” is garbage. The “raises” are garbage. The thirty-step dance ceremony for each ticket is garbage. The literal fucking garbage at the office is the best part of the entire goddamn landfill.

And yeah, over half of the code that’s been giving me problems on this ticket was written by the same dev: The legendary golden garbage boy himself.

Just.
Fucking hell.

I’m going back to looking for work again. I can’t do this anymore.

Skipping unit tests and documentation ...

I'm starting to recover after not writing a single test for the first 6 years of my professional carrer (wasn't taught in school, didn't know where to start, man I should have really found a mentor earlier), and barely any documentation (I was the sole developer for several years, and just didn't get into the habbit).

Unit testing is still not a habit, but now I have the first tests to serve as an example and an idea what/how to test at least, and I try to get every new "framework" function/class at least commented properly.

Wish me luck

Its all fun and games until your malfunctioning software costs people their lives - if you're just starting out as a dev or in the "ain't nobody got time for writing tests" camp, I highly recommend you to lookup and read about the Therac-25 incidents during the 80s.

Even if you're not working on a life-critical/mission-critical application, the realization of the impact that us devs can have on the society can push you to become a better developer producing quality software...

Working in the embedded systems industry for most of my life, I can tell you methodical testing by the software engineers is significantly lacking. Compared to the higher level language development with unit tests and etc, something i think the higher level abstracted industry actually hit out the of park successfully.

The culture around unit testing and testing in general is far superior in java and the rest.

Down here in embedded all too often I hear “well it worked on my setup... it worked at my desk”.. or Oh I forgot to test that part.. or I didn’t think that perticular value could get passed in... etc I’ve heard it all. Then I’ve also heard, you can’t do TTD or unit tests like high level on embedded... HORSESHIT!

You most definitely can! This book is a great book to prove a point or use as confirmation you are doing things correctly. My history with this book was I gonna as doing my own technique of unit testing based on my experience in the high level. Was it perfect no but I caught much more than if I hadn’t done the testing. THEN I found this book, and was like ohh cool I’m glad I’m on the right thought process because essentially what they were doing in the book is what I was doing just slightly less structured and missing a few things.

I’ve seen coworkers immediately think it’s impossible to utilize host testing .. wrong.

Come to find out most the of problems actually are related to lack of abstraction or for thought out into software system design by many lone wolf embedded developers.. either being alone, or not having to think about repercussions of writing direct register writes in application or creating 1500 line “main functions” because their perception is “main = application”. (Not everyone is like this) but it seems to be related to the EEs writing code ( they don’t know wha the CS knows) and CS writing over abstraction and won’t fit on Embedded... then you have CEs that either get both sides or don’t.. the ones to understand the low level need but also get high level concepts and pariadigms and adapt them to low level requirements BOOM those are the special folks.

ANYway..the book is great because it’s a great beginner book for those embedded folks who don’t understand what TDD is or Unit testing and think they can’t do it because they are embedded. So all they do is AdHoc testing on the fly no recording results no concluding data very quick spot check and done....

If your embedded software engineers say they can’t unit test or do TDD or anything other than AdHoc Testing...Throw the book at them and say you want the unit test results report by next week Friday and walk away.

Lol

I am extremely particular about writing good READMEs in my repositories. I make sure that it has everything from prerequisites to run the code and tests on a new machine to how to actually run it (and the tests) and everything in between.

Despite all that I was asked questions that should have been avoided if you had seen the README.

One of these times was by a junior DevOps asking me about an error which was clearly due to him running the code without a virtual environment. Pings me with the entire stacktrace, I go to his desk and tell him to install the environment, which he does. 3 minutes later, another error message.

He was running the wrong script. I go to his desk again. Open the repository. Show him the README. Show him the section titled "To run the pipeline"!

There's a reason they're called README. You're supposed to READ them! 😑

I saw this on the first page of a book that discusses techniques for writing clean code... The more I think about it, the more accurate it tests.

Out of necessity (or rather: lack of support) I've been neglecting my test suite for the past ~month. Now that one of the beta versions of RSpec has better Rails 6 support, I can finally get back to writing tests. Yay!

I just merged staging into my testing branch, and it's now 344 commits ahead of origin! eep.

So, I've got lots of tests to write. yay.

First day on my first job ever, the boss asks me what I want to do. I indicated that I had some experience with php and the yii framework (which was at some point very cool xD), so I wanted to start with something like that. And so it goes: after two days of watching laracasts (which is an awesome platform by the way! :O) I got assigned to a project.

Now the company I work at uses some kind of self built system that tracks how many hours are spent on which project, and compares that to how many hours was estimated implementing a feature would take. That's cool, but then I saw that for the project I was working on the time estimated was 5 work days. This was the estimate for both designing the interfaces and implementing both front and backend. I knew in advance that this was probably way to little time for me, but didn't want to come over as the new kid who can't do shit x)

Anyway, I started on the project and was having fun, but the biggest time consuming aspect of the project was not necessarily that I didn't have enough experience: it was that the developer who started this project and made most of the design choices had written some very messy code, without tests or apparently any refactoring. Also, everything was extremly inconsistent and not according to all the best practices I just watched in my laracasts spree.

So fastforward a little: we're way over the estimated hours. Yay. Now suddenly the boss comes by with an almost angry face that the client is becoming angry and we need to finish soon. He makes it entirely our (me and the front end guy) problem and I just decide to say nothing and try to work faster.

Now I'm stuck writing fugly code on top of more fugly code and when I mentioned to my front end guy that I was almost finished with feature but I only needed to finish up the tests, he said something like "oh just don't write tests, that'll take too long"... Is that really the mindset of this company?! No wonder the project I work on was in a very bad state.

Thanks to devrant I see now that I just need to say something if I know that I won't be able to complete something in a certain amount of time and that other people are just like me (thank god). :) I think I'll need to post more rants to vent my frustrations x)

Not writing unit tests :(

Sometimes I really fucking hate this company

The code is an absolute shitshow filled with static classes, untestable and duplicate code, on top of that my boss doesn’t like open source

Yeah so i’m not allowed to use a mapping library or something because “Uhhh like uhh we don’t have a contract with the company so who knows what’ll happen when the maintainers leave the project”
I understand his reasoning but it’s an absolutely retarded reasoning especially considering most of the .NET platform is open source nowadays

Writing a webapp from scratch now as well and I HAVE to use vanilla javascript and AngularJS 1.5 even though all the developers here told me they would like to upgrade to Typescript and Angular 2+ but it’s never gonna happen I suppose

Oh and he doesn’t like TDD and our only product is SAAS so imagine the amount of bugs being pushed simply because we don’t have time to write tests or even manually test, let alone refactor our horseshit codebase

AND i have to pay for gas myself which takes 200€ out of my bank account a month just for driving to work whilst I’m only getting a mediocre pay

Have a job interview tomorrow and another one on tuesday

A discussion about writing tests for frontend applications.

Context: my frontend coworkers don't write tests, at all. Yeah, really. Our testing process is very manual. We test manually when developing. We test manually when reviewing code. After merging, the application is deployed to a staging server and the design team does a QA Sprint. Lots of manual testing and some bugs still crawl by.

So I decided to start pushing my coworkers to start writing tests. One of the reasons I constantly hear them say to not write tests in the frontend is: "It's not worth the time, because design keeps changing, which means we have to take time to fix the tests. Time that we usually don't have."

I've been thinking about this a lot and it seems to me that this is more related to bad tests than to tests in general.

Tests should not break with design changes (small changes at least). They should test funcionality, not how things look. A form should not break if the submit button's style changes, so why should its tests fail? I also think that tests help save time, as they prevent some back and forth because of bugs.

Writing good tests is the hard part. Tests that cover what's really important and aren't frail and break with things that shouldn't break them. What (and how) should we test? And what shouldn't be tested?

Writing them fast is another hard thing. Are you doing it right if they take more time to write than the actual code?

What do you think about this? Do you write tests for your frontend applications? What do you test? How much time do you spend writing tests? What are your testing tools/frameworks?

Wanna have 120% code of code coverage? Start writing test for unit tests.

Has anyone felt the astonishing effect that is writing a whole bunch of test classes, hitting run for the first time and they all pass.

I'm kinda sitting here staring at my screen in disbelief, either these tests all passed, or I've really missed something and they passed anyway, or it's just a lying piece of shit trying to question my own abilities... all are possible right now.

And no, they are not " assert(1,1) "

I just wrote 80+ lines of tests for a 30 line module and I was really mad at myself for wasting my time like that, until I remembered that while writing those tests I did actually catch several really tricky bugs and it didn't even take that long.

Germany trying to fight Covid with digital tools (at least not another app today): registered for a test with QR-Code, Webform and E-Mail. After being tested by friendly people, I received an email that contains a link to a download of a PDF document.

Inside the PDF, a QR code, and a bureaucratic text like during the time of the Prussian emperor: "Bescheinigung über das Vorliegen eines positiven oder negativen Tests (Antigen Schnelltest) zum Nachweis des SARS-CoV-2 Virus".

Okay, we have a national "Corona Warn App" using Google's bluetooth based distancing detection, that also allows to add a test by scanning a QR code.

Scanned the code, got

"QR code is invalid".

Despite the unfriendly UX writing and the unhelpful description, another proof of the state of digitalization in Germany in 2021.

I am not even surprised.

At least my test result is negative.

I skip writing unit tests. YOLO.

I AM TIRED

warning: this rant is going to be full of negativity , CAPS, and cursing.

People always think and they always write that programming is an analytical profession. IF YOU CANNOT THINK IN AN ANALYTICAL WAY THIS JOB IS NOT FOR YOU! But the reality could not be farther from the truth.

A LOT of people in this field whether they're technical people or otherwise, just lack any kind of reasoning or "ANALYTICAL" thinking skills. If anything, a lot of of them are delusional and/or they just care about looking COOL. "Because programming is like getting paid to solve puzzles" *insert stupid retarded laugh here*.

A lot of devs out there just read a book or two and read a Medium article by another wannabe, now think they're hot shit. They know what they're doing. They're the gods of "clean" and "modular" design and all companies should be in AWE of their skills paralleled only by those of deities!

Everyone out there and their Neanderthal ancestor from start-up founders to developers think they're the next Google/Amazon/Facebook/*insert fancy shitty tech company*.

Founder? THEY WANT TO MOVE FAST AND GET TO MARKET FAST WITH STUPID DEADLINES! even if it's not necessary. Why? BECAUSE YOU INFERIOR DEVELOPER HAVE NOT READ THE STUPID HOT PILE OF GARBAGE I READ ONLINE BY THE POEPLE I BLINDLY COPY! "IF YOU'RE NOT EMBARRASSED BY THE FIRST VERSION OF YOU APP, YOU DID SOMETHING WRONG" - someone at Amazon.

Well you delusional brainless piece of stupidity, YOU ARE NOT AMAZON. THE FIRST VERSION THAT THIS AMAZON FOUNDER IS EMBARRASSED ABOUT IS WHAT YOU JERK OFF TO AT NIGHT! IT IS WHAT YOU DREAM ABOUT HAVING!

And oh let's not forget the tech stacks that make absolutely no fucking sense and are just a pile of glue and abstraction levels on top of abstraction levels that are being used everywhere. Why? BECAUSE GOOGLE DOES IT THAT WAY DUH!! And when Google (or any other fancy shit company) changes it, the old shitty tech stack that by some miracle you got to work and everyone is writing in, is now all of a sudden OBSOLETE! IT IS OLD. NO ONE IS WRITING SHIT IN THAT ANYMORE!

And oh my god do I get a PTSD every time I hear a stupid fucker saying shit like "clean architecture" "clean shit" "best practice". Because I have yet to see someone whose sentences HAVE TO HAVE one of these words in them, that actually writes anything decent. They say this shit because of some garbage article they read online and in reality when you look at their code it is hot heap of horseshit after eating something rancid. NOTHING IS CLEAN ABOUT IT. NOTHING IS DONE RIGHT. AND OH GOD IF THAT PERSON WAS YOUR TECH MANAGER AND YOU HAVE TO LISTEN TO THEM RUNNING THEIR SHITHOLE ABOUT HOW YOUR SIMPLE CODE IS "NOT CLEAN". And when you think that there might be a valid reason to why they're doing things that way, you get an answer of someone in an interview who's been asked about something they don't know, but they're trying to BS their way to sounding smart and knowledgable. 0 logic 0 reason 0 brain.

Let me give you a couple of examples from my unfortunate encounters in the land of the delusional.

I was working at this start up which is fairly successful and there was this guy responsible for developing the front-end of their website using ReactJS and they're using Redux (WHOSE SOLE PURPOSE IS TO ELIMINATE PASSING ATTRIBUTES FOR THE PURPOSE OF PASSING THEM DOWN THE COMPONENT HIERARCHY AGIAN). This guy kept ranting about their quality and their shit every single time we had a conversation about the code while I was getting to know everything. Also keep in mind he was the one who decided to use Redux. Low and behold there was this component which has THIRTY MOTHERFUCKING SEVEN PROPERTIES WHOSE SOLE PURPOSE IS BE PASSED DOWN AGAIN LIKE 3 TO 4 TIMES!.

This stupid shit kept telling me to write code in a "functional" style. AND ALL HE KNOWS ABOUT FUNCTIONAL PROGRAMMING IS USING MAP, FILTER, REDUCE! And says shit like "WE DONT NEED UNIT TESTS BECAUSE FUNCTIONAL PROGRAMMING HAS NO ERRORS!" Later on I found that he read a book about functional programming in JS and now he fucking thinks he knows what functional programming is! Oh I forgot to mention that the body of his "maps" is like 70 fucking lines of code!

Another fin-tech company I worked at had a quote from Machiavelli's The Prince on EACH FUCKING DESK:

"There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things."

MOTHERFUCKER! NEW ORDER OF THINGS? THERE 10 OTHER COMPANIES DOING THE SAME SHIT ALREADY!

And the one that got on my nerves as a space lover. Is a quote from Kennedy's speech about going to the moon in the 60s "We choose to go to the moon and do the hard things ..."

YOU FUCKING DELUSIONAL CUNT! YOU THINK BUILDING YOUR SHITTY COPY PASTED START UP IS COMPARABLE TO GOING TO THE MOON IN THE 60S?

I am just tired of all those fuckers.

* Ctrl+Shift+F to find all "assert" in solution...

Matching lines: 0 Matching files: 0 Total files searched: 1504

* Bang head on table

* Flip Table

* Start writing unit tests

Sort of !dev

I can't do school anymore. I get so many panic attacks. I was shaking the entire time I was writing my essay today. It's hard to focus when your brain is fucking freaking out. I'm missing deadlines, failing tests left and right.

Real talk, I'm not dumb. This was never a problem. My University fucked me up and now I can't even look at an assignment without an electric feeling and I don't know what to do.

I had a panic attack during the opening crawl of Star Wars. I had to leave the theater. My anxiety is going to give me a heart attack one of these times. I'm 18, why am I experiencing health issues like this?

School isn't done right. How could this be the intended effect?

Not sure if it was 2016 or late 2015, but it's a fun story anyway (and if it's not you'll at least learn something from it).

Back at the time I was quite new to unit testing (weird how it has become second nature in a years time). I was writing some software that was supposed to send out some SMS to customers. Of course this had to be tested. However, it was a bit difficult to test (or so I thought) without actually receiving an SMS to know if it was sent. So I decided to use the live API key to make sure the sending of SMS was actually working correctly. I tried it a few times but didn't receive an SMS. So I kept working on it and running tests.

The testing setup I had at the time was just a continues loop that went through all tests to make sure it all still worked (I've moved to only checking on file changes now, but that is besides the point). Keep in mind I was still running these tests, in a loop, with the _live_ API key.

So the end of the working day arrives and I go home and sit in the train. All of the sudden I receive some test SMS. I was thinking "hey nice, it did work". Then I started receiving more. It soon turned out to be an alarmingly big amount of SMS. It stopped around 100, but don't think that was the end of it. Oh no. I had changed the number to send the SMS to from my own number to a different number (+31612345678 to be exact, which I found out later isn't an actual phone number. I really hope I was right about that). I was beginning to become nervous, but there wasn't much I could do.

The next day I returned to work and checked the API for sent SMS. Turns out I had sent a couple of thousand (I think between two and three thousand) SMS in a couple of hours. Most of them to the test number I had supplied.

This probably cost the company a couple of hundred euros. Luckily my colleagues and team leader all thought it was pretty funny, but did tell me not to do it again. And I haven't of course.

Lesson learned: don't use live API keys during testing (among other things :)).

So yeah that was probably my worst dev experience.

This is my first rant here, so I hope everyone has a good time reading it.

So, the company I am working for got me going on the task to do a rewrite of a firmware that was extended for about 20 years now. Which is fine, since all new machines will be on a new platform anyways. (The old firmware was written for an 8051 initially. That thing has 256 byte of ram. Just imagine the usage of unions and bitfields...)

So, me and a few colleagues go ahead and start from scratch.
In the meantime however, the client has hired one single lonely developer. Keep in mind that nobody there understands code!
And oh boy did he go nuts on the old code, only for having it used on the very last machine of the old platform, ever! Everything after that one will have our firmware!

There are other machines in that series, using the original extended firmware. Nothing is compatible, bootloaders do not match, memory layouts do not match, code is a horrible mess now, the client is writing the specification RIGHT NOW (mind, the machine is already sold to customers), there are no tests, and for the grand finale, the guy canceled his job and went to a different company. Did I mention the bugs it has and the features it lacks?

Guess who's got to maintain that single abomination of a firmware now?

I wrote a node + vue web app that consumes bing api and lets you block specific hosts with a click, and I have some thoughts I need to post somewhere.

My main motivation for this it is that the search results I've been getting with the big search engines are lacking a lot of quality. The SEO situation right now is very complex but the bottom line is that there is a lot of white hat SEO abuse.

Commercial companies are fucking up the internet very hard. Search results have become way too profit oriented thus unneutral. Personal blogs are becoming very rare. Information is losing quality and sites are losing identity. The internet is consollidating.

So, I decided to write something to help me give this situation the middle finger.

I wrote this because I consider the ability to block specific sites a basic universal right. If you were ripped off by a website or you just don't like it, then you should be able to block said site from your search results. It's not rocket science.

Google used to have this feature integrated but they removed it in 2013. They also had an extension that did this client side, but they removed it in 2018 too. We're years past the time where Google forgot their "Don't be evil" motto.

AFAIK, the only search engine on earth that lets you block sites is millionshort.com, but if you block too many sites, the performance degrades. And the company that runs it is a for profit too.

There is a third party extension that blocks sites called uBlacklist. The problem is that it only works on google. I wrote my app so as to escape google's tracking clutches, ads and their annoying products showing up in between my results.

But aside uBlacklist does the same thing as my app, including the limitation that this isn't an actual search engine, it's just filtering search results after they are generated.

This is far from ideal because filter results before the results are generated would be much more preferred.

But developing a search engine is prohibitively expensive to both index and rank pages for a single person. Which is sad, but can't do much about it.

I'm also thinking of implementing the ability promote certain sites, the opposite to blocking, so these promoted sites would get more priority within the results.

I guess I would have to move the promoted sites between all pages I fetched to the first page/s, but client side.

But this is suboptimal compared to having actual access to the rank algorithm, where you could promote sites in a smarter way, but again, I can't build a search engine by myself.

I'm using mongo to cache the results, so with a click of a button I can retrieve the results of a previous query without hitting bing. So far a couple of queries don't seem to bring much performance or space issues.

On using bing: bing is basically the only realiable API option I could find that was hobby cost worthy. Most microsoft products are usually my last choice.

Bing is giving me a 7 day free trial of their search API until I register a CC. They offer a free tier, but I'm not sure if that's only for these 7 days. Otherwise, I'm gonna need to pay like 5$.

Paying or not, having to use a CC to use this software I wrote sucks balls.

So far the usage of this app has resulted in me becoming more critical of sites and finding sites of better quality. I think overall it helps me to become a better programmer, all the while having better protection of my privacy.

One not upside is that I'm the only one curating myself, whereas I could benefit from other people that I trust own block/promote lists.

I will git push it somewhere at some point, but it does require some more work:
I would want to add a docker-compose script to make it easy to start, and I didn't write any tests unfortunately (I did use eslint for both apps, though).
The performance is not excellent (the app has not experienced blocks so far, but it does make the coolers spin after a bit) because the algorithms I wrote were very POC.
But it took me some time to write it, and I need to catch some breath.

There are other more open efforts that seem to be more ethical, but they are usually hard to use or just incomplete.

commoncrawl.org is a free index of the web. one problem I found is that it doesn't seem to index everything (for example, it doesn't seem to index the blog of a friend I know that has been writing for years and is indexed by google).

it also requires knowledge on reading warc files, which will surely require some time investment to learn.

it also seems kinda slow for responses,

it is also generated only once a month, and I would still have little idea on how to implement a pagerank algorithm, let alone code it.

i should be writing some unit tests for a customer project, but i brought my new nintendo switch to work and there is nobody else in this room... :D

"Coding se darr nahi lagta Sahab, Unit Tests likhne se lagta"

"Coding doesn't scare me Sir, writing Unit Tests does"

As a fresher, UTs scare me.

TDD.

I'm a fan of writing tests right after you write every module. I actually think it's doable.

But I'm not a big fan of traditional TDD, which is defined as: first writing the tests, making them fail, writing code until tests don't fail.

My experience with traditional TDD when writing library code is that you start with this very naive idea of what is needed, so you write classes and functions and a lot of times they look like overly simplistic pseudocode.

So what do you do? You scratch that, you delete those classes/functions several times.

I think this discovery process that your code is naive is slowed the fuck down by doing TDD.

I'd rather write a theoretical API in a readme file, then write code, and then write the tests, you can even withhold writing the tests, but never leaving them for another day, just so that you don't waste time writing tests that you're going to scratch.

There's always a time constraint, and most of us can't afford bikeshedding.

Traditional TDD feels like an esoteric thing, it tries to make programming a series of steps, it actually sounds like an infommercial.
"FOLLOW THESE 3 SIMPLE STEPS AND WRITE THE BEST CODE EVER"

When you're writing unit tests in xcode and it crashes and loses its syntax colouring and autocomplete. All of a sudden you're coding on textedit instead.

There you are, fiddling with next.js webpack settings, because your isomorphic JS-in-CSS-in-JS SSR fallback from react-native-web to react-dom throws a runtime error on your SSR prerendering server during isomorphic asynchronous data prefetching from Kubernetes backend-for-frontend edge-server with GraphQL.

You have all that tech to display a landing page with an email form, just to send spam emails with ten tracking links and five tracking beacons per email.

Your product can be replaced by an Excel document made in two days.

It was developed in two years by a team of ten developers crunching every day under twelve project managers that can be replaced with a parrot trained to say “Any updates?”

Your evaluation is $5M+. You have 10,000 dependency security warnings, 1000 likes on Product Hunt, 500 comments on Hacker News, and a popular Twitter account.

Your future looks bright. You finish your coffee, crack your knuckles and carry on writing unit tests.

"Let the developers consider a conceptual design,” the King said, for about the twentieth time that day._

“No, no!” said the Queen. “Tests first—design afterwards.”

“Stuff and nonsense!” said Alice loudly. “The idea of writing the tests first!”

“Hold your tongue!” said the Queen, turning purple. “How much code have you written recently, anyway?” she sneered.

“I won’t,” said the plucky little Alice. “Tests shouldn’t drive design, design should drive testing. Tests should verify that your code works as it was designed, and that it meets the customer’s requirements, too,” she added, surprised by her own insight. “And when you drive your tests from a conceptual design, you can test smarter instead of harder.”

I'm convinced this is going to be wildly unpopular, but hey...

Please stop writing stuff in C! Aside from a few niche areas (performance-critical, embedded, legacy etc. workloads) there's really no reason to other than some fumbled reason about "having full control over the hardware" and "not trusting these modern frameworks." I get it, it's what we all grew up with being the de-facto standard, but times have moved on, and the number of massive memory leaks & security holes that keep coming to light in *popular*, well-tested software is a great reason why you shouldn't think you're smart enough to avoid all those issues by taking full control yourself.

Especially, if like most C developers I've come across, you also shun things like unit tests as "something the QA department should worry about" 😬

People rant here about how they hate documenting things or writing tests or whatever.

Yes these things are not the most interesting but I have a feeling that we are forgetting about most horrendous of tasks - estimating. Especially in agencies. Especially related to altering legacy features. Especially big projects.

I mean, I'm spending time doing something that is basically dev's Voo Doo, hoping that I will be right... and usually I'm not.

Today I was writing Selenium tests and was struggling to find a good way to test a text editor. We did a weekly code review and my team lead rewrote the test ij 10 lines to generically handle all cases.

Hopefully I'll be a good dev someday. 😔

I used to hate writing tests, surprisingly now I’m kinda enjoying it this time.

when someone tells me unit tests are useful and I should start writing them

I stayed at work till 8:30 last night writing tests. It was awesome!

Got home and told Mom: "sorry, got carried away".

Product Owner keeps demanding developers do items outside of Sprint, deleted story points to get extra items in, signs off holiday for my staff, even hired some unqualified developers, etc. for my team (I'm the Dev Manager). I'm blessed to report into the PMO who backs up the Product Owner, in front my own reports, meaning I have no authority. What would you do?

PMO has decided that if we drag items from Sprint to Backlog when they reach SIT, we have more space for Dev items in the Sprint :-| Though he expects developers to actually do the SIT work, including writing the SIT tests :-|

!rant

Goodbye Java I will not miss you at all! I swear ...

I do like it when making web services (especially that I can use Java8) but for Android you have been a torture. Hello sweet Kotlin! I shall embrace you and treat you like my newly born baby!!

Story is:
Working on a new project where I need to talk to a web service (also made by me).
Started writing in Java, all is cool and unit tests pass.
Downloaded Android Studio 3 Beta 1 and converted my Java code to Kotlin, That AsyncTask did not look nice in kotlin, converted it to async & await feature and I must admit lots of code removed, no more need to create a new fucking AsyncTask every time the app sneezes for data!

I feel like I'm working with C# but with difference in syntax.
My life is now complete :)

(first post/rant on here)
So I recently started at a new company. I was kinda aware that the project I'm working on would be rather old school (to put it in a nice way :-)).

Part of my job is to 'industrialize' and update/clean up the existing code so there is less time spent on fixing bugs due to bad design.

One of the first things I had to do was to write a new interface to integrate with external software.

I already noticed some rather nasty habits, like prefixing every variable with m (don't know why), private fields for every property (all simple properties) and a whole lot of other stuff that either is obsolete or just bad practice.

Started writing clean code (simple classes with properties only, no m prefixing, making sure everything is single responsibility, unit tests, ...).

So I check in the code, don't hear much from it again besides the original dev/architect that started the project using my code to further work on that integration.

Now recently I started converting everything from TFVC to Git (which is the company standard but wasn't used by our team yet). And I quickly skimmed through my code to check if everything was there before pushing it to the remote repo.

To my surprise, all the code I had written was replaced by m prefixed private variables used in simple properties. BL classes were thrown in together, creating giant monstrosities that did everything. And last but not least, all unit tests were commented out.

Not sure what I got myself into ... but the facepalming has commenced.

Dear previous dev on this project,

I know that everyone loved you and still admires you for being so nice and having such a great knowledge. Please teach me your ways of achieving this level of popularity while writing big bowls of fucking flying spaghetti monster code with a bunch of hidden bugs and thousands of lines of unit tests that clearly never been used since it is literally impossible to run them thanks to missing mocks and overall bad design.

Teach me so I can become this person who shits big reeking piles in the office in front of everyone and even after leaving people still praise them for being exceptionally clean and sophisticated.

I'm finally writing unit tests consistently thanks to a simple file organization decision.

I'm not doing pure TDD, but at least I'm writing the tests immediately after writing a module, and I make sure they run ok.

What I'm doing is Instead of putting the test files in a "tests" dir at the root of the project, I have the tests right next to the source code.

So if I have a dog.x file, I also have a dog.test.x file next to it.

I'm not inventing gunpowder here. I've seen several people do this.
But it's something that is not generally made a default or advised to do.
Like I said; test frameworks in general go with the classic "tests" dir.

But for me this is day and night in whether I write the tests or not.

Which makes sense. Imagine the classic scenario of the "tests" dir, and you just created a file deep into a hierarchy, let's say src/lib/console/windows/dog.x

This means that if you want to write tests for that, you need to make sure the hierarchy tests/lib/console/windows/dog.test.x exists

If the test file already exists, but you want to access both files, you need to traverse deep for each.

Also, it's actually harder to keep track which files have unit tests and which do not.

Meanwhile, if the test files are next to the source, all these problems disappear.

That doesn't mean there are no other challenges with testing, like testing untestable things, like system calls or http requests, but there are ways to deal with that.

Trying to love writing unit tests.

Built a whole test suite around our Laravel app which has been pointed out to exec as slowing down CI and yielding no value to the user.

Arguing it’s ensuring something our users is using doesn’t accidentally break just gets brushed off as incompetence.

Oh well, I’ll just skip tests in CI and continue writing and running tests on my own as I don’t feel confident just cowboy fixing things.

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.

Finished writing a microservice in NodeJS. Wrote tests, had clever optimisations, did profiling, the works. Lead dev says to me on a Friday evening to port my code to Java in 2 days. (Reason: to standardize everything) #FML

Start writing unit tests?!
Maybe?
Perhaps..
If they'll let me..
Ok, no!
Just survive ffs!!

My current job at the release & deploy mgmt team:

Basically this is the "theoretically sound flow":

* devs shit code and build stuff => if all tests in pipeline are green, it's eligible for promotion
* devs fill in desired version number build inside an excel sheet, we take this version number and deploy said version into a higher environment
* we deploy all the thingies and we just do ONE spec run for the entire environment
* we validate, and then go home

In the real world however:

* devs build shit and the tests are failed/unstable ===> disable test in the pipeline
* devs write down a version umber but since they disabled the tests they realize it's not working because they forgot thing XYZ, and want us to deploy another version of said application after code-freeze deadline
* deployments fail because said developers don't know jack shit about flyway database migrations, they always fail, we have to point them out where they'd go wrong, we even gave them the tooling to use to check such schema's, but they never use it
* a deploy fails, we send feedback, they request a NEW version, with the same bug still in it, because working with git is waaaaay too progressive
* We enable all the tests again (we basically regenerate all the pipeline jobs) And it turns out some devs have manually modified the pipelines, causing the build/deploy process to fail. We urged Mgmt to seal off the jenkins for devs since we're dealing with this fucking nonsense the whole time, but noooooo , devs are "smart persons that are supposed to have sense of responsibility"...yeah FUCK THAT
* Even after new versions received after deadline, the application still ain't green... What happens is basically doing it all over again the next day...

This is basically what happens when you:=
* have nos tandards and rules inr egards to conventions
* have very poor solution-ed work flow processes that have "grown organically"
* have management that is way too permissive in allowing breaking stuff and pleasing other "team leader" asscracks...
* have a very bad user/rights mgmt on LDAP side (which unfortunately we cannot do anything about it, because that is in the ownership of some dinosaur fossil that strangely enough is alive and walks around in here... If you ask/propose solutions that person goes into sulking mode. He (correctly) fears his only reason for existence (LDAP) will be gone if someone dares to touch it...

This is a government agency mind you!

More and more thinking daily that i really don't want to go to office and make a ton of money.
So the only motivation right now is..the money, which i find abhorrent.

And also more stuff, but now that i am writing this down makes me really really sad. I don't want to feel sad, so i stop being sad and feel awesome instead.

So I handed in my official resignation last week as I will be changing to a new job next month. So one of the last big things that I have been working on is a Jenkins server for the rest of the team to use and currently writing up the documentation for it.

However I haven't been told who I will be handing over my work to, but the bigger thing I feel is that even if I write all the documentation, no one will actually read it. Reason I think this is because I doubt anyone else in the team will even use the Jenkins server. The major issues are that no one writes unit tests and don't even understand what CI is!

So right now it feels like my final month of work will all be for nothing and makes me wonder if I should even bother writing documentation, especially if it isn't going to be handed over to anyone.

Spent about six hours writing tests and coding a user log in system for a Rails app last night. Finally finished at around 2:00am. Commited, pushed and merged, then called it a night.

Woke up today and Postgres is refusing to play nice. Spent twenty mins or so fixing that and then ran rspec.... Two thirds of my tests are missing - everything I wrote last night. I check my code and sure enough, they aren't there.

Wild panic ensues for a solid 5 mins before I realise I didn't actually pull the updated master branch after deleting my feature branch last night.

Now I feel like an idiot, but a relieved one.

Listened for about a half-hour yesterday to DevA ‘beat down’ DevB writing a console app for trying out a proof-of-concept idea he had.

DevB: “What’s the URL of the development server?”
DevA: “Why? What are you doing?”
DevB: “I’m needing to throw some messages to it so I can capture data for something I’m working on.”
DevA: “How are you calling the service?”
DevB: “I wrote a console app”
- you could almost hear the eye roll -
DevA: “A console app? Why in the world would you write a console app?”
DevB: “Oh..um..no reason. I just need log some test data for something I’m playing around with. How should I do it?”
DevA: “If it’s test data, you should have wrote a unit test. You see, unit tests …”
- yammer on and on for about 5 minutes about the virtues of unit tests…never really explaining anything -
DevB: “Yea, I’m not needing to test the result or anything. I just need to log some data.”
DevA: “Then you should use a unit test for that, not a console app. With a unit test, you’ll be able to validate the data. That’s what unit tests are for. Microsoft should have never put in console apps in Visual Studio. It just leads to bad coding practices.”
DevB: “Um…I don’t care. It’s a console app because I just need data…thanks anyway”

Today, DevC was talking to DevA

DevC: “Charlie is testing the order module, but there isn’t any test data. Do you still have the data generating script?”
DevA: “Oh yea, I’ll send him my console app that populates the database.”

It was all I could do from screaming “You stupid –bleep-er!! What the f–bleep-ck was all that yesterday?!”, but none of my business. Better to devrant about it than start a fight.

When I was a junior engineer I used to hate writing unit tests but now I look forward to writing them.

Well written Unit tests will save your life

I think I need to start writing unit tests for my unit tests...

Not a rant but I spent 30 minutes writing a fix for 2 integration tests while screen sharing. Ran the tests and they both pass first try, no exceptions, typos or silly mistakes. 2 additional unrelated tests also started passing. It felt good.

ME: *runs a load test for the umpteenth time*

RDS DB: *is slow af: HI contentions*

ME: "dear AWS support, I see the RDS has troubles writing to disk as THIS db exhibits 10x higher W latencies than THAT OTHER db we have. Both are identical, apps are identical."

AWS: "Hello, I hope you have a good day. After the investigation that took us almost 2 weeks, we can confirm that there are 10x higher IO latencies to disks: [CloudWatch link]. We also see a high load average during your tests.

We recommend investigating the high load average and tuning your queries along with the database.

I hope this helps, good day."

ME: *are you seriously calling this PREMIUM support package....?*

This is not joke but fact

More than a year ago I write code without tests, I must confess its frustrating trying to debug without proper testing. testing is painful I must admit but you can't compare the confident you have on your code with the pains when writing tests.

About a year ago I wrote a whole software without tests and this words from a friend hunted me everyday till date he said, what cannot be tested cannot be trusted. Wise words.

Overengineering. Finding the right point between overdesign and no design at all. That's where fancy languages and unusual patterns being hit by real world problems, and you need to deal with all that utter mess you created being architecture astronaut. Isn't that funny how you realize that another fancy tool is fundamentally incompatible with the task you need to solve, and you realize it after a month of writing workarounds and hacks.

But on the other hand, duct tape slacking becomes a mess even quicker.

Not being able to promote projects. You may code the shit out of side project and still get zero response, absolutely no impact. That's why your side projects often becomes abandoned.

Oversleeping. You thought tomorrow was productive day, but you wake up oversleeped, your head aches, your mind is not clear and you be like "fuck that, I'm staying in bed watching memes all day". But there's job that has to be done, and that bothers you.

Writing tests. Oh, words can't describe how much I hate writing tests, any kind of. I tried testing so many times in high school, at university, even at production, but it seems like my mind is just doesn't accept it. I know that testing is fundamentally important, but my mind collapses every time I try to write a single fucking test, resulting in terrible headache. I don't know why it's like that, but it is, and I better repl the shit out of pure function than write fucking tests.

I had a pretty good laugh just now.
There's this extension I wrote for our client's online shop which enables them to create template files via the backend. Essentially it's just an editor reading and writing files from/to a directory.

So I installed said extension using a package I found locally, thinking it was the latest release. Unfortunately it was not.

As I said the extension writes template files within it's own directory and back when I had packed up the extension, I must had forgotten to delete these template files resulting from tests and messing around.

Long story short, I just received a ticket about a line of text suddenly showing up below the product page description saying: "I like turtles!"

The ticket itself was very professional though and the client didn't forget to mention that the "notice" was not part of their product feed data. No shit! LOL

"I don't see the point of writing tests on this project. It's just a waste of time. "

3 months later:

"I don't know what's broken and every time I change something I don't know what it could possibly break?"

FFS.

This year I want to become a better programmer. I ordered the book clean code and want to focus on writing more and better unit tests.

If anyone has any tips on how to improve or how to get tips on your code

probably every time I see my tests failing.

Each time I am writing tests I'm convincing myself "it's an investment", "spend 2 hours now to save 2 days later", "unit-tests are good".

And each time I'm chasing away ideas like "perhaps they are right, perhaps writing unit tests is a waste of time..", "this code is simple, it should ever break - why test it??", "In the 2 hours I'll spend writing those UT I could build another feature"

Yes, it is terribly annoying to write tests, especially after writing the production code (code-first approach). Why test code that you know works, right?

But after a few weeks, months or years, when the time comes to change your feature: enhance it, refactor it, build an integration with/from it, etc, I feel like a child who found a forgotten favourite candy in his pocket when I see my tests failing.

It means I did a very good job writing them
It means it was not a waste of time
it means these tests will now save me hours or days of trial-and-error change→compile→deploy→test cycles.

So yeah, whenever I see my tests fail, I feel warm and fussy inside :)

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.

There is some gratification in writing tests and finding corner case flaws in your code. Don't worry past me, present me's tests got your back.

During one of our 'pop-up' meetings last week.

Ralph: "The test code the developers are checking in is a mess. They don't know what they are doing."

ex.
var foo = SomeLibrary.GetFoo();
Assert.IsNotNull(foo);

Fred: "Ha ha..someone should talk to HR about our hiring practices. These people are literally driving the company backwards."
Me: "I think unit testing is complete waste of time."
- You could almost see the truck hit the wall and splatter watermelon everwhere..took Ralph and Fred a couple of seconds to respond
Fred: "Uh..unit testing is industry best practice. There is scientific evidence that prove testing reduces bugs and increases code quality"
Ralph: "Over 90% of our deployments are rolled back because of bugs. Unit testing will eliminate that."
Me: "Sorry, I disagree."
- Stepping on kittens wouldn't have gotten a worse look from Fred and Ralph
Fred: 'Pretty sure if you ask any professional developer, they'll tell you unit testing and code coverage reduces bugs.'
Me: "I'm not asking anyone else, I'm asking you. Find one failed deployment, just one, over the past 6 months that unit testing or code coverage would have prevented."
- good 3 seconds of awkward silence.
Ralph: "Well, those rollbacks are all mostly due to server mis-configurations. That's not a fair comparison."
Me: "I'm using your words. Unit tests reduces bugs and lack of good tests is the direct reason why we have so many failed deployments"
Boss: "Yea, Ralph...you and Fred kinda said that."
Fred: "No...we need to write good tests. Not this mess."
Me: "Like I said, show me one test you've written that would have prevented a rollback. Just one."
Ralph: "So, what? We do nothing?"
Me: "No, we have to stop worshiping this made up 80% code coverage idol. If not, developers are going to keep writing useless test code just to meet some percent. If we wrote device drivers or frameworks for other developers maybe, but we write CRUD apps. We execute a stored procedure or call a service. This 80% rule doesn't fit for code we write."
Fred: "If the developers took their head out of their ass.."
Me: "Hey!..uh..no, they are doing exactly what they are being told. Meet the 80% requirement, even if doesn't make sense."
Ralph: "Nobody told them to write *that* code."
Boss: "My gosh, what have you and Fred been complaining about for the past hour?"
- Ralph looks at his monitor and brilliantly changes the subject
Ralph: "Oh my f-king god...Trump said something stupid again ..."

At that point I put my headphones on went back to what I was doing. I'm pretty sure Fred and Ralph spent the rest of the day messaging back-n-forth, making fun of me or some random code I wrote 3 years ago (lots of typing and giggling). How can highly educated grown men (one has a masters in CS) get so petty and insecure?

What do we say to writing unit tests?

Not today.

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?

Start writing unit tests

So management wants this:
As soon as a customer reports a bug, management wants to have an "emergency button" to let their inexperienced hands make production fall back to the last stable version, without having to pass through IT and wait for them to fix it. If the server catches a 500 error, this process should be done automatically. All because they don't want to give us more time writing more thorough tests...

rant?
When you want to write the unit test that demonstrates a subtle bug, but before recreating the same preconditions you end up writing 15 other tests, testing a lot of other stuff too, that in turn show other bugs, and skyrocketing the coverage (that was sitting at 0% actually).
Like I wanted to repair a hole in my umbrella to not get wet, and built a house instead.

Not writing tests for your code is like leaving it unguided in the hands of future Devs who gonna just change something and break the core logic and there won't be any regression test to run and check the integrity.

So after 7 months of soul crushing searching I was able to land an awesome job I never thought I'd get! I didn't really get hired for my projects, I think I was more of a culture fit that knew enough of what they were talking about. My colleagues are awesome, helpful people but they are also clearly way ahead of me as devs. I know that many new hires have similar feelings and it's more a matter of drive + time. I understand that and I'm ready for the marathon ahead of me but I have one HUGE concern... I don't understand unit testing. I've never written unit tests in JavaScript or Java (just on paper I wrote random assert statements for a college exam question that somehow turned out correct). More importantly, I don't understand when to write unit tests and what my main objectives should be when writing them. At work they talk about unit testing like it's just as basic as understanding version control or design patterns, both of which I have had no problems asking questions about because I at least understood them generally. I come here looking for resources, mainly things I can go through over the weekend. I understand that I'm going to have to ask my colleagues for help at some point but I DON'T want to ask for help without any solid base knowledge on unit testing. I would feel much more comfortable if I could understand the concepts of unit testing generally, and then ask my team members for help on how to best apply that knowledge. I'm sorry for begging, I'll definitely be looking for resources on my own too. But if anyone could point me to resources they found to be helpful & comprehensive, or resources that they'd want their co-workers to use if they were in my position I would be very grateful!!!!

After writing ~200 lines of code and then unit testing it

THE TESTS ALL PASS!!!

then I run them again just to be sure and they all pass but mocha is saying I am getting 40ms lag on some of my tests...

Noooo!!!

This is meant to be an async message passing system; I cannot have an input lag of 40ms :(

That joy of finally having them all passed.
I had stupid mistakes like: insertNewItem, but inside I use update T_T

project still fairly new, but this time I decided to write unit tests as I go instead of delaying till the end and writing nothing lol

Developer just emailed our team a complaint that our logging assembly was resulting in their poor test coverage and they sent a change request to give them the ability to mock the underlying log provider (ex. from the event log to ‘something else’).

Looked at their tests, and they are testing whether or not the .Log was executed (on an exception, if the .Log method was not executed, the test failed), which seemed a bit worthless because we’ve already got coverage in our unit tests.
We had a meeting to discuss the issue.
Me: “I’m OK with changing the logging code if it’s necessary, but I want to understand why.”
DevA: “Logging errors is crucial to the database transaction. If someone removes the logging, the tests should fail.”
Me: “If someone removes the error logging on purpose, then they likely have an agenda and will remove the test validation too. It wouldn’t be an accident.”
DevA: “That’s not my problem. They will have to deal with HR.”
Me: “We purposely prevented someone from intercepting the logging just for that purpose. Your test code already covers the business rule, testing the logging seems out of place. That would like writing a test to make sure the System.IO.File.ReadAllText actually reads all the text from a file. You kinda assume a few smart Microsoft engineers already wrote tests for that.”
DevA: “Yea, I guess that would be silly.”

Got cc’ed an email a little bit ago from DevA to his boss..
“We’re not going to be able to change logging assembly. This may have some impact on our overall test coverage as those lines of code will not get testing coverage. You will have to let the DevMgr know we will not meet our test coverage goals.”

WTF!

I've been writing tests all week.
I quite like writing tests in some respects, but I absolutely detest it if the thing I'm testing is a moving target! Stop changing your mind! Either we support the feature in it's entirety or we don't support it at all!

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)

Can we please stop making everything in javascript? Pretty please?

Like, I get it, js makes it easier to find developers and speeds up development, but writing a compiler to run on node? That doesn't make any sense to me. Typescript is taking ~11s to compile a medium-sized project, out of which ~9s are just type-checking (if I disable type-checking it takes ~2s to compile). Even Rust, which is considered to have a slow compiler (because of the borrow checker I assume) takes less time to compile a project of roughly the same size.

This is getting very irritating. If I want to keep type-checking, every single time I make a change on a single file I have to wait 11s before any tests start running. This was heavily affecting my productivity (and sanity), so I decided to disable type-checking and threw out the window 90% of Typescript's advantages.

Why the hell wasn't typescript written in an actually performant language? Just so you could say that typescript is written in itself? I don't get it, I really don't.

Do you guys enjoy writing unit/ integration tests?

Month passed so I looked at job offers and I am tired again.

All of them look the same and all of them look like crap. Some require stupid online tests preparation ( cause everyone likes to traverse tree 10000 times a day ).

Seriously I think I will go to supermarket and work there.
It’s more pleasant then getting input and pushing it in some stupid places all over again.
Finding some shit in shit pile, then moving this shit pile back and forth between different shit holes.

AI should start writing this stupid code, robots should provide food and build shelter.
The sooner the better for all of us.

I can now leave freely without any regrets!
The slight misgivings I had about leaving this place over the toys they provide, is now gone because I re-realized that while this place adopts new tech, it doesn't adapt to it. So they have shiny tools but the people and processes won't change.
It seems to me that due to pressure to deliver, there is little thought/analysis behind any tech change.

They don't plan to change their wretched delivery pipelines. Everything will be same but on git. So no velocity gains, and same bureaucratic review request process. Such a waste. This attitude applies to their other tools too. They are using a unit test library to write tests that don't use mock. They are using modern languages but without modern idioms. It's like writing C code in C++. And of course theoretically we are agile but actually we're just a waterfall team with managers on our ass everyday and tighter release schedules.

Reminds me of @boombodies recent posts and discussion about business spaghetti reflecting in code.

There are possibly multiple reasons for these problems but I think a large part of it is a lack of empathy/mutual respect. Everyone's too insecure, noone cares for anyone but themselves and people just try to outwit each other.

Tabs, or No Tabs? I did the same as this commentor 2 years ago. I can code so quick now because of this simple switch. Here's why:

(source, Laracasts.com)

Ben Smith
"I think the most beneficial tip was to do away with tabs. Although it took a while to get used to and on many occasions in the first few days I almost switched them back on, it has done wonders for my workflow.

I find it keeps my brain more engaged with the task at hand due to keeping the editor (and my mind) clutter free. Before when I had to refer to a class, I would have opened it in a new tab and then I might have left it open to make it easier to get to again. This would quickly result in a bar full of tabs and navigation around the editor would become slow and my brain would get bogged down keeping track of what was open and which tab it was in. With the removal of the tab bar I'm now able to keep only the key information in my mind and with the ability to quickly switch between recently opened files, I find I haven't lost any of the speed which I initially thought I might.

In fact this is something I have noticed in all areas of writing code, the more proficient I have become with an editor the better the code I have been writing. Any time spent actually writing your code is time in which your brain is disconnected from the problem you are trying to solve. The quicker you are able to implement your ideas in code, the smaller the disconnect becomes. For example, I have recently been learning how to do unit testing and to do so I have been rewriting an old project with tests included. The ability to so quickly refactor has meant that whereas before I might have taken 30 seconds shuffling code around, now I can spend maybe 5 seconds allowing my mind to focus much better on how best to refactor, not on the actual process of doing so."

jeff_way Mod
"Yeah - it takes a little while to get used to the idea of having no tabs. But, I wouldn't go back at this point. It's all about forcing yourself into a faster workflow. If you keep the tabs and the sidebar open, you won't use the keyboard."

Writing a small scale Ecommerce site for a friend. He keeps asking why I am writing tests for it all the time...some of us have standards

When you know you should be writing your tests first, then your code. But you secretly do it the other way round anyway.

If I'm writing an app which has the sole purpose of receiving some data from a server, then sending some other data back (so nothing is stored locally) - what sort of stuff do I write tests for?

Client wants lots of testing to occur, but all of the tests I can think of wouldn't add any value

Just had a class where we had to write a heap adding algorithm in Java to reduce rounding error for x amount of floats being added together

After an hour of writing code with no testing anything I finished. Ran the JUnit tests provided by the teacher and it passed all the tests!

Who says it can't work the first time?

I've been writing unit tests for an existing project for a couple of months now. I'm not experienced at automated tests, so I'm not sure what's good unit tests supposed to be, but the unit tests that I wrote basically just confirm the flow that already implemented, which to my limited understanding of unit tests is supposed to be the other way around. The good thing is that I could catch some minor problems with the implementation such as not imported class used, the wrong variable used since the project is a rewrite of legacy code so a lot of copy-pasta, I also have to wrap some part of the code that interacts with the filesystem in a DI class so I could test that part.

If you're subscribed to me only because of my jokes, feel free to ignore this rant. You won't miss anything.

If not, bear with me.

I was wrong about almost everything I can remember. Preaching so-called “conceptual thinking”, I invented a fantasy world of random anecdotes, which turned into a completely false worldview that shaped my reality. I bashed magical thinking, yet succumbed to it. What I believed to be true was just as magical, wrapped into what sounded like science. In the Dunning-Krueger scheme, I was right there on Peak Stupid.

Random hear-say, stupid concepts I invented, random “knowledge” I picked from YouTube videos, all that was rotting inside my head, one anecdote contradicting another. Ultimately, I think this was the reason of my constant anxiety and pointless, never-ending thought process in background.

If you learned anything factual from me and didn't fact-check it, please forget that immediately. The list includes but is not limited to everything on brain structure, everything on philosophy, almost everything on engineering and architecture, almost everything on systems theory and programming meta stuff (declarative, imperative, etc.)

I admit bashing unit tests. The only reason was me disliking writing them in uni. I wrote like three test cases, disliked it, and the rest was history. Everything else was a rationalization on top. If I was right about something, I was just lucky.

I'm not a CSS prodigy. I know stuff that earns me money and impresses my colleagues, but my knowledge is just one step above basics, in one thousand steps ladder.

Sometimes, I run tests just because I want a break from writing code. In good cases it's so that I take a moment to think about what I'm going to do next. In most cases however, I'm struggling for motivation

Spent my entire day writing jest tests...yeah I'm ready for bed

Always always always always always keep writing tests as you implement features. TDD is good thing but not necessary but tests are really necessary. I thought I'll write tests later now the code is so tightly coupled I can test things independently. 😑😑

I'm in a team of 3 in a small to medium sized company (over 50 engineers). We all work as full stack engineers.. but I think the definition of full stack here is getting super bloated. Let me give u an example. My team hold a few production apps, and we just launched a new one. The whole team (the 3 of us) are fully responsible on it from planning, design, database model, api, frontend (a react page spa), an extra client. Ok, so all this seems normal to a full stack dev.

Now, we also handle provisioning infra in aws using terraform, doing deployments, building a CI/CD pipeline using jenkins, monitoring, writing tests, building an analytics dashboard.

Recently our tech writer also left, so now we are also handling writing feature releases.

Few days ago, we also had a meeting where they sort of discussed that the maintenance of the engineering shared services, e.g. jenkins servers, (and about 2-3 other services) will now be split between teams in a shared board, previously this was handled only be team leads, but now they want to delegate it down.

And ofcourse not to mention supporting the app itself and updating bug tickets with findings.

I feel like my daily responsiblities are becoming the job responsibilities of at least 3 jobs.

Is this what full stack engineering looks like in your company? Do u handle everything from app design, building, cloud, ops, analytics etc..

Finally made my node production server stable enough that I could focus on writing tests*. I start by setting up docker, mocking cognito, preparing the database and everything. Reading up on Node test suites and following a short tut to set up my first unit test. Didn't go smoothly, but it's local and there are no deadlines so who cares. 4 days later, first assert.equal(1+1, 2) passes and I'm happy.

I start writing all sorts of tests, installing everything required into "devDependancies," and getting the joy of having some tests pass on first try with all asserts set up, feels good!

I decide to make a small update to production, so I add a test, run and see it fail, implement the feature, re-run and, it passes!

I push the feature to develop, test it, and it works as intended. Merge that to master and subsequently to one of my ec2 production servers**, and lo and behold, production server is on a bootloop claiming it "Cannot find module `graphql`". But how? I didn't change any production dependencies, and my package lock json is committed so wth?

I google the issue, but can't find anything relevant. The only thing that I could guess was that some dependencies (including graphql) were referenced*** in both, prod and dev, and were omitted when installed on a prod NODE_ENV, but googling that specific issue yielded no results, and I would have thought npm would be clever enough to see that and would always install those dependencies (spoiler: it didn't for me).

With reduced production capacity (having one server down) I decided to npm uninstall all dev dependencies anyway and see what happens. Aaaaand it works.....

So now I have a working production server, but broken local tests, and I'm not sure why npm is behaving like this...

* Yes I see the irony.
** No staging because $$$, also this is a personal project.
*** I am not directly referencing the same thing twice, it's probably a subdependency somewhere.

When you're writing unit tests TDD style and you realise how close your deadline is:

TFW the mock class has way more code than the real one.
Testing big infrastructures can be a pain...
Or maybe my team is just not so good at it.

My time spent:
Adding new feature to the real class 15%
Extending the mock with the same feature 55%
Writing tests 30%

When the CTO/CEO of your "startup" is always AFK and it takes weeks to get anything approved by them (or even secure a meeting with them) and they have almost-exclusive access to production and the admin account for all third party services.

Want to create a new messaging channel? Too bad! What about a new repository for that cool idea you had, or that new microservice you're expected to build. Expect to be blocked for at least a week.

When they also hold themselves solely responsible for security and operations, they've built their own proprietary framework that handles all the authentication, database models and microservice communications.

Speaking of which, there's more than six microservices per developer!

Oh there's a bug or limitation in the framework? Too bad. It's a black box that nobody else in the company can touch. Good luck with the two week lead time on getting anything changed there. Oh and there's no dedicated issue tracker. Have you heard of email?

When the systems and processes in place were designed for "consistency" and "scalability" in mind you can be certain that everything is consistently broken at scale. Each microservice offers:

1. Anemic & non-idempotent CRUD APIs (Can't believe it's not a Database Table™) because the consumer should do all the work.
2. Race Conditions, because transactions are "not portable" (but not to worry, all the code is written as if it were running single threaded on a single machine).
3. Fault Intolerance, just a single failure in a chain of layered microservice calls will leave the requested operation in a partially applied and corrupted state. Ger ready for manual intervention.
4. Completely Redundant Documentation, our web documentation is automatically generated and is always of the form //[FieldName] of the [ObjectName].
5. Happy Path Support, only the intended use cases and fields work, we added a bunch of others because YouAreGoingToNeedIt™ but it won't work when you do need it. The only record of this happy path is the code itself.

Consider this, you're been building a new microservice, you've carefully followed all the unwritten highly specific technical implementation standards enforced by the CTO/CEO (that your aware of). You've decided to write some unit tests, well um.. didn't you know? There's nothing scalable and consistent about running the system locally! That's not built-in to the framework. So just use curl to test your service whilst it is deployed or connected to the development environment. Then you can open a PR and once it has been approved it will be included in the next full deployment (at least a week later).

Most new 'services' feel like the are about one to five days of writing straightforward code followed by weeks to months of integration hell, testing and blocked dependencies.

When confronted/advised about these issues the response from the CTO/CEO
varies:

(A) "yes but it's an edge case, the cloud is highly available and reliable, our software doesn't crash frequently".
(B) "yes, that's why I'm thinking about adding [idempotency] to the framework to address that when I'm not so busy" two weeks go by...
(C) "yes, but we are still doing better than all of our competitors".
(D) "oh, but you can just [highly specific sequence of undocumented steps, that probably won't work when you try it].
(E) "yes, let's setup a meeting to go through this in more detail" *doesn't show up to the meeting*.
(F) "oh, but our customers are really happy with our level of [Documentation]".

Sometimes it can feel like a bit of a cult, as all of the project managers (and some of the developers) see the CTO/CEO as a sort of 'programming god' because they are never blocked on anything they work on, they're able to bypass all the limitations and obstacles they've placed in front of the 'ordinary' developers.

There's been several instances where the CTO/CEO will suddenly make widespread changes to the codebase (to enforce some 'standard') without having to go through the same review process as everybody else, these changes will usually break something like the automatic build process or something in the dev environment and its up to the developers to pick up the pieces. I think developers find it intimidating to identify issues in the CTO/CEO's code because it's implicitly defined due to their status as the "gold standard".

It's certainly frustrating but I hope this story serves as a bit of a foil to those who wish they had a more technical CTO/CEO in their organisation. Does anybody else have a similar experience or is this situation an absolute one of a kind?

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!!!

I'm a strong believer in the triple-A unit-test pattern: Arrange, Act and Assert

Anyone else that uses this for their tests? Do you see any cons to using this approach to writing tests? Are you using an alternative?

The previous developer didn't write a freaking single test for a system that does a lot of calculations. Performance was shit so I got tasked with re-writing everything from DB queries to the actual calculation functions.

This has been the worst developer hell I've ever been. Without tests I cannot change anything without knowing if something breaks!!!

I gotta understand first the mess this guy left behind, then freaking write the tests that are missing and finally refactor the stuff. FML.

Btw, its Python and the guy didint even bother to do some basic type annotations so it's even worse. Function arguments are "data", "score", some are dicts, some are floats, some are lists.

Faaaaaaaaaaaaaack!!!!

Writing unit tests on a weekend and catching up on work that needs to be done because I m too busy on weekdays to have time to think about this...

The sad thing is test coverage is shit in the entire code base as boss just decided to start enforcing requirements now... And I have this huge migrating from legacy system project that needs to be merged. And we'll the legacy system is even shittier

So I have to write unit tests for shit code that was never written with testing in mind...

On the other hand I reworked some testing utilities to make it easier... For everyone... I want a huge bonus.... That I probably won't get...

so what's on the list for today? writing unit tests for a broken php app because NO ONE THOUGHT TO WRITE THEM BEFORE HAND.......

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.

PM: Can you help out writing a test suite for feature X? Really high priority!
Me: Ok, give me a day or so.

I get it done, and setup in CI-tool to test on the feature branch.

*Next day*

PM: It doesn't work! Can you have a look?
Me: Uhm yeah.
Only broken on feature branch of course.

Dev working on feature X: Ok pushed a potential fix, can you run test suite again?
PM: Yes, can you get on that asap?

CAN YOU RUN YOUR OWN FUCKING TESTS?

(╯°□°)╯︵ ┻━┻

Today I read a great article on mutation tests, how to use and why they are important. It looks like a great thing, but...
I have never wrote any unit test in any of my jobs. Nobody in my workplace does that. And now it seems like 100% test coverage is not enough (I remind you, that I have 0%), they all should mutate to check if the quality of unit tests is high.
It seems that I'm left behind. I played with tests in my free time, but it seems the more you write them, the better you get at it, so I should be writing them in my job, where I code most of my time. Not only that, of course, I would also want to ensure that what I'm working on is bug-free.
Still, it will be impossible to introduce unit tests to my project, because they are novelty to the whole team and our deadlines are tight. The other thing is, we are supposed to write minimum viable product, as it is a demo for a client, and every line of code matters. Some might say that we are delusional that after we finish demo we will make things the right way.
Did any one of you have a situation like this? How did you change your boss and team's mind?

Why is the C++ build and package management system so complicated? I feel like whenever I work on a C++ project, I spend more than half my time just figuring out how to set up the environment, build the binaries, run the tests, when I’d rather and should be writing code.

Me at the beginning of the project: I should start by writing tests
Me after a couple of days: No time to write tests! GOTTA WRITE THAT CODE
Me now: Oh, yes, I should have written those tests at the beginning

I feel like writing or telling people about the time I jumped from Windows 7 Ultimate and jumping to Windows 10. (I'm not against 10, but I'm never updating after what had happened to me)
It all starts when none of my games will play due to a possible issue with my graphics card. I look up "3D source game bug" and not many results pop up. I go on Microsoft's Qna areas and ask this question but to my surprise nothing they say would make sense. "Clean the pins of your graphics card, make sure you verify the games on Steam". I verified the games and they checked out as perfectly fine. I don't have access to my graphics card because this is a laptop, sadly not a tower.
Two months pass and my computer is already showing signs of stress, like it didn't want to live in a sense. It was three times slower than when I was on Windows 7 and it was unallocating areas of my main hard drive where I could make virtual hard drives.
Instantly I start looking up Linux distros and find Linux Mint. 17.3 was the current version at the time. I downloaded it and burned it onto a DVD-rom and rebooted my computer. I loaded into the disc and to my surprise it seemed almost like Windows 7 apart from the Linux part. I grab my external hard drive and partition it to hold the Linux distro and leave it plugged in incase Windows 10 does actually fail.
On December 19, a few months after Windows 10 had released. I start my laptop to try and continue my studies in video game development. But to my surprise, Windows 10 had finally crashed permanently. The screen flickered blue and black, and an error box saying Loginui.exe failed to start. I look at it for a solid minute as my computer had just committed suicide in a sense.
I reboot thinking it would fix the error but it didn't. I couldn't log in anymore.
I force shutdown the laptop and turn it back on putting it into safe mode.
To my surprise loginui.exe works and I sign in. I look at my desktop, the space wallpaper I always admired, the sound files, screen shots I had saved.
I go into file explorer and grab everything out of my default hard drive Windows was installed on. Nothing but 400gb got left behind and that was mainly garbage prototypes I had made and Windows itself. I formatted my external hard drive and placed everything on it. Escaping Windows 10 with around 100GB of useful data I looked at the final shutdown button I would look at.
I click it and try to boot into normal Windows 10. But it doesn't work. It flickers and the error pops up once more.
I force it to shutdown and insert the previous Linux Mint disc I made and format the default hard drive through Linux. I was done. 10 gave me a lot of shit. Java wouldn't work, my games has a functional UI but no screen popped up except a black abyss and it wouldn't even let me try to update my graphics card, apparently my AMD Radeon 5450 was up to date at the AMD Radeon 5000's.
I installed Linux Mint and thinking the games would actually play I open steam and Launch Half-Life 2 to check if Linux would be nicer to me than Windows 10 had been.
To my surprise the game ran. The scene from Highway 17 popped on screen and the UI was fully functional. But it was playing at 10-15fps rather than the usual 60-70fps. Keep look at my drivers and see my graphics card isn't in use. I do some research and it turns out I have a Hybrid Laptop.
Intel HD Graphics and an AMD Radeon 5450 and it was using the Intel and not the AMD. Months of testing and attempts of getting the games to work at high frame rates pass and the Damn thing still functions at a low terrible fps. Finally I give up. I ask my mom for a Windows 7 disc and she says we can't afford it. A few months pass and I finally get a Windows 7 installation disc through money I've saved up. Proudly I put it into my optical disc drive and install it to my main hard drive deleting Linux completely. I announced to all my friends my computer was back in working order and I install everything I needed, Steam, Skype, Blender, and Unity as well as all my games. I test Half-Life 2 and it's running exceptionally smoothly, I test Minecraft at max settings and it's working beautifully. The computer was functioning properly once again and my life as a developer started as I modeled things and blender, learned beginners C# and learned a lot of Batch. Today the computer still runs at a great speed and I warn others of what happened to me after I installed Windows 10 to my machine if they are thinking of switching from 7 or 8 on an older machine.
Truly the damage to my data cannot be undone. But the memory of the maintenance, work, tests, all are a memory of how Windows 10 ruined me and every night before the one year anniversary of Windows 10's release, I took out the battery of my laptop and unplugged it from the a.c. power, just so Windows 10 doesn't show it's DLLs, batch scripts, vbs scripts, anything on my computer. But now, after this has happened and I have recovered, I now only have a story to tell

When there's "no budget" to spend time on writing unit tests...

JUnit 5 and Mockito are so cool! Writing tests is so much fun! Having tests is a blessing! 👉 WRITE TESTS 👈

It was the worst local Hackathon. It's not even a Hackathon either, where the whole event spanned over 2 months.

It was a group entry with me and 4 teammates. Each of them did contribute:

Guy A: criticizes what is built and designed
Guy B: offered financial tips on how to make this thing feasible
Guy C: did UI but in graphics. No CSS file, just bits of graphical elements.
Guy D: family commitments

And then there's me, writing documentation, built the entire project, wiki, drove the project, prepared the presentation slides, tests the framework, unit tests, stuck with stupid problems like SSL, localhost, Google Maps Key and the likes.

And we didn't even win, let alone launch this thing, whatever it is, to anywhere. Never doing group projects again.

I'm flying solo for now

I've never written any unit tests for any apps/programs I've developed.

I would tell myself, this time you're going to create some and be a better developer by doing so. I end up just creating the file and that's it.

Most of the bugs are discovered during the user testing phase so I always end up being lazy writing unit tests.

I write very defensive code though so that helps a little but all in all, it's a very bad habit that I need to snap out of