• (nodebb)

    Now, I'm speculating a bit, but, I suspect this is pretty clear evidence of how the pandemic may have impacted some businesses.

    Except that logically, the extra column should have been added in late 2019, before the pandemic blew up in our faces, to be ready for the beginning of the new year.

    Unless they are financial years...

    Someone was supposed to add the new column. They may have been laid off, or retasked.

    Or, if the years are financial years rather than calendar years, the switch to FY 2020 might have been after the beginning of the pandemic, and the person may have been relieved of the task called "be alive"...

  • (nodebb)

    Why do I feel a sense of closure at the end of this article? Justice for all...

  • dusoft (unregistered)

    One of our clients used to have a document they called "A holy grail". It was a spreadsheet with lots of rows to be updated every month and then sent to us for import. One day the exports stopped coming. We asked a couple of times, but nobody really responded regarding this and it didn't seem like they cared.

    And then after about 9 months we had a big meeting, the spreadsheet came on screen and suddenly one guy commented: "Oh that one, yeah, yeah, this guy gave it to me and then left the company. I didn't know what to do with it."

  • Roby McAndrew (unregistered)

    Could I query the exactitude of "sometime in late 2019 or 2020" ?

  • (nodebb)

    That's some lazy copy&paste&replace action there... Sometimes I wonder if copy&paste should only be available to devs with a proper sanity license. You know, for those answering questions like "Is it okay to put business logic into SQL statements?" correctly, similar to the sheet you get when you try to enter the US.

  • see sharp (unregistered)

    Makes one wonder if the underlying table actually started life as a spreadsheet, where (for the most part) rows and columns are arbitrary dimensions with no functional distinction. Need to add data for the next year? Add a new column; no different to adding another row for whatver that dimension represented. Then, someone was tasked with bringing the data into a database and did a row-for-row, column-for-column mapping, preserving the layout of the data without giving any thought to functionality, meaning, or how databases actually work.

  • (nodebb)

    Maybe I'm to logical but if I had written this and gotten to the trouble of expanding the when case up to 2026, I'd have have also created the empty corresponding tables up to 2026.

    That or I'd have stopped at 2019, period.

    But not both. That bugs me.

    If you're going to do some work, at least do it seriously -- otherwise embrace your laziness and don't do the work at all!

  • (nodebb) in reply to Ralf

    For a dev lazy is actually good (KISS,DRY) but sloppy, well, that one is a pain for the whole team if you have someone like that basically only creating work for all the others ;-)

  • Officer Johnny Holzkopf (unregistered)

    What we can observe here is a misunderstanding of numbers representing years. The last "column" of the year goes from 3 in 2013 to 9 in 2019. What number comes after 9? There is no number bigger than 9, and just counting further would go from 2019 to 20110, 20111, 20112 ... 20119 and then maybe 201110. None of those fit into a 4 "column" year representation, and with code like this, you could even assume there is some strange string splitting somewhere that someone invented for date processing, because there is no tool or library to do this. Bonus points for counting 2018, 2019, 20110, 201J, 201Q, 201K and 201A (this works until 2024, the year to leave that company).

  • (nodebb) in reply to MaxiTB

    Sloppy is just excessive laziness in the mind.

Leave a comment on “2019 Was a Fine Year”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article