[quote larrylujack]
no offense, dude, but software engineers are a dime a dozen…literally, so don’t take yerself so seriously….
[/quote]
Sounds like typical MBA think. Completely ignores skill levels, experience, and ‘rate of production’. Rate of production is hard to quantify, though the most ‘popular’ and overused is SLOC/hr. The reason why SLOC/hr is not that good is that some software engineers can write the same function in software with far fewer SLOC than another.

Kind of reminds me of my experience where I was laid off. A new VP of the division came in and chopped the ‘highly compensated’ software engineers and other ‘highly compensated’ employees, except ironically; management layers. He completely ignored the capability of the people he laid off and didn’t allow projects to ‘bid’ on people being laid off on the condition that they release a certain number of their own.

The result was a lot of bad feeling, since the “laid off” were long-timers that were responsible for a lot of what the company had come up and were the ‘go-to’ people for technical questions.. what is the use of company loyalty? Now the company has re-hired several of these people, including myself, as ‘consultants’ or ‘part time’ to get the work complete. Some of them refused to come back to work for the company.

The whole purpose of the layoff was to reduce the cost structure so that the burden rate was less.. after the layoff, the burden rate actually went up — oops.

[quote flu]
even with some of the easiest/stupid shit totally fvcked up like method names completely misspelled (getRecievedPakcetTipe()) in a public API you give to customers, after supposedly it was code/design reviewed, blocking/synchronous calls across networks with high latency ???
[/quote]
The last one, is one I have seen too much of.. as well as very poorly structured code. Code that almost looked like.. “well, lets try this.. no that didn’t work.. lets try this.. no that didn’t work either” style of software engineering. I have also run across several multiprocessor race conditions in code, not protected by a semaphore/guard.

When I was going through College, I used to TA software engineering courses. Through experience, I found that some people had an innate ability, some people were more ‘mechanical’ about it and others just could not ‘get it’.