Floating Cube Studios (Vietnam)

Floating Cube Studios (Vietnam) Floating Cube is a Singaporean company with a presence in Vietnam since 2009.

We make EPOS - a point-of- sale and business management platform with over 200 customers in Singapore including Parkway Hospitals, Paris Baguette and Nanyang Technological University.

25/07/2017

ENTRY NO. 11
THE 3 SKILL SETS
There are 3 skill sets in this industry - development, design and product.

These skills exist in every attempt to build software. They exist in Google, and Facebook, and Intuit, and small dev shops. It’s useful to recognise skills as falling into one of the three buckets, because then you know what to optimise for.

Development is the simplest to understand. Programmers write code while building software. Most of the software produced today is complex and demand coordination between different programmers, and sometimes different teams. So at the higher levels of this skill tree, development includes skills necessary to
coordinate between many programmers.

Design is also relatively easy to understand. Interfaces can be easy or difficult to use. A good interface designer is able to come up with user interaction flows that make sense to the user. Often, designers are the ones who have a first stab at a feature, because asking a programmer to design the UI for a feature is a Really Bad Idea.

Software companies hire less designers than they do developers. It’s normal to have 1 designer for a team of 5 or more programmers. Often, the configuration of teams
in software companies is one designer attached to every team. So the iOS team has one designer, and the Android team has another designer, and so on.

Some designers are able to code. The Django team built their web framework with the assumption that their designers would be able to write simple HTML and complex CSS. Other designers use tools like Sketch, due to its ability to export
assets for direct use by the developers.

At the higher levels of this skill tree, designers are able to do A/B tests, user interviews and are able to set tone via a design language, for the entire company. It’s no accident that Facebook uses the same shade of blue and the same icon style
everywhere, for instance.

The last skill set is harder to explain. It is also the rarest in Asia. “Product” is the skill set that glues together developers, designers and business concerns in a given product.

Product managers operate in between the core concerns of a product. Have you ever seen a building where the developers kept adding wings and extensions and towers, all in slightly different styles? The building eventually becomes ugly and unwieldy. The same goes for products. Product managers prevent this from happening.

It would take a whole blog post to describe what a PM does, so I’ll leave you with this one, possibly the best I’ve seen on the topic: The Product Management Triangle. Dan Schmidt does an incredible job describing the challenges and tensions of the
role, and why it’s tricky to define the PM’s workload.

The upshot of this is that you have the 3 basic roles that are directly involved with building a modern digital product. What role you’d like to take would be defined by these silos, and it should be a useful tool to evaluate the skills that you are learning today, for the job description you want tomorrow.

17/07/2017

ENTRY NO.10
DEALING WITH CHANGE IN THE IT INDUSTRY
When I first told my parents that I wanted to study computer science, my father took me aside and asked me: "Are you sure? The computer industry changes very quickly. Are you willing to keep learning new things, and throwing old things out, for the rest of your life?"

I told him I was sure I could take it; I couldn't imagine a world in which I wasn't learning new things.

I realise now that I was naive. When you grow older, you grow to have additional responsibilities. Some of us grow to take care of one's family, and many of us grow to have additional interests and obligations.

This growth doesn't hide the fact that it is true that in my father's career, he did not experience as much volatile skills change as I have already experienced in the comparatively short career that I've had. It is also true that if you're a programmer in
this industry, you will need to keep up with technological change.

Wisdom from Older Programmers
The good news is that our industry has seen a bit, and we've got leaders who are willing to share their experiences online. (I don't think the same can be said of many other industries - law or teaching or banking, for instance).

See Tim Bray, the co-creator of XML, in his reflection of his long career in software:

Should you stay technical? The bad news that it’s a lot of work. We’re a young profession and we’re still work ing out our best practices, so the ground keeps changing under you; it doesn’t get easier as the decades go by.

The good news is that it doesn’t get harder either. Once you learn to stop expecting your knowledge to stay fresh, the pace of innovation doesn’t feel to me like it’s much faster (or slower) now than it was in 1987 or 1997 or 2007. More good news: The
technology gets better. Seriously, we are so much better at building software now than we used to be in any of those other years ending in 7.

