Are you in a software development team with less than ten members? Less than five members? Just three, including you?
In a small sized team, priorities and responsibilities may start getting mixed up, where each member can generally take the place of another. This is fine, and there’s an additional condition. Each member must also be extremely well-versed in an area of the team’s responsibilities.
For example, in a team of three, one member (usually the team leader) takes on documentation, business logic and the overall big picture. One member takes on the back end process flow, making sure the backbone of the project is running smoothly. And the last member takes on the front end application design.
Why is this segregation important? Let me contrast this with a larger sized team first. With more people, a task may be assigned to several people, and the collective knowledge of this group is used to solve the task. Any team member can also more or less take on roles and responsibilities of another team member in this smaller group.
As the team size gets smaller, this collective knowledge and role flexibility shrinks. When you’re dealing with a small team, every member counts. Each member has to be an expert in their own circle of responsibility, or the effectiveness of the team suffers. Treating each member in this situation like a plug-and-play component is a disaster waiting to happen.
So how can you help yourself? Learn to say no. Multitasking with other team members’ responsibilities is the fastest way to drain your energy and compromise your own output quality. In the event that you have to take on another person’s tasks (say the person’s on leave), then prioritise. Find the tasks that helps the team most, and then do those, even if they aren’t originally your responsibility. This way, the team moves forward, the project gets closer to completion, and the users are happier with the support.
If you can, get good help. Even one or two more team members can help the overall effectiveness of the team (try these for some hiring arguments). This is different from adding people to projects to make them go faster. What you want the additional members to do is alleviate some of the independent tasks off the existing members. Then slowly spread out tasks more evenly amongst the team members.




I was looking at the title Japanese characters of Super Mario Brothers, and then I had an epiphany. I could match Japanese characters to English alphabets! I started with the Japanese character “su” and matched it to anything that had an “s” based English phonetic pronunciation. Then I moved to add in other matches. Slowly I built up a Japanese vocabulary that was based in part on curiosity and in part based on an urgent need (I needed to understand what I’m playing!)
Why would being able to read katakana be so useful? Because katakana is mainly used for foreign (as in non-Japanese) words, usually English. And there were enough of words used in role playing games that had foreign origins. Like battle menus.
I just read an 


I'm a mathematician, programmer, writer, 





