What constitutes 'good' code I find can be rather nebulous.

Obviously code that works is a good start.
Code that is maintainable is most likely second.
Code that make good use of the available resources third.

Too many times I come across 'senior' people who believe that cycle efficient code is 'good' code. This is ok assuming it is a small sized project - 2k of highly optimised assembler is not a big investment. For those that have had to maintain larger assembler projects, I dare say most people would like to see common methods for passing vars to subroutines and a good structure with comments. Trying to add features to highly optimised code is extremely difficult and normally necessitates a rewrite.

I had one instance where in an access control system the lookup for the user information was done by a linear search. Obviously once the number of users grew, the search could become rather slow. A 'senior' person suggested - 'do it in assembler!'. Another suggestion was to use a better data structure and search method to improve performance. The senior person cried 'it's all too complex!'. Unfortunately a standard 'smarter' search in 'c' yielded better performance than brute force in assembler.

I would suggest a good embedded systems programmer has a grounding in engineering and computer science to appreciate the whole problem.

I think a can of worms has just been opened!