Programmer Humor

1. Take from index 10 of the buffer, AND it with some hard-coded hex value.

2. Bit shift it by a hard-coded amount of 2

3. Do the first two steps, but with a different hard-coded index, hex value, and bit shift.

4. OR the two results.

5. Shove the result back into a buffer.

All of this is one line with no commenting or references to what the fuck this process comes from or why it is applicable. Then there was a second copy of the line, but with different hard-coded values.

For anyone who knows and understands Android development, process death, and saved state...

The previous dev had no understanding of any of it, and had null checks with returns or bypassing important logic littered all over the app, everywhere.

I could only assume he didn't understand how all these things were randomly null or why it was crashing all the time so he thought oh, i'll just put a check in.

Well, you minimize that app for a little bit, reopen it, and every screen was fucked visually and unusable, or would outright crash. It was everywhere. This was before Google introduced things like view models which helped but even then for awhile weren't a full solution to the problem.

It was many many months of just resolving these problems and rewriting it the correct way to not have these problems.

Here is my story:

There were console outputs after nearly every line. I asked about them: "Oh, I couldn't get the debugger to work, so I print everything to the console"

This was everywhere. The whole program was like this. On a standard Linux machine. It wasn't even remote debugging or something. Just a local C++ program.

The filenames where written in 8+3. Again, on a modern Linux machine. His answer? "You never know where we'll port this software to"

Onto computers that were outdated decades ago? To embedded systems? Of course he had no answer for this except "just in case..."

I could tell you more, that software was the stuff for nightmares.

At a small company I used to work for we agreed to take over the management system for someone trading physical resources. The guy that originally wrote it was self taught. We did a hand over with him where he took us through the code base. It was written in dotnet but it was a huge mess, he had blended multiple different dotnet paradigms, there was mixed business and UI code all over the place, large chunks of html were stored in the db, db code was just scattered through the application. We took it over briefly but it was a nightmare to work on and we found a SQL injection vulnerability. So as kindly as possible we told the client that his software was a piece of shit and the dev he hired had no idea what he was doing.

It was a huge codebase in c# with a single file in VB.net with a comment at the top "copied from codinghorrors.com/…". I never dared to try understanding what that file was supposed to do and why nobody bothered converting it in c#

I think the worst software-gore I remember seeing was a web app that dumped all the data to the browser as a huge XML file and then had JavaScript translate the contents of the xml into views. That probably wouldn’t even sound that far off the reservation now if it was JSON, thanks to the sleepless efforts of the JavaScript industrial complex, but back then you’d just render pages and return them.

There was something like

# sleep for about a second on modern processors
math.factorial(10000)

After it was found we left it in the code but commented out along with a sleep(1) for posterity.

So this is not as bad as some of the other stories I've seen, but I'll bite.

It was an old .NET Framework MVC app. Some internal product management system or something. There was a need to do a PDF export in one of the use cases, so someone implemented it. It wasn't a good implementation: one big controller, mixing UI and business logic, etc. However, it basically came down to a single private method in a specific controller for a page.

Now time passes and lo and behold, we need a PDF export in another page for a different use case. "No problem," - same dev, probably - "I already solved this problem. I'll just reuse the PDF generation logic."
Now, any sane person would probably try to refactor the code responsible for PDF stuff into a separate service (class) and reuse it. A less sane, but somewhat, acceptable approach would have been to just copy paste the thing into another controller and call it a day.

Ha! No no no no no no… Copy pasting is bad, code should be reused…

The end solution: REFLECTION. So the dev decided that the easiest way to make it work was to: 1) use reflection to inject one controller into another; 2) then use reflection again to get access and call that private method for PDF rendering into a stream.

Fortunately I didn't have to fix that fragile mess. But I did my fair share of DevExpress corpse hacking and horrible angular "server side rendering" workarounds.

This might require a bit of background knowledge about Power Query in Excel and Power BI, specifically the concept Query Folding.

Power Query is a tool to define and run queries against a host of data sources and spit out tabular data for use in Excel (as tables) or Power BI (as Tabular Data Model). The selling point of it is the low-code graphical presentation: You transform the data by adding steps to the query, mostly through the menu ribbon. Change a column type? Click the column header > Data Type > select the new type. Perform a join? Click "Merge Queries", select the second query, select the respective key column(s) to join on and thr join type – no typing needed. You get a nested table column you can then select which columns to expand or aggregate from.

Each step provides you with a preview of the results, and you can look at, edit, delete or insert earlier steps at will. You can also edit individual steps or the whole query through a code editor, but the appeal is obviously that even non-programmers can use it without needing to code.

