Dunning–Kruger effect

Kalau anda pernah mendalami dan sudah cukup ahli dalam suatu bidang/keahlian, kemungkinan besar ada saatnya dimana semakin anda belajar/berlatih, semakin rendah rasa percaya diri dan semakin anda merasa tidak mampu di bidangnya. Namun setelah mempelajarinya beberapa kali lagi, rasa percaya diri dan persaan mampu mulai berkembang dan bertambah seiring dengan banyaknya pelajaran/ilmu yang diterima.

Fenomena seperti itu disebut sebagai dunning-kruger effect.

dunning-kruger-effect-1024x724

Pengalaman saya dalam mengalami Dunning-Kruger effect

Dalam pemograman, saya sudah cukup banyak mempelajari dan memahami bidang architecture dan maintainability dari sebuah applikasi. Saya pernah mengalami rasa percaya diri yang tinggi setelah memahami N-Tier, dependency injection dan C#. Saat itu, saya berpikir bahwa inilah arsitektur terbaik dan paling mudah di-maintain. Sekitar 6 bulan berikutnya, saya mendapat kesempatan untuk menerapkan pemahaman saya dalam pengembangan di dunia nyata.

Setelah 3-6 bulan pengembangan berjalan, saya mulai merasakan masalah dan kesulitan dari arsitektur yang saya pilih. Semakin saya mempelajari lebih dalam, semakin saya ragu dengan kemampuan saya. Akhirnya setelah 1 tahun berjalan, proyek dibatalkan (yang merupakan keputusan dari sisi bisnis) dan applikasi yang saya kembangkan tidak berguna.

Kejadian ini saya manfaatkan untuk mengevaluasi pemahaman2 saya dan meneliti arsitektur-arsitektur secara lebih luas lagi. Saya mulai mempelajari nodejs dan kembali memperdalam php. Saya mulai menemukan banyak arsitektur baru dan mempelajari keunggulan dan kelemahan dari masing-masing arsitektur. Dari sana, saya mendapatkan pemahaman yang lebih luas dan menjadi semakin ahli dalam bidang ini.

Manfaat memahami / mengalami Dunning-Kruger effect

Dunning-Kruger effect adalah fenomena alamiah yang dapat dialami oleh siapapun. Efek ini juga alami terjadi dalam sebuah proses pembelajaran. Karena ini adalah proses alami, maka anda tidak perlu takut atau menghindarinya.

Orang biasa pada umumnya sudah menampilkan tanda-tanda menyerah saat mulai mengalami penurunan tingkat confidence saat baru mempelajari suatu bidang. Semakin mempelajari, semakin rendah tingkat confidence nya dan saat mencapai tingkatan terendah, mereka menyerah.

Namun sekarang anda menyadari bahwa ini adalah proses alamiah dan rendahnya rasa percaya diri itu adalah normal. Anda dapat mulai mempelajari bidang tersebut dari sudut pandang yang berbeda-beda, mencari teknik2 dan menggunakan cara-cara belajar yang berbeda. Perubahan cara pandang dan cara belajar tersebut memperbesar kemungkinan anda dalam mendapatkan pemahaman yang lebih luas, lebih dalam, dan meningkatkan confidence. Setelah itu, anda sudah mencapai tahap terakhir dari Dunning-Kruger effect dan pelajaran yang anda dapatkan berikutnya hanya akan memperkuat kemampuan dan confidence anda.

Conclusion

Dunning-Kruger effect adalah fenomena alami yang normal terjadi dalam proses pembelajaran. Memahami fenomena ini dapat membantu anda dalam melewati tahap confidence ter-rendah dan menjadi ahli dalam sebuah bidang yang diminati.

Agile manifesto

Agile is dead! Really?

Dave Thomas, one among the founders of agile manifesto says so in his post blog, “Agile is Dead (Long Live Agility)“. And lately I have seen a blog post “Agile is Dead, Long Live Continuous Delivery“. Is agile really die and need to be changed? Is Continuous Delivery a replacement of agile?

Background

In his blog post, Dave Thomas indeed say that the word “agile” need to be killed down. But why? That’s because the word “agile” and the “agile” concept has been misguided and become a tool, a process and being industrialized. As Dave said in his blog post:

Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, coopted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand.

Get it? The current “agile” is swayed from it’s original meaning and objective. It has become “marketing term”.

Agile is guidance, not methodology

