Summing up many ridiculous meetings I've been in.

Many years ago we hired someone for HR that came from a large fortune 500 company, really big deal at the time.

Over the next 6 months, she scheduled weekly to bi-weekly, 1 to 2 hour meetings with *everyone* throughout the day. Meeting topics included 'How to better yourself', 'Trust the winner inside you'...you get the idea.

One 2-hour meeting involved taking a personality test. Her big plan was to force everyone to take the test, and weed out anyone who didn't fit the 'company culture'. Whatever that meant.

Knowing the game being played, several of us answered in the most introverted, border-line sociopath, 'leave me the frack alone!' way we could.

When she got the test results back, she called an 'emergency' meeting with all the devs and the VP of IS, deeply concerned about our fit in the company.

HR: "These tests results were very disturbing, but don't worry, none of you are being fired today. Together, we can work as team to bring you up to our standards. Any questions before we begin?"
Me: "Not a question, just a comment about the ABC personality test you used."
<she was a bit shocked I knew the name of the test because it was anonymized on the site and written portion>
Me: "That test was discredited 5 years ago and a few company's sued because the test could be used to discriminate against a certain demographic. It is still used in psychology, but along with other personality tests. The test is not a one-size-fits-all."

VP, in the front row, looked back at me, then at her.
HR: "Well....um...uh...um...We're not using the test that way. No one is getting fired."
DevA: "Then why are we here?"
DevB:"What was the point of the test? I don't understand?"
HR: "No, no...you don't understand...that wasn't the point at all, I'm sorry, this is getting blown out of proportion."
VP: "What is getting blown out of proportion? Now I'm confused. I think we all need some cooling off. Guys, head back to the office and let me figure out the next course of action."

She was fired about two weeks later. Any/all documentation relating to the tests were deleted from the server.

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

I was expecting a 4th interview this afternoon for a position as a fullstack elixir developer.

Got a response from the CTO.
'Even if you pass all the tests with success, we could not go further because you're a junior and we're looking for a senior'

Well, dude, you've seen me 3 times and didn't understand that I was a junior ? My CV is not enough explicit ? It's written at the top of it...

So after a motivation interview, technical test, technical interview and Phoenix framework interview, they only realized yet the plot.

Good luck for your seniors to pass their knowledge to other seniors.

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.

Casual workday be like:

Project manager: It is important we deliver these features.

Me & Coworker: Sounds reasonable, here is how long we need, roughly.

Mgr: Well, the deadline is already set and the contract is signed and written.

M&C: Ummm...

Mgr: Also, while we are hosting the application, we are not paid for operational cost, so make sure to optimise the crap out of it immediatly. Preferably while developing the features.

(A wild architect appears): Also everything has to be built on cans and kubernuts, with rectangular ui and bootstyling and with these internally developed backend frameworks NOBODY tests. Coroporate policy you know.

(A wilder division CEO appears on meeting): Also we are rolling out code KPI's across the organisation. Everyone is expected to Focus on documentation, test coverage and there is now mandatory SonarQube scanning of repos. ZERO DEFECTS PEOPLE

M&C: ...

(Wildest Salesteam appears): By the way we sold the application to these other customers, they love feature XYZ and must have it.

M&C: It does not have feature XYZ

Mgr: It will have feature XYZ

M&C: Allright so with all the extra funding from the sales, we need to hire atleast one Machine learning guy, an extra frontend specialist a developer and maybe funnel some of the funding into slacking the operational budget in the start.

Animated Suit *Railing a line of coke from his gold plated ihpone 15*: What funding? Get to work. Also your havent been super sharp with your time registration.

"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.)

A couple of weeks ago, I got to the second stage of a recruitment process with a relatively big fintech in the crypto space (I know) - all went well and although I did not think much of it at first, with all the information I had gathered I came to realize this might as well be the best opportunity I've had in my pursuit of finding a new job (i.e looking for high technical challenges, unsure of where I see myself in 5 years, wanting to give full-remote work a try, etc.).

Cue to the end of the interview;
"That's great! I really enjoyed speaking with you, your technical background seems excellent so we would like to move to the next stage which is a take-home test to do in your free time.", said the interviewer.

"Wow! Much amaze, well of course! What's it gonna be?", said the naive interviewee.
"I'm sending you the details via email, please send it back in 48 hours, buhbye now", she hangs up.