And another things that may not be obvious: It’s not a one-way door. I stepped off the technology train, spent years in start up management and technology evangelism,and climbed back into engineering life without too much pain.

It's worth it to read the rest of the article, as it's got some really good arguments for going into management, VC, startups or big companies; Bray's been in most of them, and has thoughtful comments on the rest.

Ideas not frameworks
If you accept the idea that learning compounds (as we've discussed in the second essay in this series), and that the more you learn when you're young, the easier it is to learn new things when you're older, then you must also accept the corollary: that the ideas you learn are more important than the specific technologies that are used to implement them.

Or, to use a stupid example: once you learn FOR loops in one language, then you will automatically understand FOR loops in every language that has them! The idea is more important than the language.

Similarly, this idea applies to systems as well. It has been said that "Those who do not understand Unix are condemned to reinvent it, poorly".

There is truth in the pithy saying. While technologies emerge, are hyped, and are seen to replace those that are older, in reality, very little is truly new in Computer Science.

Long before React's idea of the virtual DOM was popularised by Facebook, game programmers accepted as standard the idea of updating models and having the equivalent sprites redrawn, automatically, in a render loop.

Witness, too this essay by programming language researcher (and Aspect Programming co-creator) Crista Lopes. She laments that nothing truly new has emerged in programming languages since the 90s.

Whether this is true is not the point (Jean Yang's work on enforcing information flow policies at the language level may be truly novel, for instance) – the point is that there aren't many languages today with completely alien ideas in them.
All this implies that there is a set of ideas that one can learn, and if one learns a large enough set, one becomes more resistant to the winds of change. With this in mind, software engineering becomes less like 'throwing everything out and learning everything all over again' (as my father argued), but more like learning new iterations of old, proven ideas.

And that, hopefully, shouldn't seem very scary to you.

14/07/2017

ENTRY NO. 9
HOW TO BE A SUCCESSFUL INTERN

We’ve had a number of technical interns here in FCS over the years. Some do really well: by the end of their internships they find themselves delivering major projects directly to clients. Others don’t do as well. Here are some things we’ve noticed are common to the more successful ones.

Before we dive into these common factors, though, let’s talk a little about internships in general. What should you be looking for in an internship?

Internship Goals
The key to understanding internships is that you’re there to learn two things:

Technical skills. This is a no brainer: you’re a programmer, you take on a software engineering internship to learn real-world technical skills. The way code is written in the industry is different from school, and this is where you get to learn that difference.

Work/life exposure. The actual experience of working in a company. This is what people refer to when they say they’re looking for ‘people with job experience’: what they actually mean is that working in a job involves setting the right expectations. People expect new employees to come in with the right attitude, calibrated to the job they’re hired to do.

Most interns we meet at FCS know that they should be focusing on learning all the technical skills they can. And this might be obvious to you too. But what is interesting is that you should also be maximising your work exposure.

This is not very obvious. Some new hires we’ve seen come in with vastly different expectations. Some expect to be spoon-fed skills. Others are unhappy if they are assigned work that they aren’t interested in. An internship is the best place for you to learn what your expectations should be.

As an intern, you’re in the unique position of being able to see the inner workings of a company, without being tied to it. An internship is just a temporary job, after all. You don’t have to stay after your n months are up. This is both an disadvantage and an advantage.

The disadvantage is that sometimes, you can’t see how the whole company works because you’re the most junior person in the room. The advantage, however, is that you can compare across multiple companies (this is true if you do multiple internships). Comparing across internships is how you figure out what kind of company you would like to work for in your career.

(I strongly urge you to consider doing at least 2 internships – one at a big company, and one at a small company during your university life. Find a way to make it happen.)

While you’re at the internship, take the time to learn everything you can about the company. How does it make its money? Who are the best engineers? What is the leadership like? What weaknesses do you notice about this company, and how might you make it better if you were in a position of power? How are conflicts resolved, and how are engineering decisions made?

Talk to your manager, and make friends with the seniors above you.

These seem like irrelevant questions, but they turn out to be very important in your career. Knowing how a company makes its money teaches you to see if you’re in a profit-centre or a cost-centre. It also tells you what the most valuable jobs look like in other, similar companies.

Company weaknesses are even more important to notice: they might not be a deal-breaker to you right now as an intern, but if the full-timers in your company are quitting because of something, then you know what to watch out for it in the future companies you apply to.

3 months is long enough to pick up on a broad set of experiences, if you’re willing to put in the time and listen. Ask the full-timers what career and life decisions they’ve made, and then decide for yourself if you want to make the same decisions in your life.

Now let’s look at some qualities the best interns seem to share:

1. Knowing when to ask questions
This is tricky. One of the most annoying traits a junior employee can have is the tendency to keep asking questions about the most basic things. This is annoying because you begin to waste the time of senior employees, whose time is more valuable than yours.

As a junior employee, you do want to be effective, and it is true that you know less than your seniors. So what’s the right balance between asking for help and struggling with your problems by yourself?

I have two ideas that may help:

The first idea is to ask questions according to the following template: “I have a problem with X. I have tried A, B and C, but it doesn’t work. Instead, when I tried A I got bad result P, when I tried B I got bad result Q, and when I tried C I got weird result R.”

Until you are able to give a list of approaches that you’ve tried and failed, don’t ask a senior.

The second idea is to time box stuff you don’t understand. Need to implement a feature and don’t have any idea how to do it? Give yourself X minutes, set a timer, and then at the end of those X minutes ask a senior.

The first idea forces you to make sufficient effort, and the second idea prevents you from wasting too much time when some guidance may be useful.

2. Ask for regular reviews
Internships are a great opportunity to get real industry experience. To maximise this opportunity, maximise the feedback you get.

If your company has some form of monthly managerial review, that’s great. But even if you do have these reviews, given the limited amount of time you have at a company, it’s probably a good idea to get informal reviews from seniors at a higher frequency than just monthly.

These reviews could be as simple as “hey, could we have a quick chat about that project I worked on this week?” with your primary manager. And if you’ve collaborated with seniors from other teams, it might make sense to approach them for some feedback at the end of the week, or the end of the collaboration as well.

3. Work harder than a full-timer
Now, before I begin on this, let me say up front that work/life balance is important to get right in your life. Work/life balance is so important to the rest of your career, in fact, that I urge you to figure out your limit as an intern, instead of figuring it out while you’re a full-timer.

What do I mean by this? Well, the stakes for burnout are much lower as an intern than as a full-timer. Internships are book-ended by academic semesters, because you get to go back to school after an internship is over. And internships are good places to level up, seeing as you have a clear amount of time, and clear goals to achieve. Pushing yourself to get to those goals within the set timeframe is an obvious thing to do.

This is probably going to be controversial, but I recommend using your internship as an opportunity to figure out where your limits are, so you know when to stop when you’re finally working as a full-timer. Work late into the night, try one or two all-nighters, and most importantly, notice when you become resentful about the work you’re doing.

Resentment is the best signal I know that burnout is on the horizon. If you feel it, you know that burnout isn’t far away. And you’ll have learnt something important about yourself, I think, something you won’t have to learn the hard way when you’re working full time at a job.NN

11/07/2017

ENTRY NO. 8
SMALL BUT EFFECTIVE

This short document will outline some skills and attitudes that would help you with your engineering career at Floating Cube. Engineers receive this document during orientation.
Floating Cube is a small company, and will likely remain small compared to other companies for some time. As of 2016 we are dedicated to building a small but effective team of engineers, who will be building up the foundation of all our future products. Notice what’s not in that sentence: it doesn’t say professional, or perfect. We don’t care that you wear nice clothes to the office. It instead says small and effective. Let’s talk about what this means.

Small teams allow individual engineers to make a large impact on the company. Being small also means being exposed to a lot of technologies and aspects of the business, and having the opportunity to build for the future.

Effective teams demand ability to execute. We care about how well you contribute to or accelerate the development of the rest of us. In return, we will take your growth seriously, and help you perform better for our benefit. By the time your time with us is up, our aim is that you will be able to leave at a higher level than when you came to us.

Here are some skills that would help you during your tenure here:

Debugging ability
Many things will break as Floating Cube grows. This includes code, modules during deployments, or processes (aka the way we do things) as we scale our company up. Your job as an engineer will include recognising when things are broken and pointing it out to us with the aim of fixing things.

Fearlessness to dive into something you don’t know
Being part of a small team means that you will get to grow faster. How this actually happens is that you’ll be exposed to other aspects of building product that most engineers in a larger company won’t. To experience this, you must be fearless to dive into things you don’t know.

Don’t be afraid to modify 3rd party software. Don’t be afraid to dive into your teammate’s code to fix something for a client. Don’t be afraid to call a client to ask for more information, or debug his problem, or even visit his shop in Singapore to see how your software runs. All these things will make you better at building product.

A pragmatic approach to decision making
It’s nice to sit down and talk about best practices, or the ideal ways to do development. But in a small organisation, pressing technical or business problems exist today. This may sometimes mean doing non-optimal technical, process, or people-related things.

A useful rule to use is to ask yourself “what action will increase the probability that the whole team succeeds?” when facing one of these decisions. Know when to get things done, but know also when to push back to make things better. Pick your battles for the benefit of the team.

A tool building mindset
By definition, a small but effective team means that we have to increase the productivity of every member of the team. Building tools is an engineer’s solution to get more done with the same number of people. Do your work with an eye towards automation, or streamlining processes to make everyone’s lives easier.

A strong generalist mindset
Floating Cube is at the stage where we’re building many new platforms for our future products. This may include using a new programming language, operating system, or framework tomorrow. All our engineers are expected to be able to pick up new things on the go. (We think this is the right attitude towards a career in our industry, anyway). Be prepared to move to a new platform tomorrow.

Be a player, not a victim
There are two responses to every event: we can either be victims and blame any problem (a slipped project deadline, a product launch that flops, or conflicts with teammates) as being due to external circumstances. Or, we can be players, and identify the aspects that are within our sphere of influence and focus our energy and efforts toward what we can actually affect and fix. Do the latter. Be a player. =)

Grit, combined with a willingness to learn and introspect
Grit is the ability to keep at something over a long period of time. Applying grit to self improvement will benefit everyone at the company, but most importantly yourself.

Floating Cube does reviews once every month. Use these sessions to reflect on the challenges you’ve faced in the past month. Focus on what you’ve learnt on your job, and what you’ve learnt about yourself while meeting your challenges. Then work with your manager on what you’d like to aim for in the coming month.

06/07/2017

ENTRY NO. 7
THE VALUE OF SIDE PROJECTS

When doing recruiting for Floating Cube Studios, I’ve found it rare to find students who have had side projects. Most of the candidates I’ve interviewed have only shown me school projects. I’m not completely sure why that is.

One possible reason could be that the university holidays here in Vietnam aren’t that long. Another could be that many students take on part-time jobs during the semester and during the school breaks – often, these roles aren’t technical. Students wait tables and help out in shops instead of taking on programming-related jobs.

And yet, when it comes to finding a software engineering job, successful, well executed side projects are often the easiest way to measure a programmer’s ability.

Even the very fact that you have side projects sends a signal to a potential employer that you at least like programming.

I want to argue that building side projects is the single most value-added activity a young programmer can be doing. These projects are even more helpful for those who get bad grades in school, yet still want to work in software engineering.

Here’s why.

Side projects indicate interest and motivation. You don’t come back from school and code on a side project if you aren’t self motivated. Side projects that you build out of interest tells me, as an employer, that you’re interested in problems outside of school. And if the project is successfully completed, it tells me that you have enough self motivation to see something through to the end. These are incredible skills that are valued in any programming role.

A portfolio of side projects also indicates exposure to external technology. The very best IT schools don’t teach specific technologies or tools. They instead teach the basics of programming and app development, and trust that the student will be able to go out and learn the rest on his or her own. This makes absolute sense: no university can constantly keep up with the latest developments in software engineering! Side projects are the easiest, if not the best way to learn cutting-edge development practices.

Side projects provide a good way of measuring skill. Why do companies hire people with good grades? Well, one reason is that grades are a way of measuring your ability. Companies think that candidates with good grades will translate to programmers who have good skill. However, in IT we can measure your skill directly: by reading your code! At FCS, we don’t look at grades so much. We read the candidate’s code, and listen to him or her speak about it. Students with bad grades can get hired in IT if they show they can write good code.

In fact, this last point has an even stranger conclusion: if you don’t have a degree from a University, or you graduated with a non-IT degree but can code, apply to software firms. You’re likely to get a job anyway.

It’s important to recognise that this is a huge advantage in our field. The ability to measure future performance directly, instead of using grades, means that anyone can become a software engineer. It also means the best way to become a good programmer is to program, not to take tests!

How do you get started?
There are many free books and resources related to learning new programming languages or frameworks. But it’s important to not spend too much time reading them (without actual coding).

The best way to get started on a side project is to find an interesting problem to solve. Ideally, your first problem should not require a solution that is too complicated to build.

I still remember the first side project I built: I had a friend in university who had a problem with parking in his university. Every once a month, the students at his school were required to sign into the university website and apply for a parking slot. This service was a first-come-first-serve basis: the first 200 people who submitted their details after 8am on the 1st day of the month got the parking space. So, on the 1st of every month, hundreds of students would camp by their computers, refreshing the page repeatedly for the button to appear.

I was in my first semester of university, and I had just learnt programming. I thought I could help him by writing a script to do everything automatically for him. The script could then loop repeatedly until it has succeeded in booking a parking slot.

As it turns out, this was a very useful project to do. As an excuse, I chose to learn the Python programming language, and then to learn to set it up with cron on a CentOS server I had just bought. It took me many painful hours, but I eventually got it to work.

Today, Python is my favourite programming language. And my friend never went without a parking slot for his entire university life.

A few other things that may help:

Use IRC when you are stuck and need help. If Google fails, and repeatedly banging your head against the wall doesn’t work, log in to freenode and go to the language channel to ask for help (e.g. if you are programming PHP, if you are building something in Django, and so on).
If that fails, use StackOverflow!
Last, but not least: here is a list of free books you can use to start your learning.

Happy hacking!

05/07/2017

Entry No. 6
LEARNING MANY FRAMEWORKS VS SPECIALISING IN ONE
One of the most surprising things I’ve learnt about software engineers in Saigon is that many want to specialise in just one programming language or platform.

This is surprising to me because this attitude isn’t as common in Singapore. Software engineers in Singapore would at least say that learning new things is a good thing, even if they don’t really practice it.

But some Vietnamese engineers that I’ve spoken to have told me that they think learning new things – especially new things outside their circle of competence – is bad!

Some of them tell me that this is old Vietnamese wisdom: that if you specialise in more than one skill, you won’t be a master in any of them. Some tell me that their professors in University teach them to do this. And I am not the only one to have experienced this attitude: other software project managers have confirmed seeing this opinion in Saigon.

The net result is that I’ve met Vietnamese engineers who refuse to code in or learn platforms that are outside their selected speciality. For instance, Android engineers who refuse to touch iOS, or PHP engineers who refuse to write backends in any other language.

So which should you pick? Should you stick to one framework, or be the generalist that does all?

The answer to this isn’t that simple. It’s not true that one is good and the other bad. The real answer is this: whichever you pick, ensure your ability to learn new things does not disappear.

Learning is Painful
My main worry whenever I hear a Vietnamese engineer tell me that they don’t want to learn a new platform is that they’d forget how painful it is to learn something completely new.

This may sound strange if you’re fresh out of university, or currently an IT student. “Learning isn’t that painful!” you might say, “It’s normal!”

But give it a few years. Once you’ve spent 10 years, for example, getting good at iOS or PHP, you’ll find that learning something completely new can be very painful, especially in comparison to coding in a framework or language that you’re already an expert in.

This is especially dangerous in our industry, where things change quickly. Maybe today you’re a well-paid, valuable Android engineer. But if over the course of the next 5 years Android dies, or if Google decides to switch Android to a completely new language, you’ll be forced to learn something new or risk being unemployable.

Let’s be clear: the risk isn’t that you’ll suddenly get fired. The risk is that you’ll slowly get stuck in a company, never being promoted, and then when you’re finally let go you find that getting a job is suddenly a lot more difficult.

The flip side of this is that engineers who can learn quickly are often regarded as more valuable than engineers who can only do one thing. Companies like Google, for instance, never hire software engineers based purely on programming language skill: instead, they test programmers on algorithms and problem solving ability. Their reasoning? If you’re smart enough to pass an algorithms interview, you’re smart enough to pick up whatever language you’ll need to pick up at Google. More importantly, you’ll be smart enough to keep learning new languages as the company’s needs change.

But Learning Takes Time
There is, however, a flip side to this. It is true that constantly learning the shiniest new thing will come at the cost of being very good at one platform. You cannot become a master of one thing if you are dividing your time to learn many new things.

Also, I’ve met senior engineers in Vietnam who tell me that their families are more important to them. They don’t have that much time to learn new things, so why not spend it on getting good at the one thing that they already know and use? This is also true.

The truth is that both concerns are valid. This is why my argument isn’t to pick learning many things vs learning just one thing, but to ensure your ability to learn new things does not disappear. So long as you keep some base level of learning around, you’ll do fine regardless of which view you take.

28/06/2017

Entry No. 5
PROFIT CENTRES VS COST CENTRES
Profit centres vs cost centres is something I wish someone had told me earlier in my career.

This idea applies to just about any job you do, no matter what industry you’re in. It is a powerful way of looking at your work, and figuring out how good the job would be for your career in the long run.

Here’s how it works:

There are two kinds of places you can work in:

You can be working in a profit centre, or
You can be working in a cost centre

A profit centre is a job that makes money for the company. For example, if you’re working in a bank, the bankers are the profit centres – they’re where the bank makes most of its money. If you’re working for a tech company, the programmers are the profit centres. If you’re working for an accounting firm, the accountants are the profit centres. You get the idea.

Companies also have cost centres. These are places in the company that are regarded as the cost of doing business. So for instance, in a company like Google, the finance department and legal department are regarded as cost centres. They’re not directly tied to how Google makes its millions and millions of dollars each year; instead they are regarded as people you have to pay in order to get business done. On the other hand, banks regard their IT departments as cost centres. The bankers make all the money while the programmers are a cost of modern banking.

Here’s what this means for you: all things being equal, work for a profit centre, not a cost centre.

1) If you are in a profit centre, the company will regard you as one of the most important parts of the company. After all, how well you perform is linked directly to how much profits it gains!

