Business

Gaji programmer di Indonesia rendah, kok bisa?

Latar belakang

Selama saya beraktifitas dalam komunitas programmer dan berdiskusi dengan programmer2 lain, banyak muncul pertanyaan mengapa gaji programmer di Indonesia tergolong rendah bila dibandingkan dengan negara-negara lain. Saya pernah memberi beberapa jawaban yang kira-kira mampu menggambarkan sebab-akibat rendahnya gaji programmer di Indonesia. Pada kesempatan kali ini, saya mencoba merangkumnya dalam sebuah tullisan artikel dengan harapan lebih banyak orang yang dapat melihatnya dan mempermudah saya menjelaskan topik ini berulang kali.

Gaji programmer

Periode saat saya mulai berkarir di dunia pemograman adalah sekitar awal 2012. Saat itu kisaran gaji programmer entry level adalah di 3 juta rupiah hingga 4 juta rupiah. Saat ini di awal 2016, kisaran gaji programmer entry level juga tidak jauh berubah, sekitar di kisaran 4 juta rupiah.

Nilai ini tergolong rendah bila dibandingkan dengan negara2 tetangga seperti singapura dan malaysia. Apalagi dengan banyaknya berita tentang hebatnya jadi programmer dan beberapa kisah programmer yang sukses membuat kita merasa tingkatan gaji programmer di Indonesia tergolong rendah. Benarkah begitu?

Nilai tukar rupiah dan nilai biaya hidup

Salah satu penyebab rendahnya gaji programmer bila dibandingkan dengan negara-negara lain di level setingkat adalah karena rendahnya nilai tukar rupiah dibandingkan dengan mata uang asing. Selain itu, rendahnya nilai biaya hidup di Indonesia membuat perusahaan-perusahaan tidak terdesak untuk meningkatkan gaji programmer.

Masih dianutnya konsep tradisional career ladder di perusahaan

Career ladder yang masih dianut di Indonesia adalah yang masih bersifat tradisional. Jenjang karir tersebut berarti setelah diawali dari junior programmer, dilanjutkan dengan senior programmer dan masuk ke jenjang managerial. Sementara konsep career ladder modern memungkinkan seorang programmer untuk naik ke jenjang berikutnya sebagai spesialis (technical) dan professional, salah satunya sebagai enterprise architect.

Konsep tradisional ini membuat stereotype bahwa gaji manajemen / project manager lebih tinggi dari programmer, dan gaji programmer sekali lagi terlihat rendah.

Supply and demand

Bila kita teliti lagi, gaji-gaji tinggi programmer di luar negeri dikarenakan kebutuhan akan skill programming yang juga tinggi dan tanggung jawab yang juga tinggi. Katakan Microsoft, Google, Facebook dan juga Wordpress (promosi terselubung) memerlukan programmer dengan skill yang tinggi dan tanggung jawab yang besar. Di samping itu, perusahaan2 tersebut juga adalah perusahaan IT yang bersifat sebagai provider / enabler, yang mana pendapatannya lebih tinggi dan service-nya lebih diminati.

Berbeda dengan kondisi di Indonesia. Hinga tahun 2010, mayoritas programmer diperlukan untuk men-develop custom application di software house atau internal perusahaan. Programmer2 tersebut masih menggunakan teknologi yang di-provide oleh perusahaan2 dari luar negeri seperi microsoft, SAP, atau wordpress. Dan sistem yang dikembangkan sebagian besar hanya bersifat CRUD atau administration screen.

Sejak tahun 2010, banyak startup-startup digital muncul di Indonesia. Kebutuhan akan programmer dengan skill lebih tinggi meningkat. Namun tetap saja peningkatan tersebut belum maksimal karena Indonesia masih belum mencetak produk-produk digital yang bisa digunakan secara internasional. Dan juga, demand untuk embedded programming dan robotik juga masih rendah, membuat kisaran gaji programmer juga ikut rendah.

Stereotype bahwa skill programmer Indonesia rendah

