งาน Software Engineer ในยุโรปตะวันตก

ช่วงนี้เป็นยุคทองของโปรแกรมเมอร์ครับ ไม่ใช่แค่ที่อเมริกาเท่านั้นที่มีปัญหาขาดแคลนโปรแกรมเมอร์ดีๆ ที่ยุโรปเองก็เป็นเหมือนกัน

ผมประทับใจโพสต์ของคุณ Tanin Na Nakorn (https://www.fongmun.com/m/10733) เลยอยากเขียนของฝั่งทางยุโรปบ้าง เผื่อมีคนสนใจ

ขอเล่าข้อมูลเกี่ยวตัวตัวเองคร่าวๆก่อน ตอนนี้ผมเป็น Software Engineer อยู่ที่เนเธอร์แลนด์ในขณะนี้ ผมทำงานเป็นโปรแกรมเมอร์ที่ไทยอยู่ประมาณสองปีครึ่ง ก่อนจะได้ทุน Erasmus Mundus มาเรียนต่อที่ยุโรป ไปเรียนทั้งหมดสี่ประเทศ คือ ฝรั่งเศส ฟินแลนด์ เนเธอร์แลนด์ และเยอรมัน

ระหว่างเรียน ผมไปฝึกงานที่ SAP ในเยอรมันอยู่หกเดือน ก่อนจะกลับมาทำงานที่เนเธอร์แลนด์ในตำแหน่ง Software Engineer ตอนปี 2013

ช่วงปี 2014 บริษัทส่งไปอเมริกาอยู่หกเดือน ก่อนจะกลับเนเธอร์แลนด์ ตรงนี้ทำให้ผมพอเปรียบเทียบได้ว่าการอาศัยอยู่ที่อเมริกาต่างกับยุโรปอย่างไร

โพสต์นี้จะแบ่งเป็นสองส่วน ดังนี้

  1. ใช้ชีวิต + ทำงานที่ยุโรปกับสหรัฐอเมริกา ข้อดี ข้อเสียเป็นอย่างไร?
  2. ช่องทางในการหางานที่ยุโรป

ในที่นี้ผมจะกล่าวรวมๆถึงแค่ยุโรปตะวันตก (เช่น ฝรั่งเศส เยอรมัน เนเธอร์แลนด์ เบลเยี่ยม)  และกลุ่มประเทศแสกนดิเนเวีย (เช่น นอร์เวย์ ฟินแลนด์ ) โดยยกเว้นกลุ่มประเทศที่กำลังมีปัญหาทางเศรษฐกิจอยู่ (อิตาลี สเปน)

เนื่องจากแต่ละประเทศในยุโรปมีความแตกต่างกันค่อนข้างมาก เรื่องไหนที่เฉพาะเจาะจงผมจะบอกชื่อประเทศไว้ด้วยครับ

1. ใช้ชีวิต + ทำงานที่ยุโรปกับสหรัฐอเมริกา ข้อดี ข้อเสียเป็นอย่างไร

1.1 เงินเดือนกับค่าใช้จ่าย

ต้องบอกก่อนเลยว่า เงินเดือนของ Software Engineer ที่ยุโรปต่ำกว่าที่อเมริกามาก  นอกจากตัวเงินเดือนจะต่ำกว่าแล้ว ภาษียังสูงกว่ามากด้วย ในอเมริกาภาษีอยู่แถว 35% แล้วแต่รัฐ แต่ในยุโรป ภาษีสูงถึง 42-52% (เนเธอร์แลนด์ เยอรมัน)

ตัวอย่างเช่น เนเธอร์แลนด์ เงินเดือนเฉลี่ยต่อปีอยู่แค่ประมาณ 45-50k EUR ต่อปี (50 – 56 USD)  เทียบกับอเมริกา ถ้าความสามารถใกล้ๆกัน ผมคิดว่าควรจะได้แถวๆ 80-100k USD ขึ้นกับรัฐ และบริษัท

ยิ่งช่วงค่าเงินยุโรปตกนี่ยิ่งน้อยใหญ่

ส่วนเรื่องของค่าใช้จ่าย ถ้าไม่ทำกินเอง อาหารนอกบ้านในฝั่งยุโรปตะวันตกแพงกว่าที่อเมริกาประมาณ 20-30% ครับ ตัวอย่างเช่น สั่งอาหารง่ายๆในอเมริกาตกสัก 10 USD  ที่ยุโรปจะประมาณ 12 – 15 EUR

ส่วนค่าบ้าน อันนี้อเมริกาแพงนำลิบลิ่ว โดยเฉพาะในโซนไอทีที่มีบริษัทใหญ่ๆ (Google/Amazon/Apple/Microsoft) เปิดอยู่

คำนวนโดยรวมแล้ว ถ้าจุดประสงค์หลักคือการเก็บเงิน ไปอเมริกาดีกว่ามากครับ เก็บเงินได้เยอะกว่ามาก

จะมียกประเทศเดียวที่น่าจะเก็บเงินได้สูสีกับการอยู่อเมริกา คือสวิสเซอร์แลนด์ ที่ฐานเงินเดือนอยู่ที่ $100k  แต่ค่าครองชีพนั้นแพงกว่าอเมริกามาก ต้องควบคุมค่าใช้จ่ายกันหน่อย

รองลงมาก็คือเนเธอร์แลนด์ ที่มีมาตรการลดหย่อนภาษีให้กับคนต่างชาติ (Highly skilled immigrant)  แต่หลังภาษีแล้วก็ยังน้อยกว่าอเมริกาอยู่พอควรอยู่ดี

หากต้องการข้อมูลละเอียดของแต่ละประเทศ ผมแนะนำ Glassdoor.com สำหรับเงินเดือน และ Numbeo.com สำหรับ cost of living ครับ

1.2 ความปลอดภัย

วัดกันตามสถิติ ความปลอดภัยของยุโรปตะวันตกนั้นดีกว่าที่อเมริกามาก ยกเว้นอยู่ประเทศเดียวคือฝรั่งเศส  ทั้งนี้ทั้งนั้น แต่ละเมืองไม่ว่าประเทศไหน จะมีโซนที่เป็นจุดอันตรายมากกว่าจุดอื่นๆ เวลาหาที่อยู่ ควรทำการบ้านไปให้ดีด้วยว่า crime rate ของแต่ละโซนเป็นอย่างไร

จากประสบการณ์ ผมคิดว่าความปลอดภัยนี่แล้วแต่ตำแหน่งจริงๆ แต่ความรู้สึกโดยรวม ยุโรปก็ยังดูดีกว่า แต่หลังเหตุการณ์ก่อการร้าย ตอนนี้เมืองใหญ่ๆที่ประเทศไหนก็ดูมีความอันตรายหมด

เรื่องการเหยียดผิวหรือคนต่างชาติ จะมีมากในฝรั่งเศส แต่ไม่ได้รุนแรงจนถึงขั้นเป็นถึงเนื้อถึงตัว   มีบ้างประปรายระดับหนึ่งในเยอรมัน ส่วนเนเธอร์แลนด์กับแสกนดิเนเวียนนี่ค่อนข้างน้อยมาก

1.3 การเป็นอยู่

ปัญหาหลักของการอยู่ในยุโรปคือเรามักจะพูดภาษาท้องถิ่นไม่ได้ แต่ถ้าเลือกอยู่ใน เนเธอร์แลนด์ หรือแสกนดิเนเวียน แทบทุกคนจะพูดภาษาอังกฤษได้หมด อยู่สบายมากครับ ส่วนตัวผมรู้สึกว่าฟังรู้เรื่องกว่าในอเมริกาด้วยซ้ำ เพราะเป็นภาษาที่สอง เลยพูดกันไม่เร็ว แล้วก็ไม่ได้ใช้แสลงมาก

แต่ถ้าเลือกฝรั่งเศส หรือเยอรมัน อันนี้จะลำบากหน่อย คนพูดอังกฤษได้น้อยมาก

เรื่องการเป็นอยู่ อเมริกามีความสะดวกในการซื้อของและช็อบปิ้งมากกว่า Amazon ทำให้ชีวิตสะดวกสบายมาก แม้ยุโรปจะมีอีคอมเมอร์ซผุดขึ้นมาเยอะมาก แต่สิ่งของที่ขายก็ยังไม่เยอะและครอบคลุมได้เ่ท่า Amazon อเมริกา

ข้อด้อยของอเมริกาคือระบบขนส่งสาธารณะน้อยกว่ายุโรปตะวันตกมาก รถไฟมีเที่ยวน้อย ด้วยความที่ประเทศมีพื้นที่มากด้วย บางที่ ถ้าไม่มีรถนี่เข้าถึงไม่ได้

ส่วนด้านความสะอาดและความน่าอยู่ของบ้านเมือง ผมชอบยุโรปมากกว่า หลายๆเมืองดูเก่าและมีเสน่ห์

1.3 Work-life balance

นี่เป็นจุดที่ผมชอบที่สุดในยุโรปครับ ที่นี่ทำงานแปดชั่วโมงก็คือแปดชั่วโมงจริงๆ ผมไม่เคยเจอหัวหน้าที่สั่งให้ลูกน้องอยู่ต่อ แล้วลูกน้องงานไม่เสร็จก็ไม่อยู่ต่อด้วย กลับบ้าน น้อยครั้งมากที่จะเจอบริษัทที่กดขี่ใช้ให้คุ้ม ซึ่งส่วนใหญ่ก็เป็นบริษัทอเมริกัน

ระบบ Union ที่ยุโรปแข็งแรงมาก การจะไล่พนักงานออกไม่ใช่เรื่องง่าย ต้องแจ้งล่วงหน้าว่าทำงานไม่มีประสิทธิภาพแล้วให้โอกาสปรับปรุงก่อน ถึงจะไล่ออกได้ แถมไล่ออกต้องจ่ายเงินให้เยอะพอสมควรด้วย

ที่เจ๋งมากๆคือบางประเทศ(เนเธอร์แลนด์) สามารถทำงานไม่ต้องครบห้าวันกันได้จนแทบเป็นเรื่องปกติ  ใครที่มีลูก หรืออยากใช้เวลาทำอย่างอื่น ก็สามารถทำงานแค่ 3-4 วันได้  จริงๆแล้วที่อเมริกาก็ทำได้เหมือนกัน แต่ไม่ใช่เรื่องปกติเหมือนที่นี่ อย่างที่ทำงานผม 50% ก็ทำงานกันแค่สี่วันต่อสัปดาห์

ส่วนเรื่องวันหยุด อเมริกาให้หยุดได้ประมาณ 10-15 วัน แต่ที่ยุโรปนี่ส่วนใหญ่ 25+  ใครที่ต้องกลับไปเที่ยวไทยบ่อยๆ หรืออยากท่องเที่ยว อยู่นี่จะมีความสุขมาก

1.4 การท่องเที่ยว

อันนี้แล้วแต่คนชอบ ส่วนตัวผมว่ายุโรปดีกว่ามาก เนื่องจากมีเชงเก้น ทำให้ไม่ต้องขอวีซ่าเพิ่มเวลาไปประเทศอื่นๆในยุโรป (ยกเว้น UK)

สถานที่ท่องเที่ยวเยอะจนไปไม่หมด อยากดูออโรร่า ขี่เลื่อนฮัสกี้ก็ขึ้นไปฟินแลนด์  อยากดูธรรมชาติสวยๆก็ไปสวิสหรือออสเตรีย สถาปัตยกรรมเก่าๆก็มีเยอะมากกว่าประเทศที่พึ่งเกิดทีหลังอย่างอเมริกา

2. ช่องทางในการหางานที่ยุโรป

ส่วนใหญ่ในยุโรปจะหาคนในประเทศก่อน หากไม่ได้แล้วก็จะออกไปหาประเทศอื่นใน EU (สหภาพยุโรป) เลยไปถึงทางตะวันออกกลาง  ก่อนที่จะเป็นประเทศนอกทวีปครับ  Priority ในการหาคนก็จะเป็นไปตามลำดับ

ถ้าเป็นงานด้านอื่น ผมบอกเลยว่ายาก แต่สำหรับงานด้าน Software Engineer ซึ่งกำลังขาดแคลนกันอยู่ ยังมีโอกาสการจ้างงานอยู่ เพราะคนที่ทำ อย่างที่ทำงานผมนี่ 80% เป็นชาวต่างชาติ

2.1 หาจากประเทศไทย

เนื่องจากการจ้างงานคนนอก EU มีขั้นตอนพอสมควร กรณีนี้โปรไฟล์ต้องดีมาก เช่น มี contribution ใน opensource ดังๆ  มีประสบการณ์ที่เกี่ยวข้อง สกิลปึ้ก ภาษาได้  กรณีฝรั่งเศสหรือเยอรมัน ส่วนใหญ่ต้องพูดภาษาของเค้าได้ด้วยหลักๆคือ คุณต้องเก่งในระดับที่เค้าหาคนในประเทศไม่ได้ (หรือแพงเกินไป) หาคนในประเทศ EU ไม่ได้ เค้าถึงจะต้องจ้างคุณ แม้จะไม่เสมอไป แต่ก็ต้องเก่งในระดับนึง

กรณีนี้ ผมแนะนำว่าให้เล็งไปที่บริษัทใหญ่ๆ เพราะมีเงินพอจ่ายให้บินมาสัมภาษณ์ และมีแผนก HR ไว้จัดการเรื่องการจ้างงานจากต่างประเทศโดยเฉพาะ

การสมัครงาน ถ้าสมัครผ่านอินเตอร์เน็ตตรงๆจะยาก เพราะจะโดน HR สกรีนออกไปก่อน แนะนำให้หาทางติดต่อ Hiring manager ให้ได้โดยตรง

ถ้ามีคนรู้จัก refer ให้จะดีมาก  ถ้าไม่มีคนรู้จักทำงานต่างประเทศ ลองหาเพื่อนของเพื่อน หรือหาผ่านทาง Opensource โปรเจ็ค, LinkedIn หรือ ตาม International Conference ต่างๆ

หรืออีกทางนึง คือผ่านทาง recruiter ตาม LinkedIn

2.2 เรียนจบที่นี่ หรือเคยฝึกงาน

อันนี้แตกต่างกันไปตามแต่ละประเทศ บางประเทศมีนโยบายในการดึงดูดแรงงานฝีมือต่างชาติมาทำงาน อย่างเนเธอร์แลนด์ หลังเรียนจบจะสามารถขอวีซ่าพิเศษไว้หางานได้หนึ่งปี โดยระหว่างนั้นสามารถรับจ๊อบทำงานตามร้านอาหารไปได้แต่บางประเทศก็ยากมาก เช่นประเทศอังกฤษ ใครมาเรียนที่นี่ ถ้ากะทำงาน มาถึงปุ๊บต้องร่อนใบสมัครเลย รอจนเทอมสุดท้ายนี่ไม่ทันแน่นอน

การมาเรียนที่นี่ ข้อได้เปรียบจริงๆคือได้ connection ผ่านทางอาจารย์ หน่วยงานจัดหางานในมหาวิทยาลัย ศิษย์เก่า หรือคนรู้จัก

ยิ่งถ้ามีโอกาสได้ Internship จะมีโอกาสสูงมาก แต่ก็ต้องดูให้ดี เพราะบางบริษัทรับ Intern ไปแค่ให้ทำงานเล็กๆน้อยๆ โดยไม่ได้มีแผนว่าจะจ้างงานหลังเรียนจบ

ถ้าใครคิดจะมาเรียนโทอยู่แล้ว ทางเลือกนี้น่าสนใจไม่น้อยเลยทีเดียว ผมแนะนำให้ลองกูเกิ้ลทุน Erasmus Mundus ดู  ทุนนี้เป็นทุนเต็มจำนวน มีค่าใช้จ่ายสำหรับใช้ชีวิตได้สบายๆ และไม่มีข้อผูกมัดหลังเรียนจบ

 

 

Leave a comment

Points to consider before adopting TypeScript

JS to TS

Introduction:

The advent of Angular 2.x makes many teams considering to adopt TypeScript in their projects. The same goes for my team even we are still on Angular 1.x.

Upon research, we found that TypeScript is very attractive. It provides strong typing which allows us to detect type-related bugs early and nicer auto-completion. In addition, the syntax is cleaner for modularization and OOP.

We decided to use TypeScript in our new module for a month. After that, we decided to revert back to the good old JavaScript.

This doesn’t mean that TypeScript is not good (and I would never dare make such a bold claim). But it was because it didn’t suit our team. The benefits we received did not outweight the price we had to pay.

Eventually, I think we would adopt either TypeScript or ES6 in the end. But it is not now.

There are numerous blogs explaining how awesome TypeScript is, so we will skip that. This blog will discuss about the points you should carefully consider before adopting it.

  1. Do you really need strong-type?
  2. Is your team good enough at JavaScript?
  3. Is your team good enough with build tools?
  4. Can you accept more complicated build process?
  5. How do you execute your unit test and debugging?

I would try to stay neural and objective as much as possible. I will be very clear if any idea is my personal opinion.

Points to consider:          

1. Do you really need strong-type?

Let’s revisit the benefits of strong typing:

  • Safety & early bug catch
  • Better IDE assistance (e.x. auto-complete, refactoring)

A way to measure this is asking your team “How often do we found bugs that are related to wrong type?” (Undefined error, etc.) If the answer is “Meh, not really. Our unit tests catch most of them already”. Then the benefit might not be as much as expected.

The IDE assistance is very valuable, but do you really use that a lot? The IDE your team currently uses might offer a certain degree of auto-completion for JavaScript. Of course, it is not very accurate without strong-type, but is it sufficient? What about refactoring? Is your code complex enough to gain the real benefit?

The benefits might not be as big as you think. Your team might have a way to cope with some JavaScript shortcomings already.

2. Is your team good enough at JavaScript?

TypeScript hides many ugly sides of JavaScript (ex. IIFE, “this” variable, prototype style of OOP.) . But the ugliness is still there during execution. Lacks of fundamental knowledge in JavaScript will make it longer to really understand TypeScript. Those who understand these quirks already can understand TypeScript easier and take less time to adopt the language.

From another angle, we can rely on sourcemaps and ignore those quirks in JavaScript. After all, we don’t need to know assembly to write C. But, in my opinion, I do believe that fundamental JavaScript knowledge will be required sooner or later. Lack of fundamental knowledge usually leads to surprising bugs.

3. Is your team good enough with build tools?

You will never get the build process right in the first time. During the first months of adoption, your build tool will be unstable and require a lot of tweaks. Be prepared for that. If your team members cannot fix some basic issues in build tools you use, the development will be blocked and the productivity will suffer. Be prepared. You should have more than one person who are good with the build tools to avoid bottleneck

If you rely on another team to tweak a build tool for you, be careful. At least, you should be able to configure your development cycle build in your own team.

In short, your productivity will most likely be impacted more than you initially estimate.

4. Can you accept more complicated build process?

Your unit test & “grunt serve” will be run on transpiled JS code. When you run and debug your application, you probably need to run it on a .tmp folder with sourcemaps.
If you use Karma, the TypeScript pre-processor https://github.com/sergeyt/karma-typescript-preprocessor is handy. It transpiles your *.ts files when Karma is run. Then it deletes them after the testing competes. However, I found some cons in using this plugin.

In the end, I removed this preprocessor and use Grunt to perform transpilling step manually to .tmp folder. Then the unit test task runs unit test on that .tmp folder.

Alternatively, you can leave it to your IDE (IntelliJ, VS Studio) to do all these jobs. The support for IDE has been improving at a very quick speed. So you probably have a very good TypeScript support by the time you read this blog. Still, you will eventually need the grunt script for running on the build server. And, in my opinion, using multiple ways of building in the same project usually leads to a trouble in long term.

Finally, there is no tools that could provide a coverage report in TypeScript. (I did my research around Sept. 2015) So we need to do this in the transpilled JS. Thus, the coverage report is quite useless, we could only use the coverage percentage. Not a big deal if your team doesn’t use coverage report.

To summarize, the additional transpilling step affects us more than we expected. In your case, make sure to do your research carefully to avoid any nasty surprise along the road.

5. How do you execute your unit test and debugging?

To debug in TypeScript, you need a sourcemap. This can be configured in your build tool. It is very easy if you debug on your browser. But what about your IDE? Can you debug with Grunt/Gulp or you must stick to what your IDE provide?

If your team uses IDE for debugging, ensure that it has sourcemap integrated and can debug TypeScript on the fly.
One pain point we experienced is that there is no TypeScript debugging support for Karma plugin in our IDE (IntelliJ/WebStorm). Ideally, unit test should be simple and not require debugging. Unfortunately, our world is not ideal. The unit test in the legacy code might break and it is usually not clear what exactly the unit test wants to test. As a result, we were forced to the primitive and inefficient console.log(). That eats us a lot of time.

Conclusions:

When people talk about adopting TypeScript, they usually focus on benefits. Hence, we classically underestimate the time we need to spend for learning and adjust our build tools. There is a cost we need to pay and it might not worth the benefits.

Nevertheless, I think that our choice on adoption was the right decision. We never know till we try. And we tried first on a new codebase, so the cost for reverting back was not high. The experience we earned will make us better in adopting new technologies in the future.

Leave a comment

ลักษณะสำคัญของ JavaScript ที่ Java Developer ควรรู้

เวลาผมสัมภาษณ์งาน Java Developer หากผู้สมัครอ้างว่าเขียน JavaScript ได้คล่อง ผมมักจะถามคำถามนี้เสมอ

อะไรคือลักษณะสำคัญของ JavaScript ที่ Java Developer ควรรู้

จุดประสงค์ของคำถามนี้คือเพื่อวัดว่าผู้สมัครรู้จัก JavaScript จริง หรือแค่ก็อบโค้ดมาแก้ชื่อตัวแปรให้ทำงานได้เป็น ถ้าผู้สมัครนึกไม่ออกว่ามีข้อแตกต่างอะไรบ้าง ผมก็จะบอกคีย์เวิร์ด แล้วให้อธิบายว่าคีย์เวิร์ดนั้นๆมีความหมายอย่างไรใน JavaScript

ผู้สมัครที่ดี ควรจะเข้าใจว่าสองภาษานี้แตกต่างกันโดยสิ้นเชิง  แล้วอธิบายข้อแตกต่างตามหัวข้อข้างล่าง (ไม่จำกัดอยู่แค่นี้)

  1. Interpreted vs. Compiled
  2. Dynamic typing vs Static typing
  3. Prototype vs Class-based
  4. Function vs Block scope
  5. Global variable กับ IIFE
  6. Passing function and Closure
  7. “this” variable behaves differently
  8. == vs ===

ในบล็อคถัดๆไป ผมจะค่อยๆไล่แต่ละหัวข้อแบบลงลึกครับ

จากประสบการณ์ ผู้สมัครน้อยคนมากที่สามารถตอบได้เกินสามข้อแรก โดยส่วนตัว คนที่อธิบายได้ถึง 4-6 ข้อ ผมจะให้ผ่านในระดับที่เข้าใจภาษาพอที่จะทำงานได้ แต่คนที่อ้างว่าเป็นระดับ expert และเขียน JavaScript มาเกินหนึ่งปี ถ้าผมบอกคีย์เวิร์ดในแปดหัวข้อนี้แล้วไม่สามารถอธิบายได้ ผมจะผิดหวังมากๆ

ทำไมคำถามพวกนี้ถึงสำคัญ?

การเข้าใจถึงภาษาที่ตนเองใช้เป็นอย่างดี เป็นตัวชี้บอกคุณภาพของโปรแกรมเมอร์ครับ

Java โปรแกรมเมอร์หลายๆคนมักจะเถียงว่า เรื่องเหล่านี้เป็นเรื่องจุกจิก ไม่มีความจำเป็นที่จะต้องรู้ก็เขียน JavaScript ได้  ถ้าอยากรู้ แค่หาใน StackOverflow ก็เจอแล้ว

ปัญหาคือ โปรแกรมเมอร์ที่คิดว่าตัวเองเข้าใจภาษาทั้งๆที่ไม่รู้เรื่องเหล่านี้ มักจะใส่บั้กเข้าไปในระบบโดยไม่รู้ตัว (ทำมาแล้วกับตัว เพราะผมเขียน Java  มาก่อน JavaScript) แล้วทีมก็ต้องเสียเวลามานั่งแก้บั๊กทีหลัง หรือแม้แต่ในโปรดักชัน ซึ่งเป็นการเปลืองต้นทุนมากซึ่งหากกะเขียนโปรแกรมเล็กๆที่ไม่มีความซับซ้อนอะไร ก็ไม่ใช่เรื่องใหญ่ครับ แต่สำหรับโปรแกรมใหญ่ๆ และพังขึ้นมาธุรกิจเสียหาย ผมอยากให้คนที่เข้าใจเรื่องเปล่านี้มาเขียนมากกว่า
ส่วนอีกข้อในเชิง Behavioral Interview คือคนที่ตัวเองคิดว่ารู้พอแล้ว มักจะเป็นพวกน้ำเต็มแก้ว

ในบล็อคถัดๆไป ผมจะอธิบายแต่ละหัวข้อแบบลงลึก ว่าข้อแตกต่างเหล่านี้เป็นอย่างไร และมันส่งผลกระทบต่อโปรแกรมที่เขียนอย่างไร

1 Comment

StackOverflow Pitfalls for Developers

I had a talk with a younger developer yesterday. We discussed that, nowadays, the most important quality of developer is ability to learn new things quickly. Most of the problems have already been solved somewhere, we just need to reuse it.

This reminds me of old time… (no not punch card, I am not that old yet)

When I first started programming, the Internet connection was scarce. I spent most of my time removing code line by line to find where the error was. Once found, I tried to make sense out of the error message. There was no one to ask.

When I didn’t know how to do anything, I consulted either text book or Help documentation. Googling was not that useful. When I found http://www.javaalmanac.com, I felt that I found a gold mine. (The site keeps pieces of Java code for solving problem.)

Life has changed. The developing environment nowadays has significantly changed, mainly

  1. Most problems have been solved – You can find 80-90% of the solution in the Internet. Most of them are with code, ready to copy and paste in StackOverflow.
  2. Open-source has (almost) everything – It is very rare that we need to build anything from scratch. Usage of framework or library is very fundamental for every project.
  3. Information overloaded – We have abundance of resources. We do not have enough time to digest them all.And they all come with different level of quality.

This greatly influences the way I work. In a good way, I am much more productive than I was (Yay!) In the bad way, I develop many bad habits over years, without realizing it.

Hoping that you will avoid the mistakes I made (and I see many others made), I would list them here:

    1. Not really read error messages- There was a time when I had a tendency to… google every error message I found, immediately.  It seemed to work for 80% of the time. But the 20% took me several hours (or days)  because I did not understand the problem. The worst thing is, when the same issue occurs again, I never remember it and has to Google it again.  This is because I never really understand what went wrong.A good example is Git, I had been using it for half a year without understanding the concept behind. When I see an error, a few seconds of Google will give me a “magic” command that solves everything. Of course, the magic doesn’t work everyday. And when it doesn’t, it usually causes me at least half a day.I learned this point from pair-programming with one of my colleagues. One moment when we ran into an error, he stopped and read it.  He REALLY read it before googling. When he saw something he doesn’t understand, he googled further and try to understand what really went wrong.

      Despite that, he usually finishes his stories quicker than others. He is, in my opinion, the most productive guy in our team. Of course, there are many factors. But one of the factor I guess is that he accumulated skill from really understanding of those errors. This skill allows him to avoid repeating the same mistake, and troubleshoot new errors more effectively.

    2. Ignore fundamental understanding of the language/framework – The ease of copy & paste makes it easy to “just do it” and move on. People start to think that they can use Angular after 30 mins tutorial. Yes, if you just want to make a Todo app. But to make a good design and avoid several hours of aimless debugging. You need to know more than that.A good example is when I first started was working in JavaScript. I didn’t know how variable scope work, so I accidentally override the global variable of the whole project.  I was stuck with another developer (who has equal knowledge of JS) figuring what went wrong for two days. We even thought that it’s because we saved the JS file in wrong encoding.Not understanding the fundamental will make you pay a lot in a long term. Invest your time to buy a good book that goes beyond simple tutorial & syntax. My small list of recommendation is:
      1. Java -> Effective Java
      2. JavaScript -> JavaScript: the Good Part (You can call me ‘old school’ guy, but read it)
      3. Angular -> Mastering AngularJS
    3. Copy & paste the code without understanding – There is a  saying that it takes you 200% of your knowledge to debug the code you write. So don’t do anything too clever, or you won’t be able to debug it.The same goes for copy & paste. If you don’t understand it, read it through first. Or you will pull your hair out when it breaks.I once found a bug that happens every 24th of December. When I asked other senior colleagues, they said that it happened in the last year too but no one found the root cause. Since there is almost no user in the system on that day, and they couldn’t reproduce it on 26th, no one bothers to fix it, meh…

      So I debugged it.

      I found a piece of code that has very strange variable names and different coding style. I didn’t understand what it does. So I pasted it on Google and found that piece of code on a blog with a very good explanation. It turns out that one of the variable that should be changed in that piece of code got the wrong values.

      Moral of the story? If you don’t understand how it works, don’t put it on your repository.

    4. Read everything – You understand it correctly. It is a pitfall to read everything.A lot of developers write blog, but not all of them are well-written. It is much faster to absorb the well-written material (like a good book) than reading multiple pieces of blogs written by different authors (with different style).I am not saying that you should unsubscribe those newsletter and RSS (if you still use it). But you need to be selective. Skim before you read it through.

      We have too much information today, most of them are duplicated. AngularJS tutorial is a very good example. And if you read a bad tutorial, bad practice will be with you for a long time.

In conclusion, don’t repeat my mistakes. Be better than me, be more efficient than me.

Leave a comment

Webstorm/Intellij Shortcuts

The proficient with IDE has high correlation with developer’s productivity.  One way to significantly improve it is to eliminate mouse usage and rely on shortcuts & keyboard.

In my opinion, the saved time (0.5-2 seconds) is not much but it avoids interruption in the “flow” of your thought.

Hence, I recommend all developers who work with JS (And IntelliJ/Webstorm🙂 ) to watch this video.

I summarize some of notable ones here (in Windows), categorized by their relation to make it much easier to “chunk” into your brain

Jumping between files (2:10)

  1. Ctrl + E = Open recent file
  2. Ctrl + Shift + N = Open file
  3. Alt + 1 = Jump to file navigation
  4. Esc = switch focus back
  5. F4 (on Project file navigation) = open the file and switch focus
  6. Shift 2 times = Find everywhere  (Use for finding menu item) ex.
    1. Show/hide navigation bar
    2. “Reopen project”
  7. Alt + Home = Open navigation bar

Class Navigation

  1. Alt + 7 = Jump to Structure
  2. Ctrl + F12 = Popup structure
  3. Ctrl + N = Navigate to class
  4. Ctrl + Shift + Alt + N = Navigate to symbol  (ex. Type “C.m” for method mxxx inside the class Cxxx)
  5. Ctrl + Alt + Left/Right = Navigate back and forth
  6. Ctrl + tab = Switcher
  7. Ctrl + B = Jump to declaration (better use Ctrl + Shift + I for the pop up of declaration)

Bookmark

  1. Ctrl + F11 = Set bookmark
  2. Shift + F11 = Open bookmark

Windows

  1. Ctrl + Shift + F12 = Hide all windows
  2. Ctrl + Shift + Left/Right = Resize the windows (doesn’t work on editor)

Selections & Editing & Jumping inside editor

  1. Selections
    1. Ctrl + W = extend selection
    2. Ctrl + Shift + W = shrink selection
  2. Navigation
    1. Alt + Up/Down = jump to previous/next class/interface/function declaration
  3. Editing
    1. Ctrl + Shift + Up/Down = move selected line(s) up/down
    2. Ctrl + D = duplicate line
    3. Ctrl + Y = delete line
    4. Ctrl + Shift + V = access clipboard
    5. Ctrl + / = comment/uncomment line
    6. Ctrl + Alt + T = Surround and add
    7. HTML
      1. Type “#myDiv>ul>li*10” and press Tab
    8. Ctrl + Shift + space = smart completion (for dynamic language like JS)
    9. Ctrl + Shift + Enter = Auto completion the line (put semicolon, bracket and go to the next line)
    10. Alt + Enter = Language injection
  4. Multiple Editing
    1. Alt + Shift + Click = Add more cursors
    2. Ctrl + Shift + Alt + J = Select all occurences
    3. Ctrl + Shift + Alt + T = Refactor
  5. Reformat the code
    1. Ctrl + Alt + L = reformat
  6. Live template
    1. One of the most powerful unused feature, See this for ideas.I’ll suggest setting this up for console.log/initialize your unit test/class/etc.
    2. Also, look for templates for your favorite library. For example, there is a live template for bootstrap which I really appreciate time-saving of typing those col-xxx-xxx for all sizes.

Want to go more?

  1. Plugin IdeaVim -> https://www.youtube.com/watch?v=UlREhZ-orlk
  2. Plugin AceJump -> https://www.youtube.com/watch?v=yK8eM50DsAY

Leave a comment