Category Archives: Career

Experience, bad and good

Just congratulated my 26th birthday. I have got 6 years of working experience under my belt, but now I always have a big question: Am I 6 years more experience than my 20 years old, or just 1 year of experience repeated 5 times. And do I have a 6 years of shit assumption, bad software, customer and internal development practice. Sometimes, it is hard to tell huh :) ) A reflection of what I became after 6 years is truly crucial. When I was in university, I saw myself as a software architecture or a computer science researcher. However, working my first job opens my eyes about the startup world, the comfort zone, the up and down of a software startup. This, together with the realization that I am not a good fit for an academic research role, changes my career path. It shows an important lesson for me that it would always be good to set out a plan, try your best and willing to adapt or change to a new environment for a new challenge

The good thing about the IT career is that it is always changing fast.  Experience can become old, like my iOS 3 and 4 experience would not be used any more. Even experience with iOS5 and 6 can become obsolete soon. New thing like Swift can change the landscape fast.

Unfortunately, it can become hard for me when I need to manage people or develop a program. It might be a lot easier for me to give a clear guidance to others based on my old experience and people will just follow and do that quickly. But then, they won’t be able to find out a new way of doing that thing. People surprised me all the time about their different way of thinking, which reminds me to be humble and patient to listen to their idea

The Generalist and Specialist Approach

Learning is a lifelong and continuous process in anyone’s career. A common question from the newbie and the college students is what areas they should focus their efforts on to move fast. I share the same feeling with their ambition to go fast and change the world. However, in my opinion, the first few years of college and career should be on learning their most favourite subjects. It is fine to not earn much money at first as long as you are building up your background.

Choosing the first job

Some people would claim that the first internship and job is the most crucial one in his career. This was far from the truth. A career is a 40-50 year (yes, they are extending retirement age to 70) marathon which allows you to make a few mistakes here and there and still achieve the greatness. The key strategy is to always move forward, always expand beyond your comfort zone. I would encourage new students to try different career paths if they are still unsure about what they want: the startup life, the small and medium enterprise and the multinational companies. These offer different skills and experience to people.

The learning curve

To learn some fundamental concepts about a new topic does not take much amount of time.  The pareto principle (The Pareto Principle states that 80% of outcomes come from 20% of causes.) on learning new concept would say you will understand and know 80% of a subject by spending 20% of the time. This part of 80% will not qualify you as a great specialist in the area, but it is enough for you to apply it in your current speciality.

A good example would be that a developer learns about UI/UX development. The first few hundreds of hours of learning and applying it will not make him a UX specialist, but that would be enough for him to apply it into his software development. This will guarantee that the UI/UX of his app/website would be at least at an acceptable level.

Work to learn or work to earn money?

A very important concept for newbie is to know their value, or to put a dollar amount into his work. The one who would say he can work for me for free will not make me impressed. The one who would say that his salary would be a specific amount of A $ because of these reasons, will be the one I feel good about. He would show me that he spends a significant amount of time to research about different companies, about my company to know how much his contribution is worth. He would still have to seek for learning and improving himself over the future period of time, and it would be good for him to show me that plan and how he would stick to it.

The altitude is always valuable for most employers, but you better show that you have the knowledge and skills to make that altitude become valuable.

Dealing with customers

Written Contract

Written Contract

Dealing with customers is always a hard topic. This blog post will not summarise some of my experience before working for my current company. Communication with customers require both art and discipline to make sure that nothing could possibly go wrong. Here is a quick list of errors I have been making throughout my working life. :

Not thinking through each of the small details the customers may want to add later.

For example, if the customers want his websites to work on mobile device, it would be wrong to assume that he meant iPhone. 

- Don’t have a specific, fixed requirement document.

It could go wrong if both sides did not agree on a specific set of requirement before the project starts. I think I may need to understand more about Agile development

- Agree on a verbal basic: this is one of the hard lesson that I learnt when working outsourcing. Everything needs to be at least written and agreed on the email and not just chat or voice call.

Not thinking through small details

This is what is hard with software estimation when all the devils are in the details. When customers say they want their app to work on iphone, they really think of all iphone versions, and they probably assume that it works on android as well unless you tell them. It is good to be clear upfront and think through all cases.

Another example is that customer do not understand how important security is, and they just want it to work. But while they are testing, they may find the security issue and blame us all for bad practice of coding and testing.

Don’t have a specific, fixed requirement document.

Customers may want us to change the graphics 2 to 3 times and that are lots of back and froth emails and demonstration with the client. It will also extend the deadline of the project as we may need to wait for them most of the time.

Agree on a verbal basic

Everything should be at least in a written form. This was the key lesson I learnt during the early days of doing business. Everything needs to be agreed again over email. Even if you trust someone, or have a good memory, it is important to remind both of us what we said. It could be as simple as the client wanted to change the graphics and then later on, they completely forgot. It would be troublesome if clients wanted to change the requirement, then to extend deadline and the budget but they regretted it later. A written document would be helpful, or at least an email. I am not a lawyer but I found this book (22 Legal Mistakes you don’t need to make) helpful for new people.