Let’s see what we have at agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The first point itself state that agile is not a methodology. The first point of manifesto states that you need to prefer to individuals and interactions over process and tools. If the agile you know focus to methodology and process, it already violates the first manifesto. Agile is just a guidance, to help you (and the team / company) to find the best process and tools for your development activity.

Even scrum, one of the most popular agile adaptation is still only a guidance or development framework. As stated,

“Langkah pertama yang perlu dilakukan untuk dapat memahami apa itu Scrum adalah dengan tidak mengaitkannya dengan sebuah metodologi apa pun juga karena Scrum hanya sebuah kerangka kerja dalam mengembangkan produk kompleks seperti software.” – Partogi, Joshua (2015) Manajemen Modern dengan Scrum, Yogyakarta, penerbit ANDI.

As translated: the first step that need to be done to able to understand what is Scrum is to not connect it with any methodology because Scrum is only a framework to develop complex product like software.

The marketing term agile / scrum

Today’s agile / scrum meaning varies and very misleading. The most popular misleading scrum is that it has “morning meeting” and “no documentation”. “If we have morning meeting, we already do agile”. It’s very misleading. The sole focus to process is already swayed away from agile manifesto.

Now let’s say that in your company you have one PM that manage 3 teams. Each team is doing project in different area. How can you do morning meeting with those setup? Evening e-mail daily reporting is enough for project tracking with those setup.

Continuous delivery is the next agile!

First, continuous delivery is not directly contradict with agile. Agile does not state that you need to develop a non-ready program. Moreover, agile state that you need to “responding to change over following a plan”, in which more or less is aligned with continuous delivery. And as stated above, agile is a guidance, not a methodology. We can say that continuous delivery is a more advanced implementation for agile.

Then it is the next agile! Hold on. As stated in agile manifesto, individuals and interactions over processes and tools, you cannot directly implement continuous delivery (CD) and hoping for everything to work well. You still need to consider the capability of team, servers, workflows, division, business decision. And the most important, the kind of software you make. CD relies heavily on good QA, test unit and continuous integration infrastructure. If you don’t have those matured, it’s risky to implement it.

Conclusion

Agile is not dead. It’s just that the term “agile” itself has swayed from it’s original meaning. It is a guidance and not methodology. It’s implementation may be evolved and improved. Continuous delivery is a good methodology and can align well with agile.

seminar at bizzy.co.id 22 feb 2016

Mengapa menggunakan framework?

Topik ini adalah salah satu bahasan yang cukup sering ditanyakan oleh programmer-programmer muda (saya belum tua tapi ya) yang baru akan memulai atau baru selesai memperlajari cara menggunakan framework. Sekedar flashback, penggunaan framework pada sekitar tahun 2005-an masih belum populer di Indonesia. Dan pada saat itu, konsep bahwa menggunakan framework menambahkan kode / size yang tidak perlu sangat mendominasi keputusan untuk mengarah ke scratch (tanpa framework).

Karena keterbatasan processing power dan kapasitas harddisk, sayapun pada saat itu juga mengarah untuk tidak menggunakan framework. Namun apa yang saya rasakah setelahnya adalah:

kalau kamu cukup mahir dan tidak menggunakan framework yang tersedia, kamu pasti akan membangun framework-mu sendiri

Mengapa demikian?

Susunan folder dan penempatan file

Untuk project berskala besar dengan tingkat kesulitan kompleks, susunan folder dan penempatan / pengelompokkan file menjadi suatu hal yang penting. Susunan file yang berantakan akan menyulitkan programmer-programmer lain untuk memahami kode, serta mengurangi kualitas dan meningkatkan resiko terjadinya bug.

Framework, pada umumnya sudah memiliki panduan untuk penempatan / pengelompokkan file-file dalam folder-folder tertentu. Standarisasi tersebut akan mempercepat programmer-programmer lain dalam memahami kode, atau mencari posisi kode yang menjalankan proses-proses tertentu. Contohnya folder config, constants, language dan sebagainya.

Bila tidak mengikuti / menggunakan framework yang tersedia secara umum, saya cukup yakin anda nanti akan membangun standar dan aturan pengelompokkan sendiri.

Arsitektur

Umumnya sebuah framework mengikuti susunan arsitektur tertentu. Misalnya pada php, umumnya framework-framework digunakan arsitektur MVC atau HMVC, karena paling cocok dalam server-client architecture. Bila menggunakan contoh lain, misalnya C# dan desktop, prism adalah framework MVVM untuk WPF.

