Gurpreet Kaur

Hello. I'm Gurpreet Kaur, and I have been working as a full stack developer on the ASP.NET framework for the past 10 years. My core programming languages are C#, VB.NET, and I have experience building web APIs, and building UIs on the Angular framework. Along with that, I have hands-on experience using various ORMs, for example, Entity Framework, Dapper. I also have experience with Microsoft SQL Server. If I talk about cloud computing services, I have experience with Azure, DevOps, Azure resources, and stuff. Secondly, I also have experience with AWS, consuming an S3 bucket to upload files, retrieve data from there, and so on. This is the whole tech stack I work on.

To validate the accuracy of the data and the reliability of the data analysis, I used to query data in the database itself, writing SQL queries and seeing what output I was getting. And if I needed to validate it from the UI, I would compare some data based on some interpretation or calculation formula. So I used to query data directly in the database, and then I would compare it with the output which my system or the web APIs were returning to the UI. Directly creating the database first and comparing those records with the output on the UI side. This is what I used to do before presenting my findings.

I have been working to build web APIs, RESTful web APIs, from approximately 8 to 10 years now. So, I used to build web APIs considering the security, whether it's Identity Server 4 or OpenID Connect to get JWT tokens and tokenize the request from the front end in order to get authorized access and retrieve the data from the web API. And in order to have Razor templates, when the web API is having a response, I used to render or bind that data on the Razor template to build the web pages.

In order to meet multiple inheritance because C# object-oriented programming, the C# language doesn't support multiple inheritance too. So in order to achieve that, we used interfaces. We need to define members and methods in the interfaces itself and then implement them into another service files, exposing them and consuming them, having the actual implementation there. And whenever abstract classes cannot be initialized, we used interfaces instead of abstract classes. It is to prevent memory leaks. So whichever object is being used, it has to be disposed of after the use or after the request gets executed. So garbage collection comes in place to dispose of the resources. And these things help a lot. Like, it improves the performance, and also, it helps to clear the memory. And, yeah.

Stored procedures are basically inline SQL queries, which we use to write, and they could be nested. Like, we have various joins. We can do unions, intersections. So stored procedures could be a long SQL group of long SQL queries. And functions are SQL queries, they return a return value. But functions are also SQL objects only where we do some sort of calculation. And those functions can be consumed within these stored procedures. And thirdly, views are also temporary, like temporary tables only where we use to store the result of SQL queries to read data from.

So if you talk about reusable code, we used to build a utility layer. Suppose I have a utility layer where I have a set of methods which are doing some generating functionality. Suppose I have a method or I need to join strings or I need to join, like, I need to convert an array into a comma-separated string value. So that could be a common method, and it can be used application-wide. So I'll keep it in a separate utility layer, which I'll expose as and when required. So if we do reusable code, this basically follows the DRY principle of the coding language, where we're not repeating ourselves. So, don't repeat yourself. It is to write a single piece of code that should not be rewritten every time. It should be consumable right away. So, common methods which are doing some basic calculations or suppose I have a formula-driven interpretation of data. I will create a common method only, which will be called as and when required from different services. And this helps a lot in order to have a clean, written code, easy to maintain code, and scalable code. It will not use much resource, and it will improve the performance as well.

Alright, so again, it is to have a scalable and easy-to-maintain architecture. First of all, we should have a well-developed architecture. So, especially, we should have an entire architecture with different layers, easy-to-read code. And if a team is working on the same code, then naming conventions should be written properly so that every developer can understand. Also, XML practices should be followed, including XML commenting, in terms of implementation. And to help with error handling for web applications, we should follow loggers where we write down the errors triggered by user interactions on the web application. So if any user encounters an error, we should write those errors into our log file, and we can go back to the log file and check the code line to read out the entire stack trace to see which line of code has broken, and we can fix it right away. And to make it more like the best user experience, we should not throw errors as a layman. So errors should be thrown with a meaningful message on the UI so that users can also understand what has failed, whether it was the user's improper input or anything else has broken on the back end. And to have proper performance, we should have services in the background. So if anything needs to be scheduled, such as email sending or SMS sending, we should have background server files or service files that will be working in the background. And to have good performance while reading large data, we should go with server-side pagination, sorting, filtering, which will return a little chunk of data on the UI side, and it will improve the performance. And yeah. Those would be some of the practices I will be following. Along with that, I would like to follow SOLID principles in terms of the implementation of code. That's it.

I have been assigned a task. I have been given any feature or any bug to fix. During the review or when I had just delivered my changes and they went live, and things were not working as expected. Then at that point, of course, I would be the one held responsible because I was the one who had worked on it. And if things were not working as expected. I would be the one responsible. And, of course, I would go further to revise it and get it reviewed by the other team members or directly by the business team so that they can share their feedback, and I would learn more about it.

Okay, generally, as I had worked with previous teams, previously with different teams, so there were times when any team member would reach out to me because they were facing this issue. Or sometimes while working on my assigned ticket, I would find out some different bugs on the same screen or while analyzing any work item I would find. If I found any bug, I would address it right away regardless of who had worked on it or whether I had worked on it earlier. Whoever had worked on it would be notified when it was fixed. So I would solve the issue, and I would notify the team without pointing out to anyone. I would notify the team or the team manager that I had found it, and I had included the patch in my work itself. And the team has always appreciated those findings and those fixes. And even if I needed some more information to get it fixed, I would talk to the team members. And, yeah, it has always been a fruitful thing.