When you write something down and let the other side read through it once, you can confirm that both sides share the same idea and clear all the miscommunication. This proves to be effective when you work on project requirement.

What is your tip? Please share it in the comment.

 

Time Management for Software Project

Time, quality and cost

 The basic of project management is a balance between time, quality and cost. Pick 2 of them. And then we start discussing about how to estimate the time when we have fixed the quality and cost (just kidding, you can pick quality and time as well).

 

Time Cost Quality

Time Cost Quality – Pick 2

 In projects I have done over last 5 years, each always contains lots of unknown and challenges, as I have worked in most of the latest technology and sometimes I come to new project without any experience

 Main problems in estimating projects can be listed as below:

   - Miscommunication

   - Overestimate the team competency

   - Task breakdown not done carefully.

   - Underestimate integration between models

   - Technical unknown

   - Requirement changes

Miscommunication

This normally happens with outsourcing companies or when teams are spread between different locations. When I chat with clients or teammates, people are lazy to chat so they tend to chat short. It leads to lots of assumptions and miscommunications between people. Voice chat on skype suck energy really fast, and require both sides to communicate synchronously. It could be the miscommunication between clients and your teams or inside your team. You definitely don’t want after 3 months, you come back and the clients’ feeling is like the figure below….

Miscommunication

Well, a famous and familiar figure huh?

Overestimate team competency

I pick my team members really hard, and I also have strong belief in my people. That is why I overestimate my team member most of the time. Belief and overestimate should be separated from each other. “Keep a cold mind and a warm heart”. That means you should keep a strong feeling in your members and encourage them to do a good work, but when evaluate them for specific project, be careful to estimate.

Task breakdown & integration

These are the 2 most underestimated when managing any projects. It is easy to look at the whole and say that it would take 3 days to finish all of them. However, if you actually break it down, and allow time for writing the code, debugging, testing and fixing bugs again,the total time could be 10 days. Oh, I forgot to mention about integrating between tasks or modules. Sometimes, we assume that if task A is done, and task B is done, combining them would be easy. Poor us, it is not usually the case. The combination between module A and module B can generate a whole new level of bugs that need fixing. The bug may only happen due to specific conditions of module A and B. It is important to run lots of tests and allocate debugging time for this phase, as shown in the following figure.

Work Breadown Structure

Work Breadown Structure

Technical Unknown

The risk level of the project depends on how many unknown stuff in your project. Some of them is that the requirement is unclear, or the technical solution is not yet known or implemented by any people in the team. It requires an expert with sharp eye to know which areas are unknown and needs to allocate time for it. The problem is people don’t know what is unknown…

One cool example that strikes me a lot is how Video Player is implemented in iOS and Android. In iOS, seeking to any arbitrary frame is a piece of cake, and I assume a well-designed framework like Android would be the same. I was totally wrong. It took me 2 months to search through many different solutions and approaches to figure how to do it in the correct way.

Only when you really get into coding, you can really know which part is challenging.

How to deal with changes

Another problem is customer change their requirement based on what you demonstrate them. An Agile approach normally helps by clearing any customers’ assumptions as soon as possible and not let them wait until the finished product. By receiving early feedback, we can constantly change the products.
HOWEVER…

1 problem of the Agile approach is that customers keep changing their minds way too often. There is 1 point that we really need to lock the requirement no matter what the customers want. Striking a balance between these issues may keep customers happy and our project budget and timeline in a good shape.

It is never too late for you

 


Just read this fantastic post on Quora feeling that I might have some further thoughts about it. I have seen many people obsessing about getting things right at the first time, and if they cannot, they think things are too late. However, what I see is that chances and opportunities are almost everywhere and after every couple of years, those chances and opportunities will come back.

Should I switch what I am doing?

I was once asked by my friend, a developer, if he should switch to Business Analysis or not. He feels like it more than programming but if he tries it and he does not fit it, he would waste 2 years of his career. And this kind of switching is raised a lot by my friends and other people. “Should I switch from a big company to work for startup/startup by myself?”, “Should I switch and try doing this/that?”, “My first job/internship was terrible, it would affect my career…”. The answer is you should not worry.

Any Experience Counts

Any experience that you learn, either from a big company, from a small company, from another job or career would bring you a unique point of view into the new career. If you work as sale and now want to move to programming, your sale knowledge is unique, 90% of programmers I know have no knowledge in sales. Understanding sales and customer would bring you a competitive advantage that most don’t have. And vice versa, if you work as programmer before and switch to be business analysis, you really understand the programming work, you understand the technical difficulties and you can help the customers and programmers to talk better. Any experience counts, any unique experience counts twice.

Why knowledge/skill costs a lot?

Yesterday, I have just done a very good job. It is very good because I spent almost a year keep thinking and trying to solve the problem but I couldn’t really solve much. However, the solution yesterday was so easy and short that I was shocked. It reminds me of the following story:

