Programmer Humor

Whatever im working on 💪

Not mine, but svn-based JDSL is the best related story that's always worth sharing.

https://thedailywtf.com/articles/the-inner-json-effect

VB.NET app that was installed on every employees computer to capture time sheets. Required VPN access so it could talk to the accounting DB using raw queries, zero input validation, and it used a pirated library for the time input grid control.

The IT staff who would install the program on all new machines (it didn't work with their imaging system) had a script to suppress the message requesting a paid license. There was nothing special about this control, it was basically a rip off of built in winforms controls.

Source code was long lost, but reverse engineering and decompiling CIL/MSIL code is thankfully relatively straightforward.

I'll consider myself lucky that the worst I've had to deal with was a 8K LOC C file that implemented image processing for a cancer detection algorithm. Nothing terribly tricky but just poorly organized. Almost no documentation at all. The only test was running this code against a data set of patient images and eyeballing the output. No version control other than cloning the project onto their NAS and naming it "v2" etc.

Research code can be really scary.

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.

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.

Joined a new team and one of my first tasks was a refactor on a shared code file (Java) that was littered with data validations like if ("".equals(id) || id == null) { throw new IllegalArgumentException() }

The dev who wrote it clearly was trying to make sure the string values were populated but they apparently A) didn't think to just put the null check first so they didnt have to write their string comparison so terribly or else didnt understand short circuiting and B) didn't know any other null-safe way to check for an empty string, like, say StringUtils.isEmpty()

I spoke with a client just last week, international scale, that let me know their user passwords are simply encoded and stored in Base64 haha

First One:

Big ASP.Net Core Web API that passed through several different contract developer teams before being finally brought in house.

The first team created this janky repository pattern on top of Entity Framework Core. Why? I have no idea. My guess is that they just didn't know how to use it even though it's a reasonably well documented ORM.

The next team abandoned EFCore entirely, switched to Dapper, left the old stuff in place, and managed to cram 80% of the new business logic into stored procedures. There were things being done in sprocs that had absolutely no business being done there, much less being offloaded to the database.

By the time it got to me, the data layer was a nightmarish disaster of unecesary repo classes, duplicates entities, and untestable SQL procedures, some of which were hundreds of lines long.

"Why are all our queries running so slow?"

We'll see guys, it's like this. When your shoving a bunch of telemetry into a stored procedure to run calculations on it, and none of that data is even stored in this database, it's going to consume resources on the database server, thereby slowing down all the other queries running on it.

Second One:

Web app that generates PDF reports. Problem was it generated them on-the-fly, every time the PDF was requested instead of generating it once and storing it in blob storage and it was sllloowwwww. 30 seconds to generate a 5 page document. There were a list of poor decisions that led to that, but I digress.

Product owner wants the PDF's to be publicly available to users can share links to them. One of the other teams implements the feature and it's slated for release. One day, my curiosity gets the best of me and I wonder, "what happens if I send a bunch of document requests at once?" I made it to 20 before the application ground to a halt.

I send a quick write up to the scrum Master who schedules a meeting to go over my findings. All the managers keep trying to blow it off like it's not a big deal cause "who would do something like that?" Meanwhile, I'm trying to explain to them that it's not even malicious actors that we have to be concerned about. Literally 20 users can't request reports at the same time without crashing the app. That's a big problem.

They never did fix it properly. Ended up killing the product off which was fine because it was a pile of garbage.

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.

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.

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!

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

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