Project Walkthrough

I am almost done with my internship at SBI. It has been a lot of fun, as well as a lot of work, which is cool. Usually, interns are either useless or forgotten; it is not unusual for them to spend their 8 hours sitting in a chair and then go home. I am very fortunate that I have actual missions.

Since all my projects are coding-based and revolve around connecting different web platforms, I am faced with a lot of completely new information daily. To write code, you need to understand what you want to achieve. It is difficult to tell a computer what you want when you do not even know yourself.

So let me walk you through the general functioning of a project at work. It corresponds to any kind of learning process.

First, you get the mission. It is motivating and energising. You have a vague vision of how to do it and just throw everything you've got into it. At first, you get some theory down and then get practical. Do some quickstart guides on the basics, and then try to change the basics for your use case.

That's one of the most fun parts. Things move fast, and you improve yourself and the project consistently. The demo offered by a quickstart is usually easily in reach, and it really sets the ground rules for your own project. However, my projects are often so specific that there is no documentation whatsoever on how to solve my problem.

That is usually when things start to block. Then comes the first error. Errors are not the end of the world; they are part of the process. Yet that red coloured cryptic text does not help with motivation. Especially when you start getting only errors, and nothing at all is working as it should.

This is the moment when motivation fades. Especially when, for example, you get the same error for 3 hours in a row. That's incredibly frustrating. The simple solution is "to do things differently", but usually in those moments it is very difficult to understand how differently.

At some point, it clicks. You get a slightly different error and manage to troubleshoot it. That's the holy grail. Getting momentum again. Once you get the ball rolling, it seldom stops again for a little while.

Through literal trial and error, you reach the first viable version. It is the version that, on a very basic level, does what you want. It is not perfect, but it is enough to build upon with more ease.

The following is optional and depends on the project. If there is time, then you can and should improve the product to be more user-friendly, since the first viable version is usually something only you understand and can use. For example, adding comments to the code, making a button on a website to launch the code, adding logs to see how the code evolves when launched, etc.

As I write this, I am working on a project to extract metadata from Pigment (a business planning platform) and reinsert it into the same platform. To break it down, my code needs to extract all the names of the applications inside of Pigment, make a table of them and then put it back into Pigment.

To conclude, it is great to be working on such open-ended projects; the final product is never fixed in advance. Furthermore, it is great to be given the freedom to operate in a sandbox to test all kinds of solutions. It really puts to test my problem-solving skills which is very refreshing.

This Week's Suggestions:

🎶 "KI/KI - BBC Radio 1 Essential Mix House Party":

This mix has great energy. It has the bounce and the melody. Of course, it is very well brought together technically. If you wonder why I am only suggesting mixes recently, it is because I am going to Berlin for the weekend, so I am getting myself into the mood!

💡 "How to Get Whatever You Want":

This is very much edited with the Alpha Grindset vision, which I have difficulties with, but the content of this video is great. Spend 4 minutes to have a little refresh!

Have a lovely Monday!