Five Things I Learned During My Internship at Hyperlab
Being an intern leads to a lot of different experiences that you don't experience during class. It's a whole new thing to actually work with a project through a company than just making an application with your classmates.
I am studying front-end development in Gothenburg and I started my internship at Hyperlab at the end of October 2018. Down below I will present 5 things I learned through my internship.
1. Variable names. Are they really that important?
I remember one project in class and my classmate realised that we had one function that handled everything. Could you guess the variable name? It was called
test! It was my fault and everything began with me trying to solve a problem in our codebase. In the beginning, I did not realise that the function was going to have such a big impact on our code so I just left it as
test "for the moment". But "for the moment" resulted in me forgetting about it and instead, trying to solve "more important" things (in my opinion).
Eventually one day my classmate asked me:
"Jonathan what does this function called test do?"
We laughed and we moved on!
At a company, though, it's not that easy! You have a lot of coworkers that are reading or will be reading your code. Even if you don't have extremely bad variable names as I did, you should start considering if it fits in its context.
It's extremely important, even for yourself to be able to understand your own code in the future.
If you start doing it now, it will be easier to handle problems in the long run.
2. But it's just a console.log!
I wouldn't even want to look back at my previous school projects. Maybe it seems like a pretty decent app when you see it in the browser, but it is a totally different thing when you look at the code.
In the master branch, you can see exactly where we were debugging our code with tons of
console.logs. And beyond that, they were not even good messages that helped us out!
You can take a look and enjoy yourself by looking through my code on github.
But is it such a big deal? Yes. In the long run, it actually is. It disturbs other developers when they review your code, takes more time, and it looks kind of unprofessional having a message popping up in the console saying "lalalala" while showing your code to your boss or other coworkers.
I guess it's okay when you are doing a school project or on your own at the moment but eventually, you will end up working in a team and then it's better to start implementing a habit of deleting unnecessary code.
3. They will eventually understand my code
What I did not realise in the beginning was that my coworkers actually looked more at my code's structure than the actual product. It was frustrating because I put a lot of effort in the product.
At the beginning of my internship, I wanted to show them that I was able to code and produce things! I wanted to show them that I was able to make things at a good pace. If you try to make something fast you will probably have to deprioritize some things in your process. I deprioritized code structure and instead focused on the actual product so I would have something to show.
They agreed that I could deliver a product, but not that I could deliver good code.
By good code I mean readable, refactored, structured, with reusable components, suitable variable names, and also make it possible to rearrange components in case we would like to make some changes in the future.
4. Is this a commit message?
During school, I just made random commit messages. It could be messages like "Ok", "DONE", "fixed", " ", "CODE", "FINALLY", "I made it!!!!" and so on. And again, just check my github if you want to see some interesting commit messages. I was just being silly I guess!
After a while, my coworker asked me this:
"I can understand that you are happy that you 'FINALLY' made it through this message, but what did you actually do?"
5. It's done, but no, it's actually not!
You know the feeling of working through something for a couple of days and you finally realise that you are done! A pull request is made, and you wait for your coworker to merge it into master so you can check off that task. And then the comments start rolling in:
"Ehh Jonathan I don't understand this, and what is this? Why did you do it like this?" And on it goes...
In the beginning, I got a lot of these comments from my reviewers. I had to make a lot of changes that sometimes took even longer time than the actual task itself. It frustrated me that I had to do all of it again!
Today it still happens, but not as often as it did before, and hopefully with not as many changes.
Now I take time to actually review my code on my own before I make a pull request. It saves a lot of time.
You won't be done just because you made a pull request, because maybe someone else has a different point of view of how to solve the programming task that might be more efficient.
I still have a lot to learn about programming and I guess it's the same for everyone.
If you don't know how you should start, begin with reviewing your friends' code and start a habit of trying to understand their code. If you don't follow along with the structure of their code you should tell that person so they can improve it to make it more understandable.
Sometimes it can feel a bit mean in the beginning, criticising each other's code but it will help you become a better developer.
Skrivet av Jonathan Johansson