Want a successful career working as a Full stack Engineer? Charles Frederic Atienza, a Full Stack Engineer at Tech Startup, Jala, in Singapore, shares his journey and advice to aspiring Engineers and Developers looking for an exciting and challenging career like his own.
Want a successful career working as a Full stack Engineer? Charles Frederic Atienza is a Full Stack Engineer at Tech Startup, Jala, in Singapore. Charles sits down with us to share his journey and advice to aspiring Engineers and Developers looking for an exciting and challenging career like his own.
I am the lead engineer for Jala, a startup whose goal is to provide a platform that connects translators and people with translation needs.
As the lead engineer for a startup, my role involves a lot of responsibilities that would normally be divided among several people in larger companies. I am in-charge of leading our scrums, translating business requirements into actual application features, maintaining our servers, and mentoring more junior engineers.
Jala is a Singapore-based startup that not only provides a platform that serves as a marketplace for translators and projects, but also assists in the act of translation with computer-assisted translation tools. On top of these tools, we also employ machine translation to help translators produce better results.
To be honest, I always thought of pursuing a career in game development not general software engineering. I started programming for the sake of learning how to create my own games. I got into software engineering during the last year of my collegiate days when I was selected to become a Microsoft Student Partner and then subsequently connected to one of Microsoft’s partner startups in the Philippines, CloudSwyft, which I then worked for, for three years.
I still work on games as a hobby and I still hope to have the time to actually finish and release one, one day. I keep in touch with the latest video game development trends in both the AAA and indie scene.
I do not think I have had my first big break yet but if I were to choose one, it would be landing my current role at Jala now. Being hired as the lead engineer came with a lot of challenges because I immediately had to maintain a product built with ancient technology and work on revamping it with more modern frameworks at the same time. I like to think that I succeeded in that regard.
Before applying for Jala, I worked primarily as a web developer in Makati, Philippines. My first job was also with a startup which I think jump-started my career as a web developer because it gave me the opportunity to work on every layer of an application stack. It was great because I worked with the latest frameworks at that time and I was never stuck with one layer, and continued to jump around the application.
Although working for a startup does have those advantages, it also comes with disadvantages. One of the more glaring ones is the lack of process. Enterprise-grade engineering teams employ a lot of standard operating procedures like testing, build scripts, design sprints. I realised that not getting experience with these procedures would hurt my career eventually, so I then moved on to work with larger companies and joined outsourced development teams of DocsCorp and Panalitix before moving to Singapore to work for Jala.
A typical day would actually be us not communicating much unless there’s a feature or bug that requires collaboration. Since we’re a small team with some working remotely, we don’t really benefit much from daily standup meetings so we only hold standups on Mondays.
As for me, I usually work on my own tasks unless my team needs help on theirs or when I have meetings with the product design team. Some days are spent accomplishing code reviews submitted by my team. My work day usually starts around 10:00 AM and ends around 6:00 PM.
We use VS Code the most, for development and Git for source control. On top of these tools, we use a lot of open-source frameworks like Angular, .NET Core, Nginx, etc. For code reviews, we use GitHub pull requests and for scrum planning we use AirTable.
Being the lead engineer, I report directly to our CEO and co-founder. The way we work is very loose with a lot of roles merged so I also work closely with our marketing and design team. I am the go-to person when there are questions regarding the technical feasibility of new requirements or addressing bugs, and even replying to user complaints.
Yes. I have been looking into microservices lately and I am planning on bringing it up with the team. From what I have read, migrating our monolith application to a microservices pattern will prove beneficial not only for the development team, but also the product design team, as they will have more freedom on deciding which new features they want out first.
This endeavour will largely impact my role because I would have to lead this migration and instruct my team even with me not having any actual professional experience implementing microservices, only experimenting with them on my own time.
It would have to be the time and freedom dedicated to experimenting with new technologies.
I find it most satisfying when I read up on a new framework, experiment with it, then actually integrate it with our application.
My current role allows me to do that often because, being the lead engineer, I get to decide on how to implement new requirements and improve upon existing ones.
The resistance to implementing processes. I believe that having freedom on how to implement new application features rapidly does not necessarily mean having to abandon processes on deciding which of those features to implement. I see processes as much a tool as any code editor because it unifies teams across departments on how to move forward with improving the product.
I graduated with a degree in Game Development so I’m kind of in the grey area where I learned programming formally, but not towards software or web development so I can go either way.
What I do have to say though, is that if you want to work in an international development team you will have to know software engineering practices that go beyond just making things work. So things like test-driven development, continuous integration and continuous delivery, architectural patterns are concepts you can read about online but will have to put into practice as these concepts are expected from you in more mature development teams.
You can go online and learn how to perform addition in code but learning how to perform addition with code that is maintainable, testable, and readable are things you learn with formal education.
When we onboard new junior engineers, I task them first with learning our stack. I make them try to learn it on their own by just reading through tutorials and documentation but I do assist them when they get stuck.
Afterwards, I need to get them familiar with our source code and solution structure. How I do this is, is to assign them minor bugs that would require them to navigate all around the source code. This way I can be confident that when I assign them tasks like implementing new features, they would know where and how to implement it.
I look for the basic skills for an engineer first, but I am actually more interested in their attitude. I need to know that the engineer can communicate well and is teachable. I always remembered what my first team lead told me on my first job. “You can teach skills but you cannot teach attitude”. So I always try to hire engineers that are enthusiastic to learn and know when and how to communicate effectively.
Honestly, just knowing how to look up solutions on the internet. It may sound like an informal way of solving problems but I assure you a lot of senior engineers would just do the same if they get stuck on a problem. This is not to say that you should never go to your seniors with any problem but to try to only do that as a last resort or with a problem that is very specific to the code of the application you are working on.
I have found that learning things on your own is more effective than having someone feed you the answers because when you figure out the solution to a problem, it will stick with you.
I recommend building a simple application but with a stack that is new to you. By the end of it, you will have something to add to your portfolio and skills at the same time. The application requirements do not need to be complex. What’s important is that you get yourself some experience on the latest technologies that are being used right now and the way to do that is to build a full application and get your hands dirty with every layer of the application.
This is not specific to any profession, really. But you should make it a point to research the company you are applying for. Learn what their business and history is. You won’t believe how many times we have had to explain to an interviewee what Jala does during the actual interview. Knowing who your potential employer is and what you will be working on will not only show recruiters and interviews that you are actually interested in the company and not just looking to get paid but will help you make a much more informed decision when deciding whether to accept a job offer.
What and how many programming languages you know will not do you any good after a couple of years as an engineer. You can always learn a new language with a 4-hour crash course online. What’s important is keeping up with the latest technologies and architecture patterns being used in the industry. And also, never set aside proper use of data structures and algorithms. As your applications grow, proper data structure and distribution become crucial and will save you a lot of headache.
Get used to test-driven development as soon as possible, continually observe proper use of data structures and algorithms, and, if you can afford it, do not let the salary drive your career path.
Charles Frederic Atienza is Full Stack Engineer. Gamer. Game development hobbyist. Might switch to professional game development in the future! You can find Charles via LinkedIn.