1 guy with a car broken going into a gargage. The repairer asks him for 100$ and it took him the whole day to fix the car. However, the car gets broken again after just a few days. The owner was so disappointed and tried with a new repairer. This new repairer, an elder, just took a quick look at the car and blow the hammer 3 times into some specific place. He then charged the owner 500$. This time, the owner was shocked, “How can I pay you 500$ for just 3 hammer blows?”. “1$ for 1 hammer blow and 497$ for me to know where to do so”.

It just shows me how much matter the knowledge, the thinking through the problem matters, not how much the efforts. Of course, experience and knowledge comes after efforts, but always think before doing

Why not join with a startup idea?

Idea vs Execution

Idea vs Execution

Just found a brillian post, says all I need to say for most of my friends or people. And a good advice to people, please think through and not so disappointed if some developer does not want to go with your idea. The #1 item is the most important thing, imo:

  • Ideas are easy, execution is hard.
  • People approaching developers often dramatically underestimate the amount of development work, or the complexity of it.
  • Proposing a revenue share means the developer has to take as much risk as the idea guy (for very low pay, given the point above), and trust that the business will receive the right amount of marketing/sales follow-through.
  • There’s an opportunity cost to working on someone else’s idea instead of for paying clients.
  • The idea being proposed is often very unrealistic (and the developer, having worked on a number of such ideas, can tell).
  • Developers have their own ideas to work in anyway.

iPhone v.s Android

The smartphone game is over. The tablet game will be finished soon, within 2 years.

iPhone versus Android

iPhone versus Android

 

 

Android wins, iPhone loses. 75% v.s 15%, soon will become 85% v.s 5%. But that doesn’t matter much for Apple. Apple is a brand for high-end products. They don’t aim to gain all market share. To gain market share, Apple has to attack more of the low-end market, which means they have to lower their price. However, matching other supplier’s price may be harmful for Apple’s brand, although they may achieve it by more efficient supply chain and factories.  To become a high-end brand, Apple spends a significant amount of money on their brand and will not scarify it for the market share.

But in this ecosystem war, the bigger ecosystem leads to a win by monopoly. When 75, 80 or 85% of the market is using Android, app developers will flock to there, and make the ecosystem become much more valuable for customer. To continue earning a lot of money, Apple has to continue what it has done best under Steve Jobs’s empire. New product, new market, new value, or new software that people are willing to purchase with high-price.

What will be the next Apple’s product? Probably Apple TV, I am not even sure about that.

And the important questions for most of us, as app developers, what should we do? Should we all move to Android yet, should we change our strategy of iOS first, Android second? Or should we start discussing about Mobile Web App?

I am writing more on the Mobile Web App v.s Mobile Native App in the next post, catch it soon.

Communication problems between distanced members

Misunderstanding

Lacking communication….

If money is your startup’s problem, you should open a branch to outsource some development work into cheaper countries, like Vietnam. Then, you would exchange 1 problem with another, probably harder than you thought.

Communication: this is a key. Effective, efficient, going into the right way. In startups, there are much less time for documentation. Things have to go really fast, features after features, products after products. It is much better for startups to go fast, try with different ideas until they get it correctly. And when they get the idea correctly, it is time to execute, as fast as possible to get the products into the market. Distance difference is a main barrier for communication, talking over Skype feels very different from talking face-to-face. Another barrier is time difference.

The time difference between Vietnam and America is huge, 10-15 hours time difference. When the Vietnamese developer wakes up, their colleague sleep, and vice versa. I have seen some approaches to this problem: scheduling out some fixed time in the day or week, to meet, or someone has to sacrifice. The first one is not normally working for startup when lots of communication needs to happen. The second one will not last for long.

Competitive Advantage – how to make it last

In the last 2-3 years, iPhone development has been my advantage when I stepped into the area early. It brings me many good results. But, that’s over. You hear it correctly. I don’t mean iPhone development will decline, but the growth of the market is significantly slowed down. And the number of good developers in this area will significantly grow when more resources are available.

Long-Lasting Success Requires Non-Ending Efforts

Competitive Advantage

Competitive Advantage

To be successful, a company or a person has to get some competitive advantage. The problem is sooner or later, every other companies/people will improve themselves to gain your competitive advantage. It may take them 3-5 years, but in this technical world, it would be even less. This advantage can never generate a long term plan. No matter how you protect it, no matter what cost you pay to protect it, people will soon be leveling your advantage. Don’t dream and don’t sleep on the victory. Long term and scalable model requires lots of building efforts to generate more competitive advantages.

I have never tried to protect my knowledge about iPhone development because I know the market controls itself. I see enough of stupid people trying to protect their knowledge to gain advantage in company promotion.

To be successful in long term, the same for personal or company, you need to build a culture that motivates new innovation, i.e creating new values. These new values, new knowledge or new understanding will bring you more competitive advantages or guarantee with you a long term success