Masih berkaitan dengan supply and demand, rendahnya demand untuk programmer dengan skill tinggi membuat programmer2 dengan skill yang tinggi untuk mencari pekerjaan di luar negeri. Pencarian kerja di luar negeri dilakukan dengan harapan untuk mendapatkan gaji yang lebih tinggi dari kisaran gaji-gaji di Indonesia.

Kondisi tersebut mengakibatkan munculnya pandangan bahwa programmer-programmer di Indonesia memiliki skill yang lebih rendah dari programmer-programmer dari luar negeri. Maka saat startup-startup / perusahaan baru ingin menempatkan programmer di posisi strategis, maka dipilihlah mereka-mereka yang berasal dari luar.

Sulit menilai programmer dengan skill tinggi

Dari kacamata non-teknis, sulit membedakan programmer dengan skill tinggi atau programmer dengan skill rendah. Dengan anggapan bahwa semua programmer (katakan yang bisa bahasa pemograman php) memiliki skill yang sama, maka memilih programmer-programmer yang setuju dengan gaji rendah adalah logis.

Rendahnya dukungan pemerintah / institusi resmi di Indonesia

Partisipasi pemerintah dan institusi-institusi di Indonesia tegolong cukup rendah dalam bidang IT. Rendahnya partisipasi itu membuat perusahaan-perusahaan, terutama yang menengah di Indonesia menjadi antipati terhadap investasi dalam bidang IT. Mereka jadi beranggapan bahwa investasi IT tidak menghasilkan, mahal dan beresiko tinggi. Ditambah lagi dengan banyaknya transaksi / dokumen di Indonesia yang lebih diutamakan secara manual, makin membentuk anggapan perusahaan-perusahaan tersebut.

Kesimpulan

Terbentuknya tingkat gaji programmer yang rendah diakibatkan banyak faktor yang cukup kompleks, dengan berbagai pihak yang ikut bertanggung jawab di dalamnya.

Do programmer’s mind set is different?

I had an interesting and valuable experience last weekend. I’ve meet my cousin’s friend that need help regarding online marketing and do search engine optimization for his existing website. My cousin is great at marketing and sales, but I’m not. So I’ve got a good chance to learn the sales tips personally.

I’ve made a mess there, with my developer mindset. However reflecting from my past action, I think there are some points that I can improve, and share.

Developer is weakness / problem oriented

As a developer, I usually need to either improve the functionality of a system or fix the problem there. Both tasks require me to look for the weakness of the system so that I can either improve or fix it. And to fellow team members or developers, we usually straightforward enough to tell that this is bad, this won’t do, this isn’t working, this’ll bring problem, etc. We usually express it starting with problem and weakness first, then suggest the ideal condition and plans on how to improve it.

That way of expressing matters won’t work to normal people outside of developers.

Sales promote a product

Now let’s say that you meet a salesman that promote you a beauty product.  Let’s say that it’s cosmetics for women and hair gel for man.

During the entire promotion, do you think that the sales will say something like: “you are ugly right now, but after using this beauty product, you will be beautiful like celebrities” or “the current product you are using right now has many flaws, first it cause irritation to skin, which will bla bla bla…”. That may sounds promising, but in the same time, insulting. People don’t like to be insulted.

Back to developer’s side, we accustomed to directly point the problem, like: “this system is vulnerable to sql injection, it is easily hacked. You need to use this and that to cover it up” or “this system is slow. You need to add this and that and change this so that the performance can improve”. Those statements does not differ from the sales statement previously.

Do we need to?

But, how can we point out the weakness of the system without such expression? The question is, do you need to? And even if you need to point them out, can you use a more indirect and polite way of expression?

Most of the time we don’t need. Say that if you are asked to fix the image that is out of line in the web, do you think you need to say that the performance is bad or it is vulnerable to sql injection? The answer is no, you don’t need to say it. It’s out of topic from the original request.

But then you will say that it is bad to hide the problem for them. They may be not asked it because they don’t know about it, so it’s better to point it to them. That maybe the case, but are you really sure that they don’t know? Do you really sure that despite they don’t know, will they accept the point that you are express? Do you think that they will consider the problem important, or will they think it won’t matters? If you are unsure about all of those above (and more to consider), then it’s better to not touch them.

