sticky~how many years C experience...unimportant!

It's possible to code C for years without using pointers except string functions.

It's possible to code C++ for years without using virtual, new/delete, template, operator overloading or even class.

It's possible to code python for years without creating classes.

It's possible to code java/c# for years without any threading (beyond locking), or reflection

It's possible to code perl for years without using hash or regex.

It's possible to code SQL for years without writing outer joins. I guess I wrote lots of mysql queries without any join.

enough c# mileage accummulated@@

Your mileage will show in IV and in projects, but IV is way, way more important than real project performance -- You only need to be barely competent to get your job done, solving common problems at your pace (though at Baml my own pace was slower than other team members). No need to be competent to solve all tricky problems, some are too tough for everyone. But you better ace the IV.

- - I still feel less familiar with some everyday tasks than my c# veteran colleagues.
- - i did rather few complete projects like Guardian and many enhancement projects. In contrast, veteran c# guys did more big projects. The number of years isn't as important as complexity and variety of challenges. VARIETY -- for eg a web dev expert (or a DB-centric c# coder) isn't really a complete c# expert.

- - wpf is a specialized skillset, like swing, or web dev or sockets. I didn't get a lot of wpf hands-on mileage yet.

- - wcf is another specialized skillset. I lack mileage.
- - assembly, appdomain, GAC

= = people agree that I can get my job done and meet most technical challenges, even if non-trivial. ("tactical")
= = explaining, justifying my design choices - not always convincing. Not only c#, but java too.

= = excel integration is one of the most valuable among the specialized c# skills. I have some experience.

+ + When presented a new c# challenge, when pushed to the frontier of my c# know-how, I am competent to construct a basic "infrastructure" and then search on-line for the missing pieces to complete the loop meeting the challenge

+ + competent with most everyday troubleshooting.  Some troubleshooting is beyond my current skill but I feel many are hard for my veteran colleagues too. If my colleagues can solve 50% of the tech problems, then my level is close to that. This competence comes from mileage i.e. real world projects. The more projects one takes on, the more competent.

+ + like Venkat, I did practice with some hot c# features like threading, closure, remote debugging ...

+ + much more confident with MSVS than before. Perhaps comparable to my Eclipse confidence.
+ + on some of the hot but purely theoretical IV topics (fake mileage), I have read up quite a bit and appreciate their nuances. I can follow most discussions on these topics -
*GC, dtor, finalizer
*threading
*value/reference types
*dynamic type

for complex joins, I always favor outer join

My habit over the last 12 months is to always favor outer join over inner join

I feel outer joins always provides more information than inner joins. Inner join output is a subset of outer join output. I could be wrong.

It's easy to filter outer join result to get inner join result.

java thread pool(phrasebook

* Runnable.java -- the tasks/jobs lined up are objects implementing Runnable.java. It's counter intuitive to me that the threads in the pool by definition implement Runnable.java, and the jobs also implement Runnable.java -- see blog post [[ wrapper object of "me" as a field in me ]]

* queues -- i think thread pools need a FIFO queue to hold the jobs/tasks. Usually it's a blocking queue.