...

"48 hours?? Right, this should be easy then, probably some online leetcoding platform, as usual.", thought the naive interviewee, who evidently went through this sh*t numerous times already.

A day later I receive the email: this was the whole deal. The take-home test supreme with bacon and cheese. A full-blown project, with tests, a project structure, a docker image, testing and bullet points for bonus points! The assessment was poorly written with lots of typos and overall ambiguity, a few datasets were also provided but bloated with inconsistent comments and trailing whitespace.

What the actual fck??? Am I supposed to sleep deprive myself to death while also working my day job? What are you trying to assess? How much of my life I'm willing to sacrifice for your stupid useless coding challenge? You are not all Google, have some respect, jeez.

I did not get the job.

Red flags in your first week of your software engineering job 🚩

You do the first few days not speaking to anyone.
You can't get into the building and no one turns up until mid day.
The receptionist thinks you're too well dressed to work in this building, thinks you're a spy and calls security on you.
You are eating alone during lunch time in the cafeteria
You have bring your own material for making coffee for yourself

When you try to read the onboarding docs and there aren't any.
You have to write the onboarding docs.

You don't have team mates.
When you ask another team how things are going and they just laugh and cry.😂😭

There's no computer for you, and not even an "it's delayed" excuse. They weren't expecting you.
Your are given a TI PC, because "that's all we have", even though there's no software for it, and it's not quite IBM compatible.
You don't have local admin rights on your computer.💀
You have to buy a laptop yourself to be able to do your job.

It's the end of the week and you still don't have your environment set up and running.
You look at the codebase and there are no automated tests.
You have to request access every time you need to install something through a company tool that looks like it was made in 2001.

Various tasks can only be performed by one single person and they are either out sick or on vacation.
You have to keep track of your time in 6 minute increments, assigned to projects you don't know, by project numbers everyone has memorised (and therefore aren't written down).
You have to fill in timesheets and it takes you 30 minutes each day to fill them in because the system is so clunky.🤮

Your first email is a phishing test from the IT department in another country and timezone, but it has useful information in it, like how to login to the VPN.
Your second email is not a phishing test, but has similar information as the first one. (You ignore it.)
Your name is spelled wrong in every system, in a different way. 2 departments decide that it's too much trouble, and they never fix the spelling as long as you work there. One of them fixes it after you leave, and annoys you for a month because you haven't filled out the customer survey.

New country, new company, new team, new projects.
I'm supposed to be the TL of a team working on a React project.

A guy in his late 40s celebrates himself as "the senior", he basically just finished watching a youtube thing, React 101 crash course or similar. The other two juniors who did only Wordpress so far venerate him like a god.

The code, of course, is one on the finest pieces of crap I ever had the pleasure to deal with in my life: naturally a bunch of JQuery plugins for everything, no tests, no state management, side effects everywhere, shared state and globals like hell, everything written in ES3/ES5 style, no types, no docs, build and deploy totally manual, deep props drilling at every level... and not to mention the console.log() shipped in prod.

First day, already headache.
Full rewrite start tomorrow.
Hiring real devs as well.

Flash has made Java programs look desirable. And anyone keeping up with me knows I despise Java and C#, despite having written C# and currently working on deciphering a Java server to create documentation.

Before I begin, I want to make this clear: IT IS TWO THOUSAND AND FUCKING EIGHTEEN. 2018. WE HAVE BETTER TECH. JAVASCRIPT HAS TAKEN OVER THIS BITCH. So, firstly, FUCK FLASH. Seriously, that shit's a security liability. If you work for a company that uses it, find a new job and then fucking quit, or go mutany and get several devs to begin a JS-based implementation that has the same functionality. There is no excuse. "I'm fired?" That's not an excuse - if there is a way to stop the madness, then fucking hit the brakes on that shit or begin job hunting. Oh, and all you PMs who are reading this and have mandated or helped someone else to mandate work on an enterprise flash program, FUCK YOU. You are part of the problem.