However there is some cases where you think that the problem is critical enough and have high risk including loss of finance that you think it needs to be expressed to the client or not. In that case, you can go to the most polite way of expressing: ask for permission. You can say something like this, example: “I have some opinion regarding the security in your system, would you like to hear it?”, or “I found that there are several things that can be done to improve the search engine optimization for your website. If you are interested, I can point them all to you”.

Now what if the problem is related to their current request, but indirectly? Such as when you are asked to integrate online payment but the performance of the system is bad that it risks the payment process. Again the good advice is: state the current situation and ask for permission. Something like: “We found a problem during implementing the payment process. The payment process will fail automatically after x seconds. The current performance of system lies around x-5 to x+15 seconds, so the current performance will affect the success rate of payment process. Do you think that we need to improve the system performance?”. Then you can state the steps of improvement, and charge them.

Conclusion

Well, marketing and sales world is far different with developer’s world. It’s hard for developer at first to adapt into marketing world and it require different set of skills. Even if I have learn something that I can share here, there are tons of things that I need to learn.

Which attitude for hire?

In management world, you will often hear the following quote:

hire for attitude train for skills

The quote is good and hit the point. However even after you agree that attitude is better than skills for hiring people, knowing which “attitude” that are being mentioned in the quote is important. I will say that, without knowing the attitude that is mentioned in the quote, you better hire for skills instead.

In this article, I’ll use many references from Pawel Brodzinski. His writing is insightful and he is good at management. Moreover, he also had written one article titled “Why I Genuinely Want To Work With You“, a very similar with this one.

The essential attitude : Honest, open handed and cheerful

Essential attitude are useful in any kind of job.

For me, the very essential attitude, required and isn’t negotiable is honesty. A person I want to work with, or hire must be a honest person. Brodzinski also say that in business, the trust isn’t measurable. For me, honesty is the most important part in building trust. Dishonest person won’t make a great partner, and they will even make me work under suspicion and making me take extra step to prevent them stabbing me in the back.

The second essential attitude is open handed and willing to help, If they are willing to help me, I will do the same and am willing to help them. No matter how skilled someone is, if they are not willing to help, their ability won’t be much of use.

Last is cheerful. Why cheerful? A cheerful person will bring positive energy to workplace. They will brighten other employees and they can get more motivation and less stressed. In front-desk jobs, a cheerful person will be more liked by customers rather than a gloomy one. You wouldn’t want to work with a gloomy person, right? Worse if that gloomy person is your supervisor.

Note: There may be several disagreement about those three attitudes can be useful in any job. Ex: cheerful factory worker or honest sales. It is conditional though and can be interpreted differently. Ex: the sales is honest to the company and only do small lies to the customer, or cheerful factory worker can be serious at working and fun at break time.

The job-supporting attitude

Different job need different supporting attitude. That’s why you cannot determine that an attitude will be useful for any line of job, even if the attitude is positive one. For example: a manager or CEO will need to have innovative and creative thinking attitude, while a factory worker need not to have that attitude. A non-innovative or non-creative factory worker is better than innovative one, because they can follow order and won’t complain about the current system. It’s cruel I know, but it’s what the business needs.

The same is applied with the so-called good attitude: “hard worker” and “can work under pressure”. Both of them has very specific appliances and not all line of jobs benefit from them. Managers that is “hard worker” usually cannot manage well. They often do the work themselves and leading to micromanagement. If not, they usually prefer hard-worker staff, resulting in overtime, reduced employee happiness and reduced employee creativity and problem solving skill.

In programming world, they don’t need the “can work under pressure” attitude while most company stated that they need programmer with that kind of attitude. I don’t really understand the reasoning behind it. Unless the software they are developing is used in military, nuclear plants, airplanes or anything that can involve life beings, there won’t be any meaningful pressure.

Michelangelo, talent is cheap, dedication is costly!
– Bertoldo de Giovanni

For every job that need skill refinery such as smiting, music, crafting to even programming, dedication is a must-have trait. They need to be dedicated to their job, doing and doing the same thing countless time, refining they skills anytime to make them able to provide masterpieces.

Conclusion

