今天和下屬Y說了一個事業祕訣。

一般打工仔，如何決定如何排列工作的優先次序？
Y說，是按照上司交付的工作，再按其他因素的影響和關係來作決定。

我溫和地告訴他，若面試中我聽求職者答這問題，其實只算 Grade C 或C+的答案。
當然，更差的還有 D, E 及F Grade。
這答案只屬C Grade，因為還只算是 do the thing right, but not “doing the right thing"。

對公司最有價值的員工，是能從整個局勢整盤棋，去知道自己角色是什麼，和應做什麼。
簡言之是do the right thing，和think out of the box。
先做好自己，再進一步就局勢向公司提出意見，這是 B和 B+的分別。
A呢？A的員工，就是使同事也能和他一樣，從公司和大局角度想。
就算不全面，若一個員工除自己外能某程度 leverage 別人do the right thing，至少也值 A-。

D 的員工，就是上司交付他之後還要跟進，不足夠獨立；或甩甩漏漏。
E 的員工，是責任感不足，遲到早退或工作時間營私（e.g. 炒股、Facebook、副業、messaging）。這在普世都很普遍，還可勉強接受。聘請這類時是要連浪費的時間也計進去。
E不算最差因為還有墊底的。F，不合格的，是除了自己責任感不足，還影響和感染其他同事。今年做的公司包括我操刀的都炒了幾個這類。這類是普遍僱主就算不忍心也都贊成辭退的。

這模型的妙處是，越高階的員工，越多權力動用公司資源。也更易升職加薪。
道理是簡單：若你是僱主，你會擢升一個為公司著想甚至能激勵同事，也能明暸市場局勢的呢，還是只懂做好份內事的員工？
你會否給予更多資源一些主動思考和帶動有質素的策略的員工？

B 和A Grade 的員工，是可以做到「要錢有錢，要面有面，要權有權」的程度。
分別只在心態。
而這種員工，薪金比同等學歷普遍高50%。

而好消息是，員工的質素和學歷無關。
以前都試過有幾個我聘請的或下屬，學歷都有博士或兩個碩士或以上及名校畢業，多國語言，面試了得，但回想中他們只屬D Grade。

分享，互勉。

簡表、總結、關鍵詞
F：負面影響
E -> D：責任感
D -> C：獨立
C -> B：僱主角度、do the right thing、think out of the box、critical thinking
B -> A：感染力、Leadership
A -> S：專精、獨創性、演化力、
同Grade±：該關鍵詞的幅度、長闊高深

Like this, re-post.

 

Data Source: engadget

 

Jun 2012

Windows 7: 50%

Windows XP: 29.9%

Windows Vista: 8.32%

MacOS: ~8%

iOS: 2.4%

Others: 2.4%

July 02, 2012

Android 2.3 64%

Android 2.2 17.3%

Android 4.0 10.6%

Jun 01, 2012

Data source: engadget

When you have a crash log sent from Apple AppReview, the file is filled with Symbolic link.

In this scenario, it is very useful to use dSYM file to debug.

dSYM file will help you to map the symbolic file to the line number of the original code.

 

To make XCode 4.3 or above generate dSYM file:

1) Build Settings -> Build Options -> Debug Information Format = DWARF with dSYM

2) Build Settings -> Apple LLVM compilier 3.1 – Code Generation -> Generate Debug Symbols = YES

 

The location of the dSYM file is shown in the following screen captures.

這個slideshow需要JavaScript。

「善戰者，求之於勢，弗責於民。」孫子兵法.勢篇.51

大意是：真正懂戰的人，是在勢上尋求取勝之道，而不㑹苛責部下盡力與否。

管理，如是。
好的上司，是計算好全盤定局，而不是硬推員工 OT。
「多算勝，少算不勝」，管理與用兵一樣，都是運籌帷幄之中，即是，「未戰而勝」，不用打就知是否能勝。要打才知的，是庸才。這等於是準備打敗仗。
不禁想起ＣＹ。在特首選舉，他顯有未戰而勝之計。

Recently discovered a bug of iOS which will cause random crash.

According to researches, the crash will appear in the possibility of range from > 0.1% to 2%.

As most experienced programmer know, this is extremely annoying type of bug.

The annoying-ness is due to the randomness, which is very hard to trace and catch.

This type of bug may spending weeks to solve one.

 

[ Symptom ]

If console is available, the console output should be similar to

