What is it like working at ICAN Future Star?
It’s been one month since I started working at ICAN Future Star Ltd and what a month it’s been, I’ve never experienced anything like it before. For a start, I’m currently the only British born person in the company. This is amazing as I’ve learned so much about the history and cultures of others in such a short space of time. For instance I never knew how similar Scotland and Galicia are. They’re a Celtic nation with their own unique bagpipes and apparently our climates are rather similar as well.
Canón de sil in Galicia (Spain)
At ICAN we also have weekly knowledge transfer sessions on Wednesdays. This is where the whole company get together over lunch, we talk about what we’ve been doing since last Wednesday, it’s a chance to give feedback and suggestions on any topic. It also means everybody’s up to date with what’s happening throughout the company.
We have a policy about answering emails which is simply, to reply to emails as soon as you can. This goes for internal and external communication. I can’t stress how lovely this is, knowing that you won’t be left waiting for a reply for hours means we can all be as productive as possible.
There are a few things that are pretty standard when it comes to working in a startup. Like the fact that it’s likely you’ll be doing several different things and it’s up to you to switch between them so everything gets done on time. This is actually one of the reasons I like working in startup companies though. Your job never slows down or becomes boring.
I’ve only been working at ICAN Future Star for a month but I can tell you that I’m looking forward to month two and beyond.
Three months have passed since I started working for ICAN. Life has moved quite fast during this time and the company has made a good progress. Last month we signed a new customer, and now we are working hard to deliver the product to the highest standards. We can say that all the efforts are now focused on the development of the new tailor-made application for this university.
As the back-end developer, my role in this project consists of dealing with all the server-side tasks: linking databases with the application APIs, while handling the network connections. And this is not an easy job, honestly.
From the beginning, I have been dealing with some modules that need to be changed, adapted and updated to meet the new requirements, and use the latest versions of some of the libraries they depend on. Equally difficult is to deal with code written by other people. Not only because you depend on the documentation –sometimes quite obtuse, sometimes quite exiguous when not directly inexistent— but also because it implies the effort of putting your mind in the same state as the mind of the author of the original code.
Taking into account that the development time for this project is a bit tight, you need to do all the work-outs quickly, so you do not fall behind and delay the project.
In this sense, now is when I am really understanding all those boring lectures at university on dealing with legacy code, and the importance of fitting to the standards and providing good documentation. Surely, the more your code follows the good practices, the better your code is (even if is not the most efficient implementation for a particular algorithm).
For example, the in-line comments and meaningful variable names help to understand the flow of the execution. Using the right idioms for the programming language you are using also makes the code cleaner (what it works for C or Java does not necessarily works for Haskell or Python). Not to mention indentation: structuring code in the right way helps the reading flow and quote the scope of functions and other structures. Little details like these improve maintainability and robustness of the code, which in most of the cases is even more important than extreme performance.
Legacy code is always problematic to deal with. Of course, this is part of the job and it will always be: software is quite organic, in the sense that it is continuously evolving. For this reason, when writing programs it is important to bear in mind not only the program itself but also that someone else will use or look after that piece of code. So I guess these are the lessons I have learnt during the past weeks working for this company.
Thus, help others in your team –or the community if you are developing for an open-source project— by abiding the standards and documenting your code. If you do so, your colleagues will thank you while your code always excel. Too simple, and too complex at the same time, right?