Old Team

As mentioned previously, I was assigned to another team barely 1 month into my new job. Initially, I felt I was dumped, but from the current situation, I was glad it happened.

When I was still in my old team, the last task in progress was an enhancement to a function. We are going to receive a new kind of data from Not Competent Solutions. My task was to create new tables to hold the data and new screens to display them, and to add Update and Invalidate functions for old data. It is urgent with a tight deadline, only 1 month, inclusive of non-working days. But it shouldn't be difficult since it's just mostly displaying. I was allowed to put my tasks at hand aside.

The person in charge, R, briefed me. Currently, the function is a popup. The title of the new data will display on this popup. To see the summary of the new data, click on the title to open a popup. To see the details of the new data, click a button to open yet another popup. So fond of popups! It sounded like a horrible design, so I suggested redesigning it. But R said the users wanted it.

Huh... I thought R should talk the users out of it, but o well... *shrugs*

Without any knowledge of the purpose of each of the fields of the new data, I found it hard to decide what to display. What does the user need to see? I also didn't want to entrap myself in case the field to display actually needed much processing beforehand and its presence unimportant. Who wants to go through a lot of unnecessary trouble to display something optional, just because I proposed it?

R's advice was to display "everything". More is better than less. This means displaying the code name AND display name of the item, for instance, when surely, only the display name will make sense to the user. Do you need to know that your Ricola herb flavour, large size, is called RIHL in the inventory?

By the way, I do not understand Not Competent Solutions' rationale for sending code and display name together. Shouldn't they just send the code name, maintain a separate list of code and display names and map the 2 tables? By doing it their way, when there is a change in, say, display name, they have to sift through all the data to update. More work instead of less. If it were done the proper way, they would only need to update 1 row what. Obviously they don't need a sotong to teach them something as basic as this, so I'm really curious about why they still chose this stupid way. Maybe want to charge more effort when the time comes.

The users approved the screens. I bet they did not even spend a minute to think about whether the information is useful or makes sense. I bet they didn't even really know what they wanted to see on the screens. It doesn't bode well.

Due to my lousy computer that hangs up to 4 times a day, my unfamiliarity with the IDE and not-so-up-to-standard programming skills, I ran into scheduling problems. I caught up by sacrificing a Saturday and ignoring potential problems regarding the update. Get the basics up first, fine tune later.

Because of the Invalidate function, it would make sense not to display invalidated data in the Current list, yet still display in the History list. I reflected to R and he agreed. No mention of any time extension. The other in charge, M, will surely say such a "small" change, 1hr can finish, time is tight, cannot extend. Although the documentation said this enhancement does not include anything not mentioned. The programmer shall slog for the flawed impact analysis.

There were still many things unconfirmed. Many new dropdown menus are added, but there was no mention of where the items were coming from. R and M didn't know if Not Competent Solutions was going to send that. I have only like 1 week left, but they still haven't discussed that.

Then there is this label, "Update Reason", which could either be filled in by selecting from the dropdown menu or typing in the textbox. But in the database table, there's only 1 column for Update Reason, instead of 1 for dropdown and 1 for textbox. So with the data from the database, how do I know where it belongs? If the user makes changes, I can't possibly merge data from 2 fields into 1 column? Computer is stupid one lor, I need an indicator or a set of rules! Whatever the case, it's additional work.

The time came for me to leave the team. There were still things I didn't have time to think over. There must still be undiscovered problems. Not mine anymore.

1 month has elapsed long ago, but I still see the poor guy, B, who took over my shit coming to ask R and M what to do about this field and that field. Or R and M telling B that there are changes. This is really shitty man, why did they rush into things and still let the user anyhow change? If the deadline remains, the buffer is... wow. Really weird way of doing things.

I just confirmed that the leader really does nothing at holding the team together. He was on leave on Friday. We all didn't know he was leaving the company until the new, enthusiastic leader came to start taking over the project's documents and the soon-to-be-ex leader's desk although he has not officially taken over yet.

Everyday, my old team is the last to go for lunch and the first to return from lunch. They rarely chit chat. I'm happy I'm not with them anymore. But sadly, I'm still sitting with them.

To be fair, I must give them credit for still helping me to buy lunch. And the rare chit chat.