I was a very introverted kid. It got better with time, but I still consider myself an introverted person, actually. Back then, I still managed to make friends, but I spent most of my time drawing, reading books, and playing video games. Nothing really out of the ordinary. I was lucky enough to grow up in a lovely and caring environment with my family and friends.
In France, students usually have two months of vacation in summer. Back in middle school, I came across this website where you could learn how to build your first website using HTML and CSS. I was so into it that I began to make all kinds of websites with friends. Around the same time, I also discovered Adobe Photoshop. Being the easily bored kid that I was, I basically rebuilt everything from scratch every week to create a new version!
At the end of high school, we had to choose what to do after. I was actually hesitating between art studies or computer science engineering, and… well, my parents weren’t too keen on letting me go to an art school, telling me that going into an engineering school was a much safer choice for my future. In the end, I don’t regret it at all since I am passionate about my work, and I still keep working on my art skills in my free time.
I went to a five-year engineering school whose strength was having a project-based approach for programming, almost always creating from scratch: a video game, an OCR, a Photoshop-like program, a chess AI… I think it’s a great way to learn something new hands-on, with a specific goal in mind. The school also provided more theoretical courses such as data structures, language theory, network architecture, project management, etc., but also non-IT related courses like economics, law, marketing, how to make an impactful presentation, etc.
The last two years, we had to specialize and I chose “Multimedia and Information Technology,” which was highly correlated to what interested me the most and fit my skills the best.
Not at all. I was also looking at the US and other European countries but in the end I chose Japan because, well, I wanted to experience something drastically different with my partner who is also a software engineer. So we just went for it, and here we are!
I came twice on vacation for a total of perhaps five weeks. I went around the main cities, following the famous Golden Route to Tokyo, Hakone, Kyoto, Osaka… but I also wanted to get off the beaten track (just a bit!), so I included Takayama, and many cities around Osaka. One city that I enjoyed a lot was Kurashiki, it was very lovely.
The time difference impacted me a little bit because joining a company remotely is complicated, especially when you’re an introvert like me, and even more so when you have an eight hour difference. So I really appreciated that my manager was very understanding of the situation and even moved some meetings so that I could attend comfortably.
SmartNews also has a “donut time” initiative on Slack, where you’re paired randomly with other people in the company and get invited to have a chat with them. That was really great because there are some people who you wouldn’t go and talk to by yourself. I had a donut time recently with two SmartNews employees: an American based in Japan and a Chinese based in the U.S. It was very nice because we had a chance to talk about things other than work. For example, we talked about keeping in touch with our respective families, what kind of messaging apps are popular in our home countries, and other things. Chats like this are like a breath of fresh air; it’s always nice to get to meet new people. I also think it helps with understanding each other. If you know people better, then you will know how they think and speak, which can reduce misunderstandings.
Another thing that was helpful was the open communication here. By remote communication, I mean being open with information sharing. I consider my manager a role model for great communication practices. He uses public channels instead of private DMs on Slack and tags us in what we need to know. This information sharing is critical for successful projects, especially when people are working remotely. Have you heard of the bus factor? It’s a risk measurement tool. The premise is this: if one of your team members got hit by a bus, would your team still be able to continue with the project? What this metaphor gets at is the risk you face if there is only one person controlling all the information.
Lastly, when I finally did get to Japan about eight months ago, the relocation agency that SmartNews put me in contact with took care of everything. They arranged someone that helped me get through the process of getting settled in.
We are responsible for the core experience of SmartNews, delivering news in a way that would interest users and reinforce the core experience. That would be the simplest definition. In the team, we have what we call squads. Currently I am in the News Feature squad. We work on providing users with relevant content.
There’s also a squad called Unified Experience. When you have multiple designers working on many different features, the experience isn’t always consistent. There are many different ways to make a feature; for example, a button can be represented in many different ways. We want to have a unified experience in terms of UI and UX, so this team handles that. It might not seem very fancy, but it’s very important.
Besides being a part of the News Feature team, I’m also part of the Android team which brings together all the Android engineers. Part of my time is dedicated to writing tech specifications for features and implementing those. I’d say that in addition to working on my news feature team tasks, I also do some code reviews on the code produced by other team members and try to bring improvements to our team methodology as well. We also do a pair-programming session every Monday morning where we basically call each other online, share our screens, and implement features together.
In my previous company, we had a much smaller team and I used to be the sole owner of the codebase. But here, the codebase is way bigger than what I was used to: it means that we all focus on the part that we have the ownership on. But, it’s also important to be able to understand the internals of how other parts of the application work as well. That way, my team members can rely on me if necessary, and I can rely on them as well.
What I think is that since I came to SmartNews, I’ve learned a lot of things from my senior colleagues. In my previous company, I was almost working alone. I didn’t have much feedback about the code I was producing. Here, though, we do a lot of code reviews. My senior colleagues are very meticulous. They set a high standard for the quality of code. I think that becoming a software engineer isn’t so difficult, but becoming a great one is. By receiving feedback from these colleagues, I can feel that the code I produce now is better than what I was writing when I first joined.
I think one of the things that is really great here is that we don’t take any comments personally. We put our ego aside. For example, even if you tell a senior engineer, “I think you can improve this part,” I think he or she will consider what you’ve said and not discard it immediately. People here have an open mind and think, “okay, let me look into it.” So we check it and modify it if necessary, and that helps us open a dialogue. And if we’re not on the same page, this gives us the opportunity to discuss it and understand what the other one is saying.
Book Recommendation
I would recommend reading Clean Code, multiple times. It’s a famous book in our field. It’s considered a must-read book among programmers. You will always come across some details that you won’t remember at first but will stay on your mind during your next reading. Of course, as for any book of that kind, you should take whatever you feel is relevant for your own case, taking into account the current state of your codebase and coding guidelines.
I first read it perhaps five years ago when I was just finishing up my internship and beginning to work. My commute was about two hours per day, and this book was on my reading list. There were times when I was able to give advice based on the book when reviewing coworkers’ pull requests.
To put it simply, writing code is good, but writing readable, well-thought and maintainable code is what makes the difference in the long term.
Clean Code: A Handbook of Agile Software Craftsmanship
Author: Robert C. Martin
Publisher: Pearson
Year published: 2008