Bagi programmer-programmer yang memahami manfaat arsitektur dalam pemograman, saya cukup yakin bila mereka tidak menggunakan framework yang tersedia, maka mereka akan membangun arsitektur yang mirip (misal dengan MVC).

Class Library

Project yang kompleks memerlukan banyak sekali operasi yang beragam. Namun tidak sedikit dari operasi tersebut yang mirip, berulang dan dapat dikelompokkan menjadi library / class library. Contohnya: logging, serialization, export to excel/csv, image manipulation dan masih banyak lagi.

Framework umumnya sudah memiliki cara sendiri / standar untuk meng-organize library-library tersebut. Contohnya pada laravel yang sudah menggunakan composer sebagai package manager, dan PSR4 untuk autoload class.

Common cases / operation

Mirip dengan class library, ada beberapa kasus / operasi yang umum dan sering ditemui dalam pengembangan applikasi. Contohnya bila dalam php adalah routing, login authentication, response type dan view templating. Umumnya framework sudah mendukung operasi-operasi tersebut.

Standar pengembangan, update dan komunitas

Keuntungan dari menggunakan framework yang tersedia, adalah framework tersebut sudah memiliki standar pengembangan (penempatan kode). Framework juga umumnya diupdate mengikuti teknologi terbaru, dan memiliki komunitas pengguna yang secara tidak langsung meningkatkan kualitas framework, dan mengurangi kemungkinan bug yang ada.

Kesimpulan

Banyak keuntungan yang didapat dengan menggunakan framework. Dan meskipun seseorang yang mahir tidak menggunakan framework yang sudah tersedia, cepat atau lambat applikasi yang dikembangkan akan mengarah dan pada akhirnya menghasilkan framework buatan sendiri.

skill

Saya programmer dengan skill tinggi, saya pasti bisa sukses

Apakah anda seorang programmer? Dan apakah anda berpikiran hanya dengan skill yang tinggi maka anda bisa sukses di dunia kerja / dunia bisnis? Tunggu dulu, ada beberapa faktor yang perlu diketahui sebelumnya.

Skill technical hanya menentukan separuh dari kesuksesan anda sebagai programmer

Apakah benar begitu? Skill technical hanya menentukan separuh dair kesuksesan anda sebagai programmer? Lalu sisa separuhnya adalah faktor-faktor apa lagi?

Mungkin skill technical bisa menentukan lebih dari separuhnya (50%), tapi tidak akan melebihi 70-80% sebagai faktor penentu kesuksesan anda sebagai programmer. Faktor penentu sisanya didominasi oleh skill komunikasi dan negosiasi. Saya tidak akan membahas attitude di sini karena pada artikel ini, saya akan lebih fokus kepada skillset yang diperlukan.

Skill / kemampuan komunikasi

Sebagai pelajar dalam dunia IT dan pemograman, saya juga awalnya tidak tahu seberapa pentingnya kemampuan komunikasi dalam dunia pemograman. Namun setelah memasuki dunia kerja / organisasi, tampak jelas bagi saya seberapa penting, sering dan bergunanya kemampuan komunikasi dalam dunia pemograman. Bila dibandingkan dengan skill-skill non-technical lainnya, saya rasa skill komunikasi adalah yang paling berpengaruh dan bermanfaat dalam dunia pemograman.

Saat interview

Bahkan sebelum interview, kemampuan komunikasi anda akan sangat menentukan apakah anda akan mendapatkan panggilan interview atau tidak. Personal branding, desain CV yang bagus serta dapat menunjukkan skill-skill utama anda, sangat membantu anda dalam mendapatkan panggilan interview.

Pada saat interview, kemampuan komunikasi anda tentu akan lebih berpengaruh lagi. Bagaimana anda berkomunikasi tatap muka dengan orang-orang yang tidak mengenal anda, dan bagaimana anda mempersiapkan diri dengan penampilan terbaik tentu akan dipengaruhi oleh kemampuan komunikasi anda.

Komunikasi dengan atasan

Sebagai programmer, anda akan mendapat proyek / tugas dari atasan / team leader. Pada saat pemberian tugas tersebut, akan ada beberapa kondisi yang memerlukan skill komunikasi. Seperti bagaimana anda bertanya mengenai hal-hal yang tidak jelas dari tugas tersebut, atau mungkin saja ada beberapa ide terkait tugas tersebut yang bisa anda sampaikan. Kemampuan komunikasi anda akan sangat membantu dalam proses tersebut.