There are essential attitudes, where the attitudes are useful in any line of job and the other attitudes are job-specifics. Knowing which attitudes to look for is as important as knowing that hiring for attitude is better than hiring for skills. When you are mistakenly looking for the wrong attitude required, you are hiring the bad employee.

Custom apps IT Solution vs Product Developer

Last night I was being interviewed at one IT solution. The interview goes normal, with questions technically and personally. However I feel that the topic of question is different from the last time I had interview (around 2 weeks ago). Long story short, this interview asks more about technical skills and ability of using tools, while at the last interview the topic is leaning more to design, architecture, security and performance.

Custom IT solution is doing the hard work

I’m sorry to say and if this phrase is very harsh to you, but if you are working at custom IT solution, it means that you are being expected to do hard works. The client does not expecting you a good quality product. They expect you to work under their order and develop what they want. You are being valued by how hard you work, not by the product you produced (well the product also being valued, but not as much as your hard work).

I may sound narrow minded, but that is what happen in majority of custom IT Solution companies. Maybe not all (if any), but at least most of them do like that, at least at my country. And no, I don’t say that the practice is bad, or delivered bad-quality product is a sin for those company. It is just a nature of the company, enhanced by clueless leader about IT world. Moreover, the business nature of custom IT solution tend to bring the company into that path.

Faster delivery = more revenue

It is true for all IT solution that faster delivery = more revenue, because faster delivery means more project to handle and it means more income. However the way they do to improve delivery time is wrong. Usually they cut testing time and encourage overtime (worse, unpaid). It resulting in fast, low quality product. Fast, cheap, good, pick two. Usually they pick the fast and cheap one.

Less self improvement

Self improvement (better design, better framework, better developed component, code review, test units, etc) is third priority inside those company. Product delivery takes number one, while customer support takes second. It is because self improvement is seen as expense (manpower and time) and has invisible/indirect benefit. Training and conference does not fall into self improvement though, because it is tightly required to development. Try to learn kaizen.

Even if the company apply self-improvement, it will be driven and handled from top levels, rendering your involvement useless.

Bad documentation

Because you can support and train the customer directly in such big time span (morning to night), it makes documentation less required. Moreover writing a good documentation, and update it every changes will require big effort.

No idea will bloom

Any sprouting idea won’t bloom. Because everything is made by customer request, the company does not need good, fresh idea. They just need a good worker and constructor. Moreover, idea will be seen as hindrance, costly and too much effort to apply.

What about product developer?

If the company developed a product and live by it, the mind set will be different. I don’t say all product developer like that, but at least the successful one does.

Higher quality = more revenue & less cost

Am I drunk that I write something like that? No, I’m not drunk. In product developer company, higher quality product will increase customer satisfaction, resulting in good testimony and recommendation, then resulting in increased sales, means more revenue.

But isn’t higher quality means longer development time and higher cost? Why it can become less cost? It is indeed higher in short time period. However because you will maintain the product for long time (years, at least), fewer bugs and good administration system will help you cutting the cost. The longer the product being maintained, the higher the cost is saved.

Documentation!

A good product must have a good manual, and documented. The better the documentation is, the lesser effort needed to support the customer. It may not apply in all case, but at least some are. The more customer using this product, the more documentation is needed.

Idea!

Idea is everything for the lifetime of the product. A stagnant product lack of new features will become obsolete, and lose competition with new products. The terms is coined as product lifecycle. A good idea from the company member has higher chance to be applied.

Conclusion

The business flow of custom IT solution and product developer is different. Their revenue source and cost is also different. How they are managing the development and support is following each business process. A custom IT solution focus more on development time, while product developer focus more into quality. Not every company in each type follow the same rules, There is also custom IT solution who focus on quality, and product developer who focus on development time.

Why using CMS/third party plugin?

As a software developer myself, I previously hate to use CMS or plugin (let’s call both with CMS) for anything related with my works. Even worse, I try to avoid any plugins-related such as bootstrap. Well, that is me before I’m being involved in professional world. I think that I can make anything, better than any existing tools out there. Presently, I that way of think is wrong, but not when it was at the time before.

It’s Time

In the past