The reason for this outburst seems unreasonable until you realize the hell I went through today. At my University, there is a basic entry-level psychology course I'm taking. Pearson, a company I already fucking hate for some of the ethically sketchy shit they pulled with PARCC as well as overreach in publishing to the point they produce state tests here in the US - has a product called "My PsychLab" and from here on out, I'm referring to it as MPL. MPL has an issue - it is entirely fucking Flash. Homework assignments, the textbook, FUCKING EVERYTHING. So, because of that, you need to waste time finding a browser that works. Now let me remind all of you that just because something SHOULD WORK does NOT mean that it actually does.

I'm sitting on my Antergos box a few days ago: Chromium and Firefox won't load Flash. I don't know why, and don't care to find out. NPAPI and whatnot are deprecated but should still run in a limited mode or some shit. No go on Antergos.

So, today I went to the lab in the desolated basement of an old building which is where it's usually empty except a student hired by the university to make sure nobody fucks things up. I decided - because y'all know I fuckin' hate this - to try Windows. No go in Chrome still - it loaded Flash but couldn't download the content. So I tried Firefox - which worked. My hopes were up, but not too long - because there was no way to input. The window had buttons and shit - but they were COMPLETELY UNRESPONSIVE.

So the homework is also Flash-based. It's all due by 1/31/18 - FOUR CHAPTERS AND THE ACCOMPANYING HOMEWORK - which I believe is Tuesday, and the University bookstore is closed both Saturday and Sunday. No way to get a physical copy of the book. And I have other classes - this isn't the only one.

Also, the copyright on the program was 2017 - so whoever modded or maintained that Flash code - FUCK YOU AND THE IRRESPONSIBLE SHIT YOUR TEAM PULLED. FUCK THE SUPERIORS MAKING DECISIONS AS WELL. Yeah, you guys have deadlines? So do the end users, and when you have to jump through hoops only to realize you're fucked? That's a failure of management and a failure of a product.

How many people are gonna hate me for this? Haters gonna hate, and I'm past the point of caring.

Worst hypothetical Dev job... hmm 🤔 well I think I have the right scenario for you. A medical company stores patient charts and critical life saving information in a database. This database makes medical decisions for lifesaving incubators and if there’s a bug it means 10,000 newborn sick babies will die because of your fuck up (oh and you’re criminally liable too so good luck!). But beyond the high pressure job that sounds at least somewhat normal, the database is written in a special form of assembly for a custom undocumented CPU where only one copy in the world exists so all tests and development are on production. Google and StackOverflow is banned so your only resource is your brain. Good luck🍀

Finding the right balance between well written, need-one-week, maintainable software, and fast-written, ready-in-2-hours-and-never-look-at-it-again software.

Last time it took me 20 minutes to integrate with a new API. I had a script that did everything you needed. I then spent 2 weeks on handling error responses, unexpected responses, exceptions, intelligent retries, logging, unit tests, integration tests, caching, documentation, etc.

Unpopular opinion: unit tests are often overrated.

Although a well written test suite is almost essential in some parts of the application (I.E. business logic) I cringe when I see hundreds or thousands of line which “mocks” everything to test a micro service which just does CRUD operations on a database, in cases like that unit tests are just a waste of time because almost every operation involves a mock which may not behave like the real database and often needs to be rewritten when the code undergoes a huge refactoring. In these case a integration test suite is faster to write and way more helpful.

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

You may know I love to hate tests. Well not the tests actually, what I hate is the TDD culture.

DBMS schema in my app dictates a key can either have a value, or be omitted - it can't be null, and all queries are written with that in mind (also they're checked compile-time against schema). But tester failed to mock schema validation, inserted a bunch of null keys with mock data, actually wrote assertions to check those keys are null (even though they never should be), and wanted me to add "or null" to my "exists" queries.

No, we don't need more tests, and you're not smart with your "edge cases" argument. DBMS and compiler ensure those null values can never exists in our DB, and they're already well tested by their developers. We need you to stop relying on TDD so much you forget about the practical purpose of the code, and to occasionally break from the whole theoretical independent tests to make sure your testing actually aligns with third-party services some code uses.

And no, we don't need more tests to test your mocks, and tests to test those test, and yo dawg, I heard ...

Cocktail for disaster:

- TDD
- Mocking
- Multithreading
- Averagely well written, testable code
- All tests pass
- One test methods still shows some vague stacktrace in a worker thread ❌ but the test passes ✅
- Run only that test method and no stacktrace.