Selain itu, umumnya saat sebuah tugas / proyek selesai, sang programmer akan memberikan laporan kepada atasannya. Bagaimana cara menyusun laporan yang baik dan cepat dimengerti, sedikit banyak akan dibantu oleh kemampuan komunikasi anda.

Komunikasi dengan sesama programmer

“Program saya error”, “entah mengapa applikasi ini tidak jalan”, “kenapa datanya duplikat ya?”. Banyak sekali proses komunikasi yang akan terbentuk antar sesama programmer pada saat proyek dikerjakan. Contoh paling umum adalah saat anda perlu menanyakan proses detail dari module yang sebelumnya dikerjakan rekan programmer. Dan sebaliknya, saat anda ditanya oleh rekan anda terkait modul yang anda kerjakan sebelumnya. Sekali lagi, kemampuan komunikasi anda akan diuji di sini.

Komunikasi dengan user / non-technical

Ada beberapa perusahaan yang memerlukan anda untuk berhubungan langsung dengan user / pihak non-teknis. Di sinilah kemampuan komunikasi diuji. Bagaimana cara kita menjelaskan proses techincal kepada pihak-pihak non-technical, yang tidak mengerti istilah-istilah dalam dunia IT.

Skill negosiasi

Skill negosiasi / persuasi sangat diperlukan, terutama pada saat interview. Ya, tentu saja soal gaji dan benefit / tunjangan. Hanya dengan memiliki kemampuan negosiasi dan persuasi saja memungkinkan gaji anda bisa lebih tinggi dari standar dengan tunjangan yang lebih oke.

Selain untuk interview, skill negosiasi / persuasif akan berguna saat berdiskusi / berdebat mengenai kandidat-kandidat solusi untuk sebuah project. Contohnya, senior anda akan marah / tidak terima bila langsung dikatakan “solusi anda nggak akan jalan”. Namun bila diutarakan dengan lebih baik, misal “cara itu ada banyak request ke server kan? Apakah nggak akan membebani? Kalau misalnya begini … bagaimana?” tentu akan lebih mudah diterima dan mereka akan kurang resistif.

Dunia bisnis

Dalam dunia bisnis, lebih banyak lagi skill yang diperlukan selain skill-skill di atas. Contohnya seperti skill leadership / management, networking, kemampuan inovasi, desain dan marketing. Di sini, pengaruh kemampuan technical terhadap kesuksesan anda jadi lebih kecil dibandingkan dalam dunia kerja.

Kesimpulan

Walaupun programmer memiliki tugas utama untuk mengembangkan program, namun bukan berarti skill-skill lain tidak ikut ambil bagian dalam menentukan kesuksesan anda di dunia kerja. Terlebih lagi dalam dunia bisnis. Skill komunikasi dan negosiasi cukup berperan dalam membantu menentukan kesuksesan anda di dunia kerja.

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.

I’ve found a bug! Who to blame?

Despite that blame culture serve no benefit to the company, many companies still have this culture. Moreover, it is stupider to put a blame for bugs happened in software. Simply said, that’s because bugs happen, and the possibility of a bug is close to infinite.

Many times, many parties responsible for bugs in production

Let’s say that we use the following SDLC: requirement, analysis, design, develop, test, implement, maintenance. Now let’s see which responsibility can be held in each phases for each parties.

Requirement

The requirement given by user is ambiguous, has multiple meaning or the worst, he/she is wrong when giving the requirement. Next, the meeting PIC (person in charge) is doing mistake during passing the requirement through the analyst and programmer.

Analysis

The analyst doing a mistake during interpreting the user requirement. The analyst is mistaken during communicating the analysis and requirement through the programmer.

Development

Many-many things can happen during development. Wrong logic condition, wrong parameter assignment, etc. In short, the code is wrong.

Testing

The test case is very lacking compared to the complexity of the project and environment deployed. The case is testing wrong things. The test case resulting in false positive.

Implementation

Incorrect publish parameter. Incorrect deployment tools configuration. Production environment not tested beforehand. Production environment (OS, etc) is different with testing environment, and the code has environment-dependencies. Worse if the publishing done manually.

Maintenance