One main reason the inconsistent whether it is right or wrong is one: time. In my past, I have a lot of free time and not involved in any money-making task/job. It is very suitable for the past me to explore the website world, making the prototype myself and trying to compete with existing one. I even developed C# winform foundation myself (the foundation consist of login management, user controls and many utilities such as printing).

It is good, and right, at least when I was in the past. It is my phase in life to learn and train, crafting my skills better. If right now you are thinking about lyric from Linkin Park, “In the end, it doesn’t even matter”, I will say no, it is matter. It does not matter whether what you are trying to build will be used or not. It is matter however, about knowing how to build it and how complex the existing tools is. You will be able to differentiate between good and bad tools, will be fluent and better at using it.

Presently

Now I have been involved in professional work. The time is very limited, so does any works that I can produce within those limited time. I can choose between a vast types of products with shallow quality or very specific type of products with deep quality. I chose the later, resulting in me very specialized at enterprise back-end system, architecturally. Then, if in case I want to produce some general product like company profile, I will use CMS.

Standard and supported

CMS is used by many people worldwide. It has standard interface that everybody knows. Moreover it is supported, meaning that some important feature requested by user will be implemented later, and the bug will be fixed. It is also support external source integration to some point, such as SEO and API. It will be better if you use their paid version or service, meaning you can get support directly from the provider. You can consider this practice as “outsourcing”.

Documented and discussed

A good CMS is used by many people. Many people using the CMS will create discussion. That discussion, when too frequently happen, will one day become FAQ or even included in the documentation. A good documented product will be used by more people, resulting in the cyclic flow of improvement. It is however, different with self-developed system. A good documented and discussed component will make new developer faster to catch up with development.

But it’s limited

Limitation caused by CMS / plugin usually become problem to you. However currently, any good third-party component will provide some way to extend and customize the current behavior. It can be achieved with DI, overriding (CSS and javascript for example), to the extreme way of customizing the source code. The last is not recommended, because after you do so, you cannot expect any update from the provider, rendering the additional feature and bugfix useless.

Every tools out there have limitation. There is one tool that good at one side, meanwhile other good at other side. My knowledge (or yours) received from trying to develop third party tools and people review will enable you to choose which one is suitable for your current needs.

Conclusion

CMS is good if it fulfill your requirements and align with it. If you want some other things that is vastly different with the CMS provided, you need to either look for another or develop it yourself. Customizing CMS too far out of original purporse (ex: using wordpress for stock exchange) or even modifying the source code is not good, since it will prevent you to get further support.

Big or Small Company

Last night I’ve met with my past co-worker at a big company. Before working here at a small company, I’ve worked at a big company for some time beforehand. We talked a lot. Based on their story, the work situation there currently is not far off from last time I was there, or maybe even worse. Same company size, worse workload. It makes me think, how different is it at the big company instead with one in a small company?

Decision maker

In small company, most of strategic decision lies at the hand of the owner. The success factor or future of company lies at the sole hand of the owner.

Meanwhile in big company, The strategic decision are separated by levels. More critical and strategic the decision, the higher the position that make the decision.

Position competency

In big company, a position have clear definition about competencies and required skills. In small company, strategic position usually filled with relations (family or friend), or subjective competency from the owner.

Reward and punishment

In big company, reward and punishment are defined clearly. In small company, it is changing from time to time and only based from oral norms.

Strategic plan duration

Strategic plan in small company usually can be executed faster and clear faster. Usually the strategic plan is planned shorter (days/ weeks/ months) before execution. Strategic plan in big company need more factors to reconsider, has bigger duration and cannot be easily executed. Strategic plan also planned further (years) in big company.

Law

Usually, small company are tend to violate the law more than big company. Especially for tax and employment law. It is basically due to the government can monitor big company more than small company, and big company can easily be exposed when violating law,

Performance

Big company usually has more stable performance. The same performance can be expected with the branches in same area. Small company’s performance are vary and unstable. It is usually based on company owner’s performance, or some skillful’s manpower. When the company lost those skillful manpower, usually the performance go down a lot.

Conclusion

Big company tend to be more rigid and stiff. They don’t change much, but they have clear plans, rewards and rules. In small company, the rules are more subjective based on owner’s view, but they are more agile and flexible.