Interning as a software engineer at hSenid Mobile — Part I

Right off the bat I should say that this is not my first job, and surely not my first time interning … however this is my first job that I’m doing remotely. Even after all this time we are all still getting eased into this whole “living with Covid” situation: not the best kind of situation mind you, but it surely has its’ perks. What’s worse than a Monday morning? … well, living a dozen miles away from the workplace. Sheesh … waking up at 5 in the morning to catch a bus to be on time at work. Trust me, that’s not fun. Remote working almost completely eliminates that from the equation of the daily to-do list, but this has it’s pitfalls too: missing the ‘first few days at your new job’ feeling is one of those. As much as I like to rant about how I felt, let me enlighten you about what I came across in the first few days of my new internship.

So, Skype is still a thing

Remember Skype? That one video calling app which most of us didn’t use? Maybe I was too young back then but considering the plethora of video calling applications that came in to play, I wouldn’t have been surprised to find Skype to be long dead. With the likes of Zoom, Slack and Teams taking up majority of the cooperate culture, I was part relieved to find the old school application alive and kicking. It was not the Skype I remembered. This new version was fully fledged with the essential tools for cooperate environment communication. This was the preferred method of communication for hSenid as well, and it really made me wonder why people jumped on the Zoom bandwagon, instead of sticking with Skype.

I had to start reading again

Believe it or not, I love reading; at least I used to. Never really found the time or the patience to stick through a lengthy online forum as of late, let alone a novel for that matter. I guess social media has really thinned out my attention span, which is surely not for the better. I had to muster up whatever was left of my focus to start reading this book: “Clean Code”, which was written by Robert Cecil Martin: a very sassy person, mind you. I felt that from the get-go, but the tone of the author really manages to penetrate the idea through, on how important clean code is. I learned about various conventions that I wouldn’t have considered in the first place: proper naming, vertical and horizontal indentation, commenting, testing, structuring of a project, etc. What really stuck with me was how disciplined you have to be to write clean code, since the clarity of a code is of equal precedence to the logic at work, and you have to actively refactor the code as you go, to maintain that industrial standard.

Touch-typing

With an average typing speed of 60+ words per minute, and an average accuracy of around 98%, I never considered myself to be a shabby typist. Things took a rough turn when I was told I had to practice typing without looking at the keyboard. For the majority of typing I’ve done in my life, a little bit of peeking was needed to readjust my fingers, but the work ethic of hSenid encourages you to be so efficient to the point that taking that split second off is considered a waste of time. Thirty plus minutes of touch typing every morning for a month, and I saw a significant increase in my ability. Not only did my accuracy improve, but now I barely peek at my keyboard anymore.

The VIM editor experience

The VIM editor, also known as VI improved, is an open source powerful text editor which can be used on any platform. Now why am I using this? … Apparently vim can be used to remotely edit server side files, and this skill is required of me if I am to take part in this companies endeavors. It doesn’t look like much from the outside, but I have come to learn that getting the major VIM commands down; especially if you make it your second nature, you wouldn’t be needing another text editor. It is that much powerful.

Maven: The build tool

I’ve had some minor experience with Maven prior to getting my feet really wet. By experience what I really mean is executing the ‘maven spring-boot: run’ command on the console to test out a project. I’ve only known Maven as a build tool, but nothing more. In fact, I didn’t know what a build tool was in the first place, but now I do. A build tool is essentially a program which automates the process of converting a source code into an executable, and this process includes the likes of validation, compilation, testing, packaging, verification, installation and deployment. I had to experiment with the ins and outs of this build tool to get in touch with it.

My first training activity for this was creating a multi module sorting program comprised of a service and a core package. I had to implement insertion-sort, bubble-sort and selection-sort. ‘Pretty simple stuff’ I thought, but I was not ready for multi module madness. Majority of the time allocated for this activity was spent me trying to understand the pom file and setting the dependencies properly. However, by the end of it, I was much familiar on how to work with Maven.

Back to basics with SQL

I’ve been engaging with SQL back and forth for the past few years; especially during my foundation year at university. SQL has been my first experience with a database, may it be relation or non-relational, and I was happy to be in familiar grounds. However, the training activity which was given to me comprised of a few unfamiliarity’s like database reverse engineering, database normalization, working with MySQL CLI and working with the SQL workbench. I also had to spend time researching since I was out of touch with most queries. For the most part, the activity felt like a walk in the park; I had to create a database, a few tables and write queries to retrieve specific results. Things started going south when I reached the latter parts of the activity when I encountered the likes of joining tables and creating stored procedures. I wish I had a bit more time to research about the aforementioned latter parts, but it is what it is. I completed the activity to the best of my ability with the given time.

The struggle with Spring

I don’t know who came up with the name Spring, because it surely felt like I was caught in a frozen tundra for days on end. It took me a really long time than I initially anticipated to get the project up and running, and even after that it felt like my project was being held together by bubble gum and shoe strings. I was dreading to make any improvements to the program or clean it up further, assuming that everything would collapse in on itself.

The activity I was assigned with was creating an employee management web app with CRUD functionalities. Create, Read, Update and Delete … four functionalities. How bad can it be? … Very bad. I’ve had my fair share of PHP experience on small scale projects, so I was familiar with the functionality of parsing data across pages, but not on a level of how spring did it. I could clearly see how Spring makes things easier with its’ JSP files, annotations and controllers, but the knowledge and familiarity required to get comfortable with this framework was not easily accessible.

This activity took me the longest time to complete, and I when something went wrong, I would scrap that project and create a new one instead of figuring out the root cause. Spring really loves bombarding you with lines and lines of errors, and that was surely not in my favor. The IntelliJ IDE, which was supposed to help me out was clearly making things worse with its’ weird dependency issues.

I managed to somehow complete the task up to a considerable standard (not the prettiest, but it does what it set out to do), and through that I learned about service classes, controller classes, repository classes, JSP files, endpoints, entities, artifacts and substantially more.

Setting up the environment

Take everything I mentioned and cram it up to DEFCON 1. That’s what my experience was like setting up the environment required for my work laptop. I was not using windows anymore … I was using Ubuntu and was instantly in deep waters. I have used Ubuntu a few times in the past, but it never appealed to me. I knew it to be more efficient for programming, but I preferred to do all my work on Windows. There were a lot of syntaxes to learn, especially since using the GUI instead of the terminal was considered ‘a waste of time’, I had to get familiar with using terminal for everything, and that includes navigation, downloading and installing applications, tracing log files, creating files and directories, etc. I eventually got better at it, but the path was surely a rough one.

The environment required to run the projects, required me to install three databases (SQL, Postgres and MongoDB), two APIs, Maven and webservers like Nginx and Apache Tomcat. Getting the project to run was an endless process of tracing log files, including dump files and WAR files, and googling. I heaved a sigh of relief as the webpage finally loaded.

What’s yet to come

I guess you could call this section a conclusion to this blog, and I’m hoping to follow this up with another write-up, which will include sections on how I did my first contribution to a project, my experience with AJAX and some really useful Linux commands that I came across. Till then, Cheers!