So I've been pulling my hair for the last two days trying to figure out what was throwing in that test method. Turns out that thanks to the multithreading going on, some other, similar method threw the exception in parallel. And apparently a different test method was already running when the exception was finally caught.

🖕

When I discovered that, it was fixed in a minute. 😭

What you're about to read is an horror story based on real facts.
Our story begins one week ago, when a dev who calls himself "Arfmann" (what a loser, the f* means arfmann?) decided to take his dev skills to another level.

He always has been scared of databases. He made really bad dream about them. Like, they were screaming at him "SELECT useUs FROM database" while he was crying in some shared preferences noises.

A week ago, he decided to overcome his fear. He learned the basics of SQL. Everything was going well. Until, he decided to implement it on Flutter. A Google's technology.

At first, he decided to appeal to documentation. Went on Flutter web site. Flutter documentation. Sqflite documentation. Started reading. Started doing tests with the code written by Google's engineer.

Everything was fucked up. Dozens of errors, the documentation started to blow up and his PC went on fire, due to Android Studio.

He used a sample project made by Google's engineer. "Maybe if use directly their code it will work. Maybe I was the problem". He wasn't.

The whole documentation was wrong, every single line of code was a spaghetti code (yes, every single line was an entire spaghetti code). Everything was put in the main. If you wanted to try to keep things organized, you would end up punched and beaten up from the code itself. It would become a sentient entity that will beat you the fuck up.

Really scary.

I am usually lurking in here since I never really worked as a Software Developer, but until I start going to the University, I thought I might also find myself a job in Software Development.

Well... I don't know where to start.

Someone in here heard of JBoss? Me neither... we're using it... It is a Framework to deploy fortified Java Web Applications. My first day was very chaotic and was dedicated to get this fucking shit to work. I got JBoss 7.5 from my colleagues and started deploying the hello world program...

So. Many. Things. Gone. Wrong...

