Uncategorized

skill

Saya programmer dengan skill tinggi, saya pasti bisa sukses – Part 2

Sebelumnya dalam artikel dengan judul yang sama, saya pernah menjelaskan bagaimana soft skill-soft skill di luar programming, terutama yang berkaitan dengan organisasi dan komunikasi, dapat membawa manfaat tambahan bagi programmer. Kali ini, saya akan coba membahas situasi-situasi yang ternyata kebalikannya, di mana soft skill tidak terlalu bermanfaat bagi programmer.

Startup / perusahaan kecil dengan CEO dan CTO yang kuat

Startup / perusahaan kecil umumnya didirikan oleh 2 founder, yaitu CEO (Chief Executive Officer) dan CTO (Chief Technology Officer). Untuk beberapa startup yang foundernya cuma sendiri, biasanya memegang peran ganda, yaitu CEO dan CTO secara bersamaan.

CEO mengurus semua aspek bisnis non-technical, seperti requirement, marketing, funding, networking, mencari client dan aspek-aspek bisnis non-technical IT (seperti merekrut driver di gojek). Sementara CTO mengurus semua aspek technical IT, seperti server, arsitektur, bahasa pemograman, framework dan lainnya.

CEO yang berpengalaman akan dapat men-handle aspek-aspek non-technical IT, terutama yang berurusan dengan user / client. Untuk hal-hal technical IT yang memerlukan keterlibatan user, maka CTO dapat me-handle nya. Karena sudah di-handle oleh CEO dan CTO, maka programmer hanya perlu mengerjakan requirement dan mengikuti arahan dari CTO (atau project manager bila ada).

Karena perusahaan kecil tidak mampu mempekerjakan banyak karyawan, maka semakin tinggi skill programmer dan analisanya, maka semakin diminati. Soft skill yang diperlukan hanya komunikasi umum (sehari-hari) dan sedikit kemampuan analisis, agar dapat memahami requirement dan arahan. Karena kemungkinan bagi programmer untuk berhubungan dengan user kecil, maka skill negosiasi dan komunikasi yang tinggi tidak terlalu bermanfaat.

Developing non-business application

Menurut saya, applikasi dapat dibagi menjadi 2 dari aspek penggunaan. Pertama adalah tools. yang fungsi applikasinya lebih umum, dapat digunakan oleh lebih banyak user, dan tidak terlalu terikat pada bisnis tertentu. Contohnya seperti photoshop, notepad bahkan database oracle. Sementara applikasi lainnya adalah implementation, di mana penggunaannya spesifik untuk satu unit bisnis tertentu, dan sangat erat dengan proses bisnis si pengguna. Contohnya applikasi POS, accounting, dll. Tentu saja applikasi tidak dapat dibedakan seperti hitam dan putih. Bisa saja sebuah applikasi memiliki karakteristik keduanya. Contohnya seperti cloud accounting.

Sebagai programmer, semakin applikasi yang di-develop ke arah tools, maka semakin sedikit soft skill yang dibutuhkan. Begitu pula sebaliknya, semakin applikasi yang di develop mengarah ke implementation, maka semakin banyak soft skill yang dibutuhkan. Hal ini karena programmer mengembangkan applikasi yang langsung di-request oleh user, maka keterlibatan user dalam pengembangan menjadi lebih tinggi. Semakin applikasi yang di-develop mengarah ke tools, maka teknologi yang diperlukan dan kompleksitasnya akan semakin tinggi (lebih tinggi dari implementation), sehingga daripada soft skill, skill technical yang tinggi jauh lebih diperlukan.

Kesimpulan

Dalam beberapa kondisi, soft skill akan sangat membantu programmer di dunia kerja dan meraih sukses. Namun dalam kondisi lainnya, skill technical dari programmer dapat menjadi satu-satunya parameter penentu keberhasilan seseorang. Mengetahui ini, maka programmer dapat menentukan langkah-langkah yang dapat diambil untuk mengembangkan diri dan karir.

Advertisements
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.

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.

Context Switching – what works for me

Context Switching

This article is a follow up to Pawel Brodzinski’s good article about context switching. On short note, let’s say that context switching happens when we are doing one project, then switching to another project. The tasks, information, data, code (context) are changing.

Context switching is not without cost, it consume brain power and usually need time for one developer to catch up to working condition after switching. So it is generally bad. However Brodzinski already mentioned the Zeigarnik Effect.

Our brains remember much better tasks that we haven’t finished and also have intrusive thoughts about that thing.

So we got 2 contradict situation. One where our brain is doing better when we are multitasking (switching context) and that the context switching / multitasking is costly. Let’s just say that the amount of multitask one can do will yield into diminishing return at one point. So how do we know the peak point of context switching’s benefit? Trial and error. The solution below works for me, and maybe also works for you.

My Solution

Limit to two tasks

For me, multi tasking comes with responsibility and pressure. More tasks assigned to you, more pressure and responsibility you hold. Which is why I think assigning two tasks at the same time is the best. Three is okay, but the third one must have very low priority over the other. More than three will cause queue time.

One long-running task and one short-running task

I experienced good performance when I am assigned with one project / task which is long-running (long deadline), and another which can be completed shortly / soon. That way, I can focus my work to the long duration one, then switch to the short-duration one when I get problems / stuck or simply bored.

Why not both short-duration or both long-duration tasks? I must say the mental effect comes here. A feel of achievement from clearing one task can help you boost your moods and performance. The mood boost will help when working the other one. That can only be achieved by doing two different-duration tasks.

Can focus the long duration work, then switch to the short-duration work when get problems

One higher priority and another lower priority task

Similar with before, this way I can focus the work with the higher priority one then switch to lower one when stuck. When both tasks are high priority, and you will feel very pressured. Otherwise, when both tasks are low priority, you will feel lazy / loose.

Do I feel the performance gain?

Yes it is. I don’t know whether it’s the same case with the other. However when I am stuck with a case/problem or need a long time analysis, usually I tried to distract myself from the task (usually by browsing which ended in seeing many cat pictures), or changing to other tasks. After some time, I will switch back to the problem with zero cache or memory in my mind about it, and thinking it from the start with different approach.

This way, when I have multiple tasks, I can distract myself with that other task, while both unconsciously thinking about the problem and forgetting the current not-working solution about the problem.

When I am stuck, I tried to distract myself and come back later with new approach

Conclusion

Two task, with both varies between priority and duration benefits me the most from context switching.

People and Methodology at Work

Spot on points about methodology. Will be useful for software development.

People - Process - System

Before I start, I hate to work with un-organized people and organization. Campaigning what should we do with Plan Do Check Action (PDCA) slogans, just like fart… No Plan, Less Do, Un-check and No Action…

Back to this article, I would like to combine between People and Process through this title… People and Methodology at Work…

My personal definition (and originally made by me) of methodology is the art to solve problem systematically utilizing creativity, knowledge and experiences continuously.

In my perspective, there is only optimized methodology or un-optimized methodology. Methodology can’t be judged right or wrong. That’s it.

Five things I would like to highlight related to methodology:

  • Creativity. Mainly focus on methodology development. How creative you are to solve the problem, related to the methodology process and result. Creativity closely related to the skill.
  • Knowledge or education background as a foundation to build up methodology. It’s like a background processing in computation. What you…

View original post 199 more words