Of course, it's most efficient to have SQL transformations done by the database server already. Bur Power Query can do that too: "Query Folding" is the feature that automatically turns a sequence of Power Query steps into native SQL. A sequence like "Source, Select Columns, Filter Rows, Rename Columns" will quite neatly be converted into the SQL equivalent you'd expect. Merges will become Join, appending tables becomes Union, converting a text to uppercase becomes UPPER and so on.

If at some point there is a step it can't fold, it will use a native query to load the data up to that point, then do the rest in-memory. Even if later steps were foldable, they'll have to be done in-memory. You can guess that this creates a lot of potential for optimising longer queries by ensuring as much or it as possible is folded and that the result is as "small" as possible – as few rows and column as feasible etc.

Now, when I tell you that there is a table in one of our sources with a few large text columns you almost never need, you may be able to smell the smoke already. A colleague of mine needed help with his queries being slow to load. He had copied some code from Stackoverflow or what have you that joins a query with itself multiple times to resolve hierarchies. In theory, it was supposed to be foldable, provided the step it runs off of is. The general schema of my colleague's query went Data Source -> non-foldable type conversion -> copied code -> filtering (ultimately keeping about 20% of rows) -> renaming columns -> removing columns. Want to guess which columns were loaded, processed with each join, explicitly renamed and only then finally understood to be useless and discarded?

"I always do the filtering last, don't want to miss anything."

This is your regularly scheduled reminder that MS (and our corporate BI team) can present Power Query as self-service data transformation tool all it wants, that still doesn't mean it's actually designed for use by non-data techies.

I wrote an algorithm that should be recursive but in expediency I wrote a loop that iterates 10 times.

It's fine but I'm still mad 3 weeks later

Back in the day, a C program to handle estimating procurement costs for complex government contracts. We had to figure out the code and write in in a different language. It was just one giant loop, no functions, with variables named V1, V2, V3, etc. Hundreds and hundreds of them. I still shudder at the horror of it all.

Oh, I've seen some doozies... The one I remember the most, and I've seen this twice, is this:

myClass.TheProperty = myClass.TheProperty;

When I asked about it, the developer said that, well yes, because it reads from one place and sets in another! Not at all difficult to read!

I got forcefully moved onto another team at work. They use Observables to replace signals, change detection, local storage, and even function calls. Every single component is a tangled mess of Observables and rxjs. Our hotlist has over 300 bugs, and the app is like 6 months old.

I've been looking for a new team

It was a Java project and every class was in a separate Maven module.

Had a coding firm costing 1k+ euros which was unfamiliar with django select all() from DB just to cast that into a list each time a user opens the tool. That got real funny real fast when the customer started adding the announced 50k objects per day. They did that buried in about 50-60 api endpoints conveniently coded by hand instead of using genetic api endpoints available from django rest framework.

When the loading times hit 50s per click, the company took the money and ran. My colleagues and me spent 2 years and half that to fix that shit.

My university uses ORACLE. To make a payment from a research account, you need to manually input a 15 character chart string. Every time.

Mine.

I should state that I'm not a programmer. I'm a network engineer.

I work for a space (among other things) contractor, and there are days I feel like I'm mission control for Apollo 13.

A switch that would just return the input value with a constant offset ... hardcoded for over 40 consecutive values.

Private key for a third-party API hard-coded into the front-end web app

This was then sent to the server as pure sql, no orm.

ORMs are overrated.

The encryption thing is definitely weird/crazy and storing the SQL in XML is kinda janky, but sending SQL to a DB server is literally how all SQL implementations work (well, except for sqlite, heh).

ORMs are straight trash and shouldn't be used. Developers should write SQL or something equivalent and learn how to properly use databases. eDSLs in a programming language are fine as long as you still have complete control over the queries and all queries are expressable. ORMs are how you get shit performance and developers who don't have the first clue how databases work (because of leaky/bad abstractions trying to pretend like databases don't require a fundamentally different way of thinking from application programming).

There are a couple that come to mind.

Definitely the worst, a C# .net mvc application with multiple controllers that were 10s of thousands of lines long. I ran sonarqube on this at one point and it reported over 70% code duplication.

This code base actively ignored features in the framework that would have made things easier and instead opted to do things in ways that were both worse, and harder to do. For example, all SQL queries were done using antiquated methods that, as an added benefit, also made them all injectable.

Reading the code itself was like looking at old school PHP, but c#. I know that statement probably doesn't make sense, but neither did the code.

Lastly, there was no auth on any of the endpoints. None. There was a login, but you could supply whatever data you wanted on any call and the system would just accept it.

At the time I was running an internal penetration test team and this app was from a recent acquisition. After two weeks I had to tell my team to stop testing so we could just write up what we had already and schedule another test a couple months down the line.