• Michael (unregistered)

    Frist they will have a shared calendar for the PMs to remind them of a JIRA work item to update the code

  • (nodebb)

    I used to think stuff like this was bad, but in my older years, anything that drags out the workday to make less "real" work is A-OK in my book. Oh, it's coming to the end of the script's content? I'll update that so we don't have to do it again for 10 years or so. Boom, a day or two of busy work where you're left alone.

    To quote Stanely from The Office: This here is a run-out-the-clock situation.

  • Industrial Automation Engineer (unregistered)

    that's trivial to correct: if len(date) < 7 then date = left(date, 5) + "0" +right(date,1) end_if;

    What could go wrong? </sarcasm>

  • Tim (unregistered)

    I'd just write a script that generates a 1000 line function - good for 100 years

  • Industrial Automation Engineer (unregistered) in reply to DocMonster

    If you've become that jaded, you should retire. It will make both you and your employer much happier.

  • (nodebb) in reply to Industrial Automation Engineer

    Ha! The way that's going, retirement will never be a thing. And at this point, I could care less about the employer being happy. They're the useless part of the relationship.

  • The Dave G (unregistered) in reply to DocMonster

    The employer pays you, correct? In my book, that makes them far from useless.

    But yes, this a total, compete, wtf.

  • Guilty (unregistered)

    I definitely have done stuff like this... "I will c&p it for this year and until next year, the proper solution will be in place". Repeat every year.

  • Sauron (unregistered)

    That code serves its purpose perfectly.

    I insist: that code serves its purpose perfectly.

    Because the very purpose of health insurance companies is to extort cash from people to waste it. That code fullfills the money-wasting part.

  • LZ79LRU (unregistered) in reply to DocMonster

    Fundamentally the relationship between employer and employee is a trade. We sell our time and labor in exchange for money as well as ancillary benefits such as free coffee in the office. Therefore whilst the employers happiness is indeed irrelevant their satisfaction as a customer of our sale is not. Just as our satisfaction as the provider of services is relevant.

    At the end of the day both sides have the freedom and ability to take our business elsewhere. So whilst we don't have to like each other a degree of mutual respect and work ethic is required from both side.

  • (nodebb) in reply to The Dave G

    It's definitely a WTF. Just one that older me doesn't care as much about as younger me would have.

  • (nodebb)

    Lowest common denominator.

    This requires no knowledge. Any new hire of the week can update it. They might roll their eyes, get it done in 2 minutes, and move on.

    What's a database layer again? What's the particular date format function for this? That requires more time to figure out for a noob, and they will likely get it wrong at first, need to debug it, etc. Extra work likely not rewarded as a useful task by their manager.

    Sometimes good enough is just good enough.

  • LZ79LRU (unregistered) in reply to Ralf

    And some times you get exactly what you paid for. See my previous comment (if it ever gets unblocked) for context.

  • Riho (unregistered)

    It's called job security

  • Dave (unregistered)

    As a SAS programmer, I can say that this entire thing could be replaced with:

    year_month = catX('-', scan(year_month, 1, '-'), put(input(scan(year_month, 2, '-'), 2.), Z2.)) ;

  • WTFGuy (unregistered)

    IMO Ralf nailed it. As of now, the least-cost way to push the problem off to 2024 is to c&p the last 12 lines, edit the year number to "2023" in those, and commit your change. Management only cares about immediate least cost. Therefore as a worker you should care only about immediate least cost.

    This is also the least-risk way of avoiding regressions. If there's a long-standing bug in the c&p from, eg, 2017, something will break if you "fix" that by doing a smarter 2-line string replacement that gets every month right, not just most of them. Converesely, if a bug is introduced in the 2023 c&p, it'll probably manifest pretty immediately in production.

    Testing? We don't need no steenkeen' testing. Real Men (of whichever sex) commit directly to Prod.

  • (nodebb)

    I particularly love these lines:

    else if year_month = '2014-10' then year_month = '2014-10';

    If my can of seltzer is on the table, then re-put it on the table.

  • Brian (unregistered)

    This is what happens when quick'n'dirty becomes institutionalized. If it takes two minutes to update a script vs. two days to refactor the whole system, why bother doing it the "right" way? Change is risky, after all. Next thing you know you'll be storing entire JSON docs in a DB column because it's too much trouble to change the schema.

  • DQ (unregistered)

    Why would you need date functions for this? Something like

    year_month = Left(year_month, 5) & Right("00" & Mid(year_month, Find("-",year_month) +1), 2)

    would do the trick.

  • Phil K (unregistered) in reply to Mr. TA

    That whould be illogical to have less than 12 lines added each year

  • (nodebb)

    which is 'the database layer'. The database should be in the business of returning dates as date objects. the ui layer should convert them to however-the-user-is-meant-to-see them.

    I think actually a newbie would try and convert that to use some sort of, I don't know, string processing involving, I dunno, split. Or length checks. Or something. The existing maintainers would probably send the changes straight back though. Because it's not in a consistent style with the rest of the code.

  • Duke of New York (unregistered)

    I haven't touched nor thought about SAS in decades, but it looks like TRWTF is defining a macro that doesn't take the year-month as a parameter, doesn't produce the scrubbed year-month as a value, and does no evaluation within the macro processor (using %IF rather than IF) but only emits code with a side-effect to the interpreter.

  • (nodebb)

    Most of your proposed solutions would break for the year 10000.

  • (nodebb) in reply to DQ

    What language are you using to write your SAS macro? Your code doesn't look very similar to Dave above, who pointed out that he is an SAS programmer. :-)

  • Duke of New York (unregistered) in reply to LZ79LRU

    You can hold out for respect and satisfaction, but other folks will throw them in the shredder to pay the bills. From where I've been sitting for the last several years, the policy of employers is: if you have a better idea, keep it to yourself. I remember when things were different, but that was then.

  • (nodebb) in reply to Phil K

    Yes, because adding 12 lines each year is super logical hahahaha

  • Graculus (unregistered)

    Surely there is a good case (no pun intended as this could be a case statement?) as this means there is no string manipulation which means there is no indeterminate running of a background garbage collection to tidy up strings and any invalid date coming in isn't blown up by clever substring code throwing exceptions again causing performance issues.... yes it might be "stupid" code but we don't know what else is around it

  • LZ79LRU (unregistered) in reply to Duke of New York

    I do not think you understood what I said.

    The satisfaction I am talking about is explicitly customer satisfaction. As in not you your self being satisfied emotionally but the satisfaction of the counterpart in an economic arrangement.

    For example say I am selling you bread. As the counterparty in that deal you to be satisfied with the bread as a product and the price I am offering it for. And I need to be satisfied that you are giving me the correct amount of money and that said money is proper legal tender. If either of those two conditions are not met than the deal won't go through.

    In the context of this discussion what it means is that the employee has to work good enough that the employer is a satisfied customer, gets what they want to get out of the deal and therefore continues to desire to retain the employee. And the employer in turn needs to do the same to prevent the employee from leaving.

    And if the employer wants crap that means giving him crap.

  • FTB (unregistered)

    If I ever get fired from my job I know they'll be calling me back in a few months time when the program starts to freak out.

    Plus I'll be able to charge them "consulting" rates to patch it up for another year.

  • Bored at work (unregistered)

    year_date = put(input(year_date,anydtdte.),yymmd.); is how I'd solve the problem efficiently, and knew how to do less than 2 weeks after my first SAS exposure - which was very disappointingly not %put Hello World!;.

    But why not do it by generating all the possible options for the last 50 months to the next 50 months in a table, hash mapping the table and having a function apply the hashmap? If I'm going for job security after all I might as well make it as tricky as possible for anyone else to read/debug?

  • Tinkle (unregistered)

    Updating this by hand every year is a terrible WTF

    They should have a cron script running every month, say on the 29th that will add a line for the next month to this script. What could go wrong? Just test it for a year and if all is well you can forget about it.


  • Prime Mover (unregistered) in reply to davethepirate

    In order to avoid the y10k problem, the simple fix is to detect the position of the hyphen, compare it with the total length of the string, and use that to determine whether to squeeze an extra zero in after said hyphen. If there ain't no hyphen throw a reboot exception

  • Alistair (unregistered)

    It is likely that recent dates will be processed more frequently than older dates, so this code can be made more efficient by reversing the order of the tests.

  • (nodebb)

    else if year_month = '2014-10' then year_month = '2014-10'; else if year_month = '2014-11' then year_month = '2014-11'; else if year_month = '2014-12' then year_month = '2014-12';

    TRWTF is nobody understands that the reason it's done this way is to be able to include three new lines of useless code every year. This is PROGRESS, people!!

  • Duke of New York (unregistered) in reply to LZ79LRU

    I've already had the praxeology lesson, thanks.

  • LZ79LRU (unregistered) in reply to Duke of New York
    Comment held for moderation.
  • meclizine otc (unregistered)
    Comment held for moderation.
  • (nodebb)

    When I started at my current job many years ago we had a situation like this: there was a database table consisting of two columns, one with months in MM YYYY format and the other with the same month in YYYY MM format. This was in a system built by a contractor, and we didn't have access to the database part, only to the front end. Sales budgets could not be added for dates past the end of the data in this table. So pretty clearly a hostage situation (we had already parted ways with the contractor).

    Fortunately someone had discovered that we could get into the database part by adding linked tables that pointed into it (this was all in Access; I said it was many years ago, and in fact we were in the middle of a project to replace the whole system when I joined), so I did get to do the job of adding another year's worth of months to this table so that we could keep using the old product until the migration was complete.

  • (nodebb)


    Addendum 2023-09-06 22:12: Discovering Dianabol has been a revelation in my fitness regimen. The effects have been simply astounding. My muscles are dianabol pills for sale growing at an unprecedented rate, and I find myself breaking personal records in the gym effortlessly. Dianabol is, without a doubt, the ultimate game-changer in my quest for physical excellence.

Leave a comment on “Yearly Updates”

Log In or post as a guest

Replying to comment #:

« Return to Article