<Error>: *** Terminating app due to uncaught exception ‘NSFileHandleOperationException’, reason: ‘*** -[NSConcreteFileHandle writeData:]: Bad file descriptor’
*** First throw call stack:
(0x3302f88f 0x34fd4259 0x3302f789 0x3302f7ab 0x376dcd15 0x376ba2a3 0xb8cfd 0xd19ad 0x3556ecab 0x355687dd 0x35536ac3 0x35536567 0x35535f3b 0x330d322b 0x33003523 0x330034c5 0x33002313 0x32f854a5 0x32f8536d 0x3556786b 0x35564cd5 0x91fff 0x91fb4)
Jun 6 19:46:30 unknown ReportCrash[270] <Notice>: Formulating crash report for process APP_NAME[268]
Jun 6 19:46:30 unknown com.apple.launchd[1] <Warning>: (UIKitApplication:com.APP_NAME.APP_NAME[0xdd2e]) Job appears to have crashed: Abort trap: 6
Jun 6 19:46:30 unknown SpringBoard[23] <Warning>: Application ‘APP_NAME’ exited abnormally with signal 6: Abort trap: 6
Jun 6 19:46:30 unknown ReportCrash[270] <Notice>: Saved crashreport to /var/mobile/Library/Logs/CrashReporter/APP_NAME_2012-06-06-194630_IPAD_NAME.plist using uid: 0 gid: 0, synthetic_euid: 501 egid: 0

The crash log should be like:

Incident Identifier: 16C417D3-236D-473E-B10B-A9072AE69273
CrashReporter Key: e69210ad08c63842187ed72017cd40c0675b8b69
Hardware Model: iPad3,3
Process: APP_NAME [11251]
…
…
0 libsystem_kernel.dylib 0x352f8004 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x352f81fa mach_msg + 50
2 CoreFoundation 0x32e053ec __CFRunLoopServiceMachPort + 120
3 CoreFoundation 0x32e04124 __CFRunLoopRun + 876
4 CoreFoundation 0x32d8749e CFRunLoopRunSpecific + 294
5 CoreFoundation 0x32d87366 CFRunLoopRunInMode + 98
6 CFNetwork 0x36b59e14 CFURLConnectionSendSynchronousRequest + 340
7 Foundation 0x374854a6 +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 242
8 APP_NAME 0x0006a6fe 0x26000 + 280318
9 APP_NAME 0x0006a5fa 0x26000 + 280058
10 APP_NAME 0x00068034 0x26000 + 270388
11 APP_NAME 0x00067bc6 0x26000 + 269254
12 UIKit 0x35370ca4 -[UIApplication _callInitializationDelegatesForURL:payload:suspended:] + 1176
13 UIKit 0x3536a7d6 -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 402
14 UIKit 0x35338abc -[UIApplication handleEvent:withNewEvent:] + 1004
15 UIKit 0x35338560 -[UIApplication sendEvent:] + 48
……
……

 

[Solution]

The cause of the bug, is traceable back to the [NSURLConnection sendSynchronousRequest:returningResponse:error:]

responseData = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error];

The solution is:

1. Check if the URL opening is a redirecting URL. If so, change it to be non-redirecting.

2. Change the synchronous request to asynchronous request, with delegate.

3. Add this implementation in the handling:

– (NSURLRequest *)connection:(NSURLConnection *)connection

willSendRequest:(NSURLRequest *)request

redirectResponse:(NSURLResponse *) redirectResponse{

return request;

}

Done.

承上題，有關 PM 與牧養。

從這角度看，㑹有新共通點發現。
男性與女性，需要不同牧養角度；對 PM 的反應也大致相同。

男性較接受 Facilitator 的牧養，也是較接受 Facilitator 的 PM。
女性則較接受 Fatherhood (Motherhood) 的牧養 / PM。

不過，Facilitator 和 Fatherhood 這兩者本身是相違的。大多數人只徧向一樣。需要經驗磨練才兩面都兼顧到。

純粹如是我聞。

有時，真的覺得，做PM和在教㑹中做牧養 (e.g. 組長)，感覺很像。

好的PM，不是單單使事情做得好和有利，而且當中很重要的是人的元素。

下屬覺得你關心佢，關注佢利益，感受到佢的感受，同佢有理心，和最基本的，當佢係個人，自自然然就㑹同你賣命，出事都唔㑹走左去，而去你共同進退。

好的PM，有點像個大哥哥 / 好爸爸。教㑹中的牧養，也是一樣。：）