2) Therefore the company is highly motivated to invest in you. People working in profit centres enjoy lots of invisible benefits: the company will spend more on them, will train them better, will work hard to keep them. On top of that, companies will try and recruit the best people to work in their profit centres, which means that your fellow colleagues, your managers, and their bosses are likely to be really good people you can learn from.

3) New projects that you want to push are more likely to be approved. You will have more freedom to start new initiatives. And so on so forth.

On the other hand, if you are working in a cost centre, you’re likely to suffer from a lack of invisible benefits. New initiatives are harder to push through, your colleagues won’t be as heavily recruited, and the company won’t work so hard to keep you.

This idea explains a lot about job and salary types. It explains why salespeople tend to be amongst the highest paid regardless of industry – because the sales force is directly linked to how much money a company makes. It also explains why programmers in Google enjoy more benefits than programmers in large banks.

Notice that the ‘profit centre vs cost centre’ argument does not say anything about how much you’re paid. If you are a lawyer in the legal department of a large company, you would probably be paid just as well as if you were working in a law firm. But you will learn less.

One last note: this idea also means that sometimes, the best way to get what you want is to position yourself as a profit centre to your boss, as opposed to a cost centre. Internal company politics are built around appearances. If you are in a cost centre, your best strategy is to sell yourself as a profit centre.

It can be entirely possible that an IT department is regarded as a profit centre inside a bank, if the head of the department knows how to sell his team as important to the bank’s long term goals (or if the CEO thinks IT is important).

Here’s a real world example: working in AIA’s IT team in Singapore is pretty good, because the current AIA CEO believes technology will be a huge competitive advantage for its business. The current team is paid well, and given quite a bit of freedom to innovate.

All things being equal, work for a profit centre, not a cost centre.

Address

Ho Chi Minh City

Opening Hours

Monday 09:00 - 18:00
Tuesday 09:00 - 18:00
Wednesday 09:00 - 18:00
Thursday 09:00 - 18:00
Friday 09:00 - 18:00

Telephone

+84866819510

Website

Alerts

Be the first to know and let us send you an email when Floating Cube Studios (Vietnam) posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The Business

Send a message to Floating Cube Studios (Vietnam):

Shortcuts

Share

Category