Internal support team inserting data with format that is not tested (whitespace characters). Some script being executed without tested. No change management for software correction, which causing the developers can directly push file to server. Some maintenance activity (backup, index rebuilding) causing anomaly and incorrect results. User trying to break the system.User input data with unsupported format.

Other causes

Requirement change mid-development. Some requirement break / not compatible with other requirement. Development time being shortened to meet earlier shipping date. Natural disaster causing loss in development time, but no schedule adjustment.

Bugs caused by many factors

Despite code / logic error, many other things can cause bug to an application. For example:

  • compiler / interpreter error – very rare cases though
  • flawed server configuration / installation
  • OS-level bug
  • Bug caused by different configuration in different environment
  • Error caused by cosmic rays
  • Y2k error – year 2000 problem
  • Network-related error
  • Incorrect data / format
  • Not-printable characters input

And there are many-many more.

Conclusion – now, who I can blame for that?

It’s best to not blame anyone for bugs / error happened in a software. Entire team / company should take responsibility for the error (even user as well). What you need to do is, to find the root cause, fix the software and find a way so the same mistake / error won’t happen in the future.

A standard mouse, good for teaching though

Important factor when giving lesson

I get the idea for this article after reading Testivus on Test Coverage story. In this story, three programmers asked Testivus about proper percentage of test coverage. Testivus gives three different answer and every answer depends on skill level / knowledge and attitude of the programmer. The same can be applied to every lesson that you, or anyone when teaching.

Example

Let’s take a situation, where you are teaching newcomers about programming. First, you teach them about variable, data type then if-else, function and so on. You will try to arrange the topics and course material as easy and as non-technical as possible. Later on after several meeting, you can move to deeper and more technical topic.

Absolutely you won’t mention about interface, clean code, architecture, dependency injection, CQRS or any advanced-level topics during the first course. They don’t know what those topics are about. They won’t get anything beneficial from those topics. It is same as a programmer attending a seminar about newly founded medicine which can cure cancer, presented by researchers targeting senior doctors.

You don’t teach any advanced topics during first course for newcomers

Why so

Man 1: hey, YYMM’s stock is on golden cross today!
Man 2: Have you see the 60 days MACD? It haven’t touch the support yet!

Are you an investor? Or have you do stock once or twice? If you do, then you will know what the conversation above is about. Assuming that you don’t know anything about stock, what is your reaction when I tell you to buy a stock because it’s on golden cross today? What knowledge do you get from that?

Nothing. You don’t even know what a stock is about. You don’t even know about the stock basics yet. The basics is included as: stock unit, how to buy it, how to sell, how the price is formed, open/close/high/low price, closed market, closed time buy, etc. After that you need to learn about resistant and support, then graph, then you are approaching the more advanced concept such as fair value and reading quarterly financial statement.

Now let’s say that you already learned the basic, then suddenly you attend a seminar led by George Soros about how to do a 3 months projection of a stock value based on current financial statement. I guarantee that you either be confused and get nothing, or at max you only get the minimum value from it.

Now let’s say that instead of that seminar, you attend a local financial institute seminar about how to do cut loss and planning for cut loss. You already know the basics and that topic is not too far from the basic. You will understand what the seminar is about and get full benefit / knowledge from it.

When attending a wrong course, you will be confused and get nothing. However when attending a right one, you will understand it and get full benefit

The case in IT / Programming

“How to build an e-commerce with PHP, mysql and laravel for beginner”. When I ask for suggestion about what topic should I bring for newcomer, many colleague suggested that topic. Then as usual, I spend 15-30 minutes explaining why it doesn’t work. Every time.

This is also the basis for my decision to use javascript as programming language for newcomer. Weakly typed, interpreted, support procedural and multiplatform. They don’t need to do variable declaration, initialization, type casting (conversion still exists, though), directly run the code without compilation, and no need to learn about object oriented or classes and the likes. With this, I can teach how programming works and they can immediately learn about the concept of programming.

The software requirement is negligible. With a programmed environment, for example this jsfiddle: https://jsfiddle.net/fendy3002/1embueho/, someone can begin programming anywhere anytime. So far I only find one weakness and that is to receive input from user, you will need to learn html first. That’s some big sidetracking I must say.

I use javascript as programming language for newcomer because it is weakly typed, interpreted, support procedural and multiplatform

Conclusion

To ensure that the topic you bring in a course can be learned effectively and beneficial, you need to know the skill / knowledge level of said attendance.