After like 5 hours of troubleshooting, I had to install/setup a new wrapper with my own batch scripts, install SPECIFICALLY jdk 1.7_17 (anything else won't work) and downgrade JBoss to 7.2.

Yeah that's the first thing. Let's continue about JBoss. Version 7.2 uh? What's the newest one though? Oh it's now known as WildFly... huh... FUCKING HELL, THE NEWEST ONE IS VERSION 10.1??? AND EVEN 10.1 IS 1 YEAR OLD? WHAT THE FUCKING FUCKK AAAAAAHH...

So yeah, after that, without any expectation, I had a look at our codebase. Unit tests huh? I couldn't find a single self written one to test the applications functions... I asked my fellow devs and they told me that "it is too time consuming and we have to focus on new features, the QM Team will just manually test the application". Ever heard this bullshit? A big fat ass codebase with shittons of customers and not a single unit test...

So last but not least, since it is a web application, it also got a site. Y'know RichFaces? The deprecated front end library for Java Webpages? Where you got like 150 Tables per page everyone with a random id everytime you reload? Yeah I don't think I have to explain that to you guys...

So now YOU tell me? Is this a place to be 😂😂😂

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?

Change one line of code. Fix the tests for the next 6 hours. This is absolutely normal... NOT!

Following my first rant, my boss had the brilliant idea of running the old and the new architecture in parallel. I had advised that it won’t be ideal since the same Scala code was ingesting into 2 different Kinesis streams and one was running an old KCL written in Java where as other was consumed by a Firehose delivery stream(eventually we will be ingesting it into Firehose directly). I had told few manual + automated tests on Code as well as from a functionality of the new architecture and a set of tests for checking the integration of the new Producer code with Consumer.

The statement I got from my boss was “This is the test, we test it on production in parallel”. My boss had a brilliant idea to fucking test the new code on the production directly but running them in parallel without accounting for undefined behaviour it might cause in the current production system. I mean my boss should get a Nobel peace prize for shattering our mental peace.

Anywho, we started the deployment today at 5AM in the morning. I had all the aws services deployed. Was just waiting to deploy the new Collector code which we did at 5AM. Immediately after 5 minutes the system went bonkers, there was fire, blood, demons and I was smoking a cigarette with the biggest “I told you so smile” on my face. I’ve just written an email to my boss and have told him calmly that “Listen motherfucker, 90 percent of the software companies aren’t idiots to focus on testing and quality. We need to start spending time on testing and quality else we’ll again be in the same soup after few weeks again”.waiting for his reply

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?

One responsibility of our team is general code QA for the entire dev department, DevMgr walks in our area yesterday…
DevMgr: “Has anyone reviewed the new WPF threaded model execution code?”
- everyone on the team responds “no”
DevMgr: “Can we get a review on that code ASAP? If it works as well as the developer said, it’s going to solve the lock up problems users are experiencing and automatic logging of errors.”
DevA: “Well, no amount of code is going to stop users from performing bad searches locking up the user-interface. That code is just a band-aid around the real problem. If the developers would write unit tests first …”
- rant about 5 minutes on unit testing that had nothing to do with why the DevMgr was here
DevB: “Yea, the code probably isn’t written to handle threads correctly. All the threading they’ve done so far is –bleep-”
DevMgr: “Oh, I wasn’t aware of that. Get me the results of the code review and if they don’t have unit tests, delete it from source control and let the developer know it’s not up to our standards.”
OMFG!! You have not even seen the code!
OK, DevA ..what the –bleep- does unit testing have anything to do with the user interface! You know the DevMgr is too dim to understand the separation of concerns. Shut your pompous ‘know-it-all’ mouth.
DevB…what the –bleep- have ever done in WPF? You manage the source control and haven’t written any C# in two years and never, ever written code for any significant project. Take that “handle threads correctly” and shove it up your –bleep-. Pompous –bleep-hole. Go back and watch youtube and read your twitter while the grown-ups get the work done.

My work product: Or why I learned to get twitchy around Java...

I maintain a Java based test system, that tests a raster image processor. The client is a Java swing project that contains CORBA bindings to the internal API of the raster image processor. It also has custom written UI elements and duplicated functionality that became available in later versions of Java, but because some of the third party tools we use don't work with later versions of Java for some reason, it's not possible to upgrade Java to gain things as simple as recursive directory deletion, yes the version of Java we have to use does not support something as simple as that and custom code had to be written to support it.

Because of the requirement to build the API bindings along with the client the whole application must be built with the raster image processor build chain, which is a heavily customised jam build system. So an ant task calls out to execute a jam task and jam does about 90% of the heavy lifting.

In addition to the Java code there's code for interpreting PostScript files, as these can be used to alter the behaviour of the raster image processor during testing.

As if that weren't enough, there's a beanshell interface to allow users to script the test system, but none of the users know Java well enough to feel confident writing interpreted Java scripts (and that's too close to JavaScript for my comfort). I once tried swapping this out for the Rhino JavaScript interpreter and got all the verbal support in the world but no developer time to design an API that'd work for all the departments.

The server isn't much better though. It's a tomcat based application that was written by someone who had never built a tomcat application before, or any web application for that matter and uses raw SQL strings instead of an orm, it doesn't use MVC in any way, and insane amount of functionality is dumped into the jsp files.

It too interacts with a raster image processor to create difference masks of the output, running PostScript as needed. It spawns off multiple threads and can spend days processing hundreds of gigabytes of image output (depending on the size of the tests).

We're stuck on Tomcat seven because we can't upgrade beyond Java 6, which brings a whole manner of security issues, but that eager little Java updated will break the tool chain if it gets its way.

Between these two components we have the Java RMI server (sometimes) working to help generate image data on the client side before all images are pulled across a UNC network path onto the server that processes test jobs (in PDF format), by reading into the xref table of said PDF, finding the embedded image data (for our server consumed test files are just flate encoded TIFF files wrapped around just enough PDF to make them valid) and uses a tool to create a difference mask of two images.

This tool is very error prone, it can't difference images of different sizes, colour spaces, orientations or pixel depths, but it's the best we have.

The tool is installed in both the client and server if the client can generate images it'll query from the server which ones it needs to and if it can't the server will use the tool itself.

Our shells have custom profiles for linking to a whole manner of third party tools and libraries, including a link to visual studio 2005 (more indirectly related build dependencies), the whole profile has to ensure that absolutely no operating system pollution gets into the shell, most of our apps are installed in our home directories and we have to ensure our paths are correct for every single application we add.

And... Fucking and!

Most of the tools are stored as source bundles in a version control system... Not got or mercurial, not perforce or svn, not even CVS... They use a custom built version control system that is built on top of RCS, it keeps a central database of locked files (using soft and hard locks along with write protecting the files in the file system) to ensure users can't get merge conflicts by preventing other users from writing to the files at all.

Branching is heavy weight and can take the best part of a day to create a new branch and populate the history.

Gathering the tools alone to build the Dev environment to build my project takes the best part of a week.

What should be a joy come hardware refresh year becomes a curse ("Well fuck, now I loose a week spending it setting up the Dev environment on ANOTHER machine").

Needless to say, I enjoy NOT working with Java. A lot of this isn't Javas fault, but there's a lot of things that Java (specifically the Java 6 version we're stuck on) does not make easy.

This is why I prefer to build my web apps in python or node, hell, I'd even take Lua... Just... Compiling web pages into executable Java classes, why? I mean I understand the implementation of how this happens, but why did my predecessor have to choose this? Why?

Started porting one application written in php to:
Golang(and some libraries to make certain sht simpler like GORM and Gorilla amongst a couple of others, most shit is STD shit already built in)

Java Spring(I know it well, but wanted to try this particular app in it, lots of boilerplate although the coded is solid AF)

.NET Core API, which I separated in a series of modules for the domain interface, the persistence logic, the actual api etc, I really dig it. It has a basic React frontend in Typescript whereas the other 2 versions are using the standard Go html/template package and the Twig interface for Spring.

My favorite thus far is Golang. I find it extremely easy to extend, the language reads good enough for a retard like myself to make sense of it fairly easy, really easy to test and experiment with it, any idea I get for something to add(say users and stuff) took me less than 30 mins to figure out while reading the actual documentation, as in the base documentation or just the source code.

I know the language is retard proof, and I am highly enjoying this. Not to say that the other two are bad, not at all, been using C# and Java for years now, but I highly appreciate being able to concentrate on functionality rather than all the fucking architectural boilerplate needed to run basic shit in the other two frameworks. Thus far Golang has been a breath of fresh air the likes Clojure gives me, while not even being a profound or mind blowing language in terms of features(since other than the interface{} and goroutines i can't think of shit) and have not reached a scenario in which I am stuck or dying to have generics one bit for the overall business logic.

The app is growing like crazy in terms of code since the original php application was huge to begin with, but dear me this shit is as simple as it can get without being too technical. Might move it to production once all usability tests pass and force the rest of the staff to learn it. I have one lead dev that damn near refuses to touch anything other than php, and a very eager to try shit out content administrator that comes from a Java and C# background.

all I want to say is how much I love go haha

I’m currently working 2 jobs with over 60 hour work weeks in addition to my own SaaS company.

One job is full-time 40 hours, where I am a mid level developer and I just do the waterfall of tickets that is assigned to me. This place is unorganized and has almost no communication within the team.

The second job I am the Senior Dev and project lead. It’s a contract position that I put 20+ hours in on the evenings and weekends. Agile methodology, with a modern tech stack and I promote excellent communication as well as documenting everything.

I’m in a unique position because I’m able to see these differences and compare them side by side. My full-time job doesn’t really know about the second job. I get my work done, and that’s all that matters. This place is a mess. The project lead (CTO) is a helicopter boss that sticks his nose up at any type of formal documentation and practices. No tests are written.. no SIPs or deployment docs.. no stand ups or anything. I must also mention this team has 5 developers and a QA.. my team is only 2 developers and a QA. We get through tickets much faster.. it helps when I go over every single ticket that is created and add requirements and images..

I guess my point is... I’m about to be a full-time contractor because I can’t take this unprofessionalism anymore.

Just because these formalities technical take longer. It does decrease actual time spent developing a project. Spending a couple of hours on tests and requirements can save you days of back and forth in the future. Not to mention... document.. everything.

Remember how I was - against all that was promised - assigned to a time-sensitive front-end (so definitely not my forté) project about a month ago? Remember how I struggled with the choices of how to go about it - switching from F# (Fable) to Rust (Yew) to eventually settling in with Vue and TS?

Yeah, I’m glad I went that way, even though there could’ve probably been better choices out there: my part is done now, even though it’s not quite prod ready yet (close tho), the team who’ll maintain it takes it over now, after I finish dealing with my current minor issue. And damn their front-end guy is GOOD. Makes me feel very inferior in that department. Well, I am. Back to back-end, thank you very much...

But I have an issue here, that bothers me. I’ve produced a codebase that’s obviously written on a tight schedule: no tests, no documentation, a few embarrassing hacks/workarounds and so forth. I actually feel bad for leaving it out of my hands to them in such a state...

I remember back when I was in pre calculus I decided to take a class online. So my teacher's website was made by him and run on go Daddy, he taught precalculus, calculus, algebra, algebra ii, and computer science. I decided to penetration test his website and use a web crawler. His directory that had the tests, test answers, exams, exam answers, and homework answer's as well as all the books he's written in PDFs, was unprotected, I could access and download them all. He also had a database directory that contained all the students' phone numbers, email addresses, home addresses, and their full names.

I alerted him to this and didn't get anything in turn :P

I implore ANYONE... please...

Have you EVER written a SINGLE Jest test that didn't have some sort of bullshit spewing stuff like this:

"ReferenceError: You are trying to `import` a file after the Jest environment has been torn down."

"Warning: React.createElement: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: object. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports."

and yet running on a device, features work flawlessly and quite well, no errors or even warnings in sight logged

This is the most fragile pile of garbage I have ever seen.

I hate this.

inb4 your stupid ass todo boilerplate garbage you wrote tests for in freshman year. i'm talking about a REAL app with HUNDREDS of components.

where the grownup testing tools at? it's a question I've still not answered after a year of fucking around with this framework

I've just joined a new company out of despair after several month out of jobs without being able to even get interviews.
I've been warned about the code being a bit behind with modern Android stack, they needed to migrate from rx to coroutine and compose is not a priority at the moment.
Fine with it, I like handling and planning migration, that's a nice challenge.
But if only that were the only problems !! Far from it, the code is a formidable mess, I've never seen so much amateurism... Most of it was written from the previous Lead Dev who stayed there for years and touched everything with their very bad practices.
I don't even know where to start honestly...
While the code is in Kotlin, it stink Java. Nothing wrong about Java, but if you code in kotlin, you need to understand what kotlin try to achieve. And that's not the case here. There is freaking nullable everywhere, for no reason at all, the data classes contains lot of var in their constructors, equals are override to compare only one or 2 params and no hashcode override with it.
Sealed class, what for ?! Let me just write a List<Pair<Enum, Any>> and cast your any depending on the enum !
Oh and you know what, let's cast everywhere, no check, and for once no null safe, there is enough nullable in the code !

What about the reactive part ? well let's recreate a kind of broken eventbus with rx ! Cause why not ?!
The viewmodel observable don't contain data, they just contain enum for the progress of the states we're checking.
In the viewmodel function we update that enum states and emit it to be observed and make the data available as a var for the view to pick it up when needed.
But why put the business logic in the viewmodel, let's put in the views, and grab and check the variable contain in the viewmodel whenever it fits.
Testing the business logic ? uh let me just test my variable initialisation in the viewmodel instead.
The vm, the views, make about 2000 lines, the test over 3000, and not a single test really test the business logic in it ! I've made big refactoring we're all the tests stayed green, while the function are full of side effects ! WTF ?!
Oh and what about that migration from rx to coroutine ? well better not break the existing code and continue writting like rx, everything is cold flow ! We just need to store a boolean saying if we already did our call to the data layer then we decide to start our flow or not.
As for the RecyclerView, having too many viewHolder is just so annoying, let's put all our different views in one, and hide what we don't need.
Keystore has been push on the repo, but it's private no ? So who cares ?!
And wait i'm not done ! Some of the main brick of the apps depends on library that hasn't been updated for years, and you know what... yes they were hosted on Jcenter and it's only now that they decide to do something about it, we we're warned about the sunset of jcenter 2 years ago !!!!
So what about compose ? What do you want with compose ?! there is no design system in that app obviously, so don't even think about it !
And there... among all of that mess, I'm supposed to do code review... how the fuck do you do a code review when all the code that is around stink ?!
And there is so much more but by now I'm afraid you're thinking i'm just pissing on the old code like everyone... but damn I guarantee, that's the worst code I've ever seen, and i've work on more than 15 app from small to big on different contract with a lot of legacy code, but nothing that bad !

Ever had to switch out a whole serializing layer in an API? Damn that's a lot of work :(

At least the 1952 tests are written well...