Daily Log #112

As I mentioned yesterday, I decided to go with a high protein/fat diet but that doesn’t mean I cut down the carb in the form of rice. And the best thing happened. I didn’t feel hungry nor do I find myself snacking on anything until 7.30pm. Considering I had my lunch at 12.30pm, I call that a win.

By high protein/fat, well, I went with 1.5x the serving of Char Siew Pork and 1.5x the serving of roasted pork belly with one egg. There is also a liberal amount of sauce.

I’m sure people probably suspected that I ate beyond the calories I need from that single meal. And I agree. But what people fail to realize is digesting food also take energy. For that amount of fats and protein I have consume, at least one quarter of it is spent on digesting. Combine that with exercise, I think I can bring my weight under control…hmmm…yup…lots of it is wishing thinking…but had to try it to see how it goes.

That aside, there’s something that grind my gears at work.

The company that I work at now pride itself for being an engineering company. Even the management from time to time will cite at their core, they are all engineers. There’s nothing wrong with that only except the actions I have seen coming from my management team, at least on the project I’m on, ran contrary to that.

For me, I just feel that processes and best practices should be followed as thoroughly as possible with no compromise on safety and quality. For something to have utmost safety and quality, testing is a big part.

Yet, in the software project I’m on, there is no unit testing, no proper regression testing. The only test conducted is by the developers themselves. And developers, no matter how senior, can fall into the trap of testing only the happy cases and a few exceptional cases. Hell, even I myself can forget about certain edge cases that my old codes have catered for but was ultimately removed as part of refactoring. And then there is always the situation when I want to do more testing, I got called away to do something else. This sudden context switch always make me forget what I was trying to do before. And it doesn’t take long for other tasks to come along later in the day and make me forget about my changes. Before I realize it, that code is deployed to production and things start breaking.

As with anything, it takes two hands to clap. I maybe highly conscientious at work, able to think of edge cases and whatnots, but I’m only human. I’m not infallible. My memory can fail me.

The lack of testing won’t be so bothersome if nothing bad came out of it. But for the last four months alone, my team and I have been fighting one fire after the next due to the constant demos, trial runs, etc. and that the application kept breaking. Even today too. The customer wanted to do a trial run with the application because they are complaining we took too long to go production.

Therefore, my colleagues went to the customer’s main office to start installing the applications necessary last Friday. Then today during the trial run, there was some access right issues.

For context, that issue is actually caused by a bug in the logic that handles access checking whenever user request for access to specific resources. This bug actually surfaced early august, two days before Singapore National Day when the application was supposed to be trialled by the user.

And that piece of code was written by me eight or nine months ago but was never fully tested. It’s my fault for not doing sufficient testing and always default to using the super admin account. And I didn’t expect it to go to production so soon anyway.

Well, because of National Day being two days away, I had to manipulate the data to allow the access checking to always succeed, at least for the trial. After that event, I spent one and a half day testing the crap out of the new code I wrote and then roll it out to our development environment for testing by an internal tester. It worked. However, the fix was never released to production because the codebase already have many other new features implemented. We didn’t want to risk deploying an even more buggy application when there is two more demonstrations after that.

And I did hate myself thoroughly for writing that lousy piece of code.

So I wasn’t surprised if the bug surfaced today again but it was not in a way I expected. Hell, I even drew the wrong conclusion. The bug was even more sneaky, if that’s the right word to use. It turned out there was also a logical error in how the code determine which user belongs to which group that ultimately decide the kind of resources the user can access. It’s a double whammy.

The only time the code worked as intended is when the user belongs to one group and it must be the first group that comes up for checking and must always return true to the caller. Then all the resources has to be in that same group. Resources belonging to another group will also work, if and only if they are also in the first group.

Understand where I’m going so far?

The logic falls apart for every other case and will always return false, therefore permission denied.

So if you are me, and have been doing programming for more than ten years (including school), don’t you want to kill yourself over this?

I got to say this is one of the worse bugs I have ever introduced into a system.

And in my defense, seriously, don’t distract me or rush me or ask me to context switch. This is what happens and will happen always. Whenever I do something, I want to devote all my attention and energy into that one single thing.

Given how this company operate, I doubt I can have that option. And I’m also doubting my ability to continue this line of work at this kind of pace. I just feel like there is no “deep work” anymore. I also don’t see myself developing tunnel vision as of late. And I got to say tunnel vision is a good thing when applied correctly. It is especially useful when you are writing a single piece of function or code and then you get to test the crap out of it.

That reminds me of something my colleague said to me this morning too when I provided her an API to retrieve recently online users that did kind of make me roll my eyes.

For context, there is a minor bug with the API that seemingly returned duplicated record because of a failure to limit the time range. The second is that it may need a scheduled task to ensure the data for the heartbeat for the user’s session is updated when the client is logged out or dead (hang or non-responsive).

What happened was, my colleague actually asked me to perform that update when the Get Current Online User API is called.

Deep down, I’m like, “ARE YOU FUCKING SERIOUS, LADY?”

Look, I care deeply about best practices. I care about code quality and standards. Best practices exist because they prevent the code from becoming a big mess. So… whatever function I wrote is always adhere to SOLID principle whenever possible and will always be for one specific use case. A new use case equals a new function or a series of related functions with one common entry point. Therefore, a Get/Fetch/Find function will always do just that. Retrieval operations only. Same for Update, Add or Create. And I follow the naming convention of domain driven design so that the original intent of the function is not lost.

And you are asking me to perform an “update” in a “get” operation?

Are you serious?

Are you fucking serious?

To think that you work for far longer than I have…

No wonder your own code based is also a huge mess that don’t make any sense when I read it. Wrong use of static functions and variables. Wrong use of private methods. Wrong use of double dispatching. Wrong use of model when in reality it is a service. POCO everywhere with zero object orientation.

Despite me always saying want to quit IT and programming in general, turns out I still care a lot because all the things I mentioned do affect the final quality of your work, whether tangible or not. I believe in that.

So I have three options.

  1. Encourage my colleagues to change their mindset
  2. Accept that kind of crap mindset and do my work.
  3. Leave for a place that does engineering/design better.

I for one is leaning towards the third option. The first option will just be a waste of my time and energy. I just won’t do option two. I can’t turn a blind eye to it.

And I remember I once told my supervisor during my first internship and first job (they are the same person), “I will always strive to write the perfect piece of code that is as bug free as possible.”

She replied, it’s not quite possible. And writing good code means you won’t have a job anymore because there is no need to call you to fix bug.

For me, it’s never so much about having a job. It’s about the attitude to whatever I create and output. It’s also about showing to everyone that I can write really high quality code and that you can trust I will do the same over and over again. That is just my conscientiousness talking.

Ok, this daily log is bit long because I wanted to get stuff out my chest.

And I will end off this log with the following:

Truly quality work comes from within, comes from that strong desire to create something that make people’s life easier and stress free with liberal application of attention to detail.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.