patrick.net

drew_eckhardt says

For example, there's a lot of evidence suggesting that the abilities to understand indirection, parallelism, and recursion are inherent aptitudes for software people.

Computer science departments attempts to teach them often fail and I wouldn't attempt to hire some one (even an intern) who didn't grasp them.

I think computer science departments should not teach languages like Java and C++. Instead, they should pick a statically-typed multi-paradigm language like OCaml, F#, and Scala.

I doubt parallelism can be tackled successfully without a good understanding of functional programming. Likewise, I feel one needs to leverage meta-programming to be productive.

BTW, words cannot describe how wonderful F# is. Microsoft certainly has a winner here.

CaptainShuddup says

I can't find a kid to mentor to save my life, not even on a Bet.
1995 one could have filled a Colosseum with hopeful quick studies.

This might be a win win for all concerned

wthrfrk80 says

I think the claimed "shortage" of scientists and engineers in America is propaganda.

As an ex-engineer I can say that this is 100% true and has been the case for decades now.

Ruki says

The boomers are retiring.

They have enough money to retire???

Rin says

SF is even more expensive than Boston. Yes, that's CoL hell on earth & the view of the Bay isn't enough for one to get price gouged, as badly as that. Next, aside from the lack of wintery snowstorms, does SF really have more to offer than any municipality in the northeast corridor?

The same could be said for any city/metro enjoying a virtuous cycle economy. Like I said, move on over to Texas if you prefer a different flavor. It's entirely possible one of those Texas metros could eventually become a virtuous cycle economy too...though the smart money is short on that outcome. Same reason all the US top service industry HQs aren't in Des Moines and Kansas City now, like was predicted by the demographic pundits and other self interested smarty pants circa 1980.

Peter P says

BTW, words cannot describe how wonderful F# is. Microsoft certainly has a winner here.

I'll wait until someone discovers "B#".

Ruki says

That is changing and will drastically change in as little as five years, when massive labor shortages kick in. The boomers are retiring.

Given the current employment landscape with random layoffs at NASA, Motorola, and various other enterprises, on/off, I don't think enough boomers will have cash in the eggs nest to officially retire in mass. Instead, if there's a short term labor shortage, they'll be able to work as contractors, until the company is fully re-located to Vietnam, if it's not Texan bound.

zzyzzx says

As an ex-engineer I can say that this is 100% true and has been the case for decades now.

What are you doing these days? The mechanical engineering profession is being de-skilled, automated, and outsourced. I'm thinking of getting out.

To the original topic: Science and Engineering careers are not obsolete, but they have continued to evolve significantly. I continue to be unable to hire for open engineer roles for a few reasons (listed below in no particular order):

* Most applicants are over specialized and uninterested in generalizing their knowledge. What is valued more than anything now is flexibility; we source super-specialization when needed from contractors.

* Anyone with more than 5 years experience wants to "be a manager", even though they have all the people skills of a feral labradoodle.

* Many are offended at the notion that they have to act as Business Analyst as much as Genius Technologist in order to be successful. We can outsource/offshore/automate the purely deterministic part of your job, but the reason we need an actual person is for inductive, heuristic, and judgmental skills. Sadly, so many Engineers seem to think that those things are "someone else's job".

* Testing. I can't tell you how many applicants (in software specifically) I've binned simply based upon their reaction when they realize that I consider testing skills to be among their first and foremost fundamental skills. Somewhere along the line something went very wrong in our collective approach to SW engineering and development whereby engineers and programers think they are "too valuable" to test. Any hint of that and I stamp the candidate as 'rejected'.

* Most of the rest "want to be an architect" or any of the derivative "I don't want to code" (again in software in these cases; less of a problem in hw). I pretty much reject anyone claiming they are a "software architect" 95% of the time simply based on how they present themselves in that context. And "I don't want to code" is code itself for "someone else should do the work". There are many forms of coding, and being able to go all the way to the detailed solutions is essential to engineering, so these people are all disqualified.

Our problem is not that there are a surplus of engineers. It's that there are a surplus of people educated and experienced in some form of engineering discipline who believe they are entitled to ignore the commercial realities of what pays their salaries.

Randy H says

Like I said, move on over to Texas if you prefer a different flavor.

If I were to stick to IT, instead of hedge fund stuff, I'd move to TX, despite being a northeast person, for the sake of my career, not for the weather or barbecue. All and all, what's happened in places like Boston or NYC is that there's a landed class, those who'd made money in the past (or work in finance/surgeons/actors), vs present-day professionals who're stretched to make ends meet. Thus, the fundamentals for the NE is that labor plus CoE costs are high and thus, not worth it for anyone but the executives to stick around. Whenever a big defense project in MA wraps up, the next cycle starts in Dallas, and then, the accountants can immediately show a 15% reduction in overhead w/o showing a loss of delivery. This has been on-going now for almost a decade.

Rin says

All and all, what's happened in places like Boston or NYC is that there's a landed class, those who'd made money in the past (or work in finance/surgeons/actors), vs present-day professionals who're stretched to make ends meet. Thus, the fundamentals for the NE is that labor plus CoE costs are high and thus, not worth it for anyone but the executives to stick around.

True. See the following thread:

/?p=1214445

Randy H says

Our problem is not that there are a surplus of engineers. It's that there are a surplus of people educated and experienced in some form of engineering discipline who believe they are entitled to ignore the commercial realities of what pays their salaries

Be brutally honest (basically read 'em your essay) with those you telephone screen, and you'll find that person. The problem is that in many cases, what the job seeker observes is the sort of poor communicative or dysfunctional behavior of organizations, and thus, go back into their former shell whether it be 'Architect', 'DBA', or 'I'm too good for QA'.

Again, the same arguments I've heard 3x cycles before. There are more aspects to value than non-GAAP earnings, my friend.

Rin, I manage an organization a bit larger than you're probably imagining. In any given week we are probably doing 25-50 phone screens, so I obviously have to rely upon a recruiting staff to do that. Plus, I'm sourcing globally, so I'm hiring only about 40% in the SFBA, and also in MI, NH, Singapore, Shanghai and Europe (the latter as seldom as possible for obvious reasons).

And I far prefer Michigan to Texas as it commands a distinct advantage on the variables you cited. I still have some workforce in TX, but we're not replacing those who leave and are instead shifting those roles to MI.

Randy, here's what I've found to be difficult in terms of interviewing or making a lateral move to another company.

Questions like 'What do you want or see yourself doing?' is too basic and broad stroke to get a meaningful response. And thus, the pre-screening becomes a type of farce of HR theatrics.

A better approach is for the recruiter to state the company's or dept's requirements. Then highlight the issues of the week, quarter, or year. Afterwards, you can let the person try to sell himself. Eventually, if the person discovers that he has to 'code', then he won't even bother with the 2nd interview.

Randy H says

Most of the rest "want to be an architect" or any of the derivative "I don't want to code" (again in software in these cases; less of a problem in hw). I pretty much reject anyone claiming they are a "software architect" 95% of the time simply based on how they present themselves in that context. And "I don't want to code" is code itself for "someone else should do the work". There are many forms of coding, and being able to go all the way to the detailed solutions is essential to engineering, so these people are all disqualified.

Interesting you say that. When I do software architecting, usually it means coding up and down various levels of abstraction. One would think engineers only want to code... oh well.

Rin says

A better approach is for the recruiter to state the company's or dept's requirements. Then highlight the issues of the week, quarter, or year. Afterwards, you can let the person try to sell himself. Eventually, if the person discovers that he has to 'code', then he won't even bother with the 2nd interview.

I think an intuitive process work better. Unless you are hiring a salesperson, selling is not necessarily a useful skill. Besides, don't forget you may have to work with that person. Work cultural concerns are equally relavant.

I always try to ask unexpected questions, or even questions for which the "expected" answers are wrong answers. You need to probe the mind.

Randy H,

I'm in mechanical engineering and not software, but I find your comments helpful. Thanks for sharing them. My two cents below.

Randy H says

* Most applicants are over specialized and uninterested in generalizing their knowledge. What is valued more than anything now is flexibility; we source super-specialization when needed from contractors.

That's why I don't want to go on to graduate school...too much specialization. I might actually become *less* employable.

Randy H says

* Anyone with more than 5 years experience wants to "be a manager", even though they have all the people skills of a feral labradoodle.

Not me. I like doing technical stuff and I realize my people skills aren't so great.

Randy H says

* Many are offended at the notion that they have to act as Business Analyst as much as Genius Technologist in order to be successful. We can outsource/offshore/automate the purely deterministic part of your job, but the reason we need an actual person is for inductive, heuristic, and judgmental skills. Sadly, so many Engineers seem to think that those things are "someone else's job".

I've been guilty of this, yes. I think it comes from spending 4-5 years in brutal technical education. Plus there's sort of a "geek culture" where technical ability is the "be all and end all."

Randy H says

* Testing. I can't tell you how many applicants (in software specifically) I've binned simply based upon their reaction when they realize that I consider testing skills to be among their first and foremost fundamental skills.

Randy H says

Most of the rest "want to be an architect" or any of the derivative "I don't want to code"

Even though I'm a mechanical I've done some coding and debugging. I actually find the, coding, debugging, and testing part of the job very satisfying. Does that make me a masochist? ;-)

Peter P says

I think an intuitive process work better. Unless you are hiring a salesperson, selling is not necessarily a useful skill. Besides, don't forget you may have to work with that person. Work cultural concerns are equally relavant.

I always try to ask unexpected questions, or even questions for which the "expected" answers are wrong answers. You need to probe the mind.

In this case, when I say selling, I mean the candidate presenting his background for the needs of the dept or job function.

And thus, within that context, you can probe the mind for 'tunnel vision', being 'too high level', etc.

But using questions like 'what's your weakness?' with the expectation that the person will respond that 'he works too hard' is a game of theatrics.

Too many people try to say what they think you want to hear in an interview. Sometimes you have to ask multiple questions and interpolate what they really think. Sometimes you have to confront them if the answers are not consistent. Sometimes you may as well ask them to do something impossible and see if they challenge you.

Rin says

In this case, when I say selling, I mean the candidate presenting his background for the needs of the dept or job function.

And thus, within that context, you can probe the mind for 'tunnel vision', being 'too high level', etc.

Perhaps. But the candidate is usually well-coached to answer this. I prefer raw answers. If you let the candidate know as little as possible, don't you get more sincere answers? It will be more difficult for him to game.

Rin says

But using questions like 'what's your weakness?' with the expectation that the person will respond that 'he works too hard' is a game of theatrics.

Ask for a weakness that he thinks you may not like. If he gives crap like "working too hard" ask why he thinks you do not value hard work. It is never about the answers. Always the responses.

Again, I always use "he" as the default personal pronoun. "He" really means "he or she."

Peter P says

Rin says

But using questions like 'what's your weakness?' with the expectation that the person will respond that 'he works too hard' is a game of theatrics.

Ask for a weakness that he thinks you may not like. If he gives crap like "working too hard" ask why he thinks you do not value hard work. It is never about the answers. Always the responses.

Ok, what if I said that my greatest weakness was that I didn't take easier courses to raise my GPA from a 3.6 to a 3.8 because other premeds did that and as a result, now have a better shot at Johns Hopkins.

And thus, the extra coursework was irrelevant to the final game of admissions. Plus, it's not useful for industry and would mostly be applicable to graduate school/PhD admissions but then again, those programs don't expect 3.8s vs medical or law school.

I'm pretty sure you wouldn't want to hear the above but for the most part, that was my only weakness for my entire career. Anything else, about roving deadlines, changes on the fly, etc, were all lies and tall tales. Plus, taking badly about prior managers/directors is a no no.

But that sounded more like academic decisions than strength/weakness. You are just trying to "spin" your "follow your heart not the evil system" strength. You would need to convince me how is that a weakness you think I may not like. :-)

Peter P says

You would need to convince me how is that a weakness you think I may not like. :-)

Ok, so then I'm perfect, have no flaws, and should replace your CEO.

Thus, I'm a megalomaniac with narcissistic personality disorder :-) ! There's a weakness!

I think I may like that answer! :-)

Peter P says

I think computer science departments should not teach languages like Java and C++. Instead, they should pick a statically-typed multi-paradigm language like OCaml, F#, and Scala.

I think computer science programs should have students run all their programs on 30 year old hardware so they really have to understand what's going on to get good performance. way too many people think throwing more power at the problem is always the solution when really what they should be doing is thinking a little harder about what they're trying to do.

and it should also have the students go through some kind of operational support program so they get a complete idea of what it means to write software and design systems. unsupportable software might as well have never been written and the only way they discover it's unsupportable is when they're on the hook for fixing it and dealing with pissed off customers.

We need performant design not just code. Slow computers will not be useful. Instead it is more helpful to make the problems larger with millions of data points as opposed to five.

Peformance nowadays means scalability not saving 3 CPU cycles.

kids need to start small and work up. saying that performance is about scalability is great, but it's a meaningless comment without additional context. what does it mean to scale, and how are you doing it?

throwing more hardware and more power at a problem is one way of doing it, and many times it will work...until suddenly it doesn't work or can't be done because no one wants to go buy another 20 servers and the infrastructure to support those servers.

saving CPU cycles, reducing your IO needs, and shrinking your memory footprint is always a good thing, and it's not something that the kids these days think about because no one forces them to think about it.

Because they really need to think about other things like time to market and maintainability.

I guess the answer is perhaps those jobs are obsolete but does it matter? All that does is push out the history majors when the engineers take the business jobs.

I have a lot of respect for history/philosophy folks. Just not economics majors.

There was a time when I was a history major and economics/finance is a much tougher major than you might think!

jessica says

All that does is push out the history majors when the engineers take the business jobs.

This is already starting. Here's my post from another thread on women in the sciences ...

Here's one from the MIT class survey (http://gecd.mit.edu/sites/default/files/GSS2011.pdf). Realize, MIT is a top tier STEM focused college, not a liberal arts place like Dartmouth or Swarthmore. If you total up the number of recruits from Finance & Management Consulting positions (i.e. Morgan & Stanley, JP Morgan, McKinsey, Boston Consulting Group, Bain, Deloitte, Citigroup), you'll see that those careers make up 40+% of MIT graduates (these are students who're not attending grad programs). You'll find similar results for the past number of years of surveys. Then, collate that with my personal anecdotes (of women leaving the sciences, even if they'd studied it in school) ... if STEM work was so great then why is it that even from MIT, an engineering school, as oppose to Wharton or London School of Economics, the monied professions attract a serious volume of candidate placements?

omgbacon says

saving CPU cycles, reducing your IO needs, and shrinking your memory footprint is always a good thing, and it's not something that the kids these days think about because no one forces them to think about it.

Peter P says

Because they really need to think about other things like time to market and maintainability.

Extra time spent writing tight efficient lean code that is easy as possible to understand will reduce your time to market by reducing the test/fix cycle dramatically and increase your maintainability in the process. Bloated sloppy techie geekie gee whiz this is cool code or slap it together any way you can to get it out the door code doesn't. That's what I've always found to be the hardest thing to teach not very experienced coders. You will spend a hell of a lot more time tweaking code than writing it in the first place. Going back and figuring out how sloppy code works time and time again takes forever.

bob2356 says

Extra time spent writing tight efficient lean code that is easy as possible to understand will reduce your time to market by reducing the test/fix cycle dramatically and increase your maintainability in the process.

bob2356 says

You will spend a hell of a lot more time tweaking code than writing it in the first place. Going back and figuring out how sloppy code works time and time again takes forever.

Those are lessons I have learned the hard way!

freak80 says

Those are lessons I have learned the hard way!

I was lucky. The first place I worked, back in the days when bits counted, was obsessive to the point of anal retentive about clean code. Later when I got assigned to get some horror show code working that came from a company that cut and ran on a project I really learned why.

freak80 says

Those are lessons I have learned the hard way!

Unfortunately right now that's the only way those lessons are ever learned, and that's why experience matters a lot.

If people aren't writing clean code to begin with, and you're swapping out developers project by project because you're "Agile" and see programmers as fungible commodities what you end up with after a few years is a giant mess of spaghettified crap where the only thing you can be certain of is that touching any part of it will have results that no one can predict.

Managers and BSAs don't know because they usually aren't technical enough and even if they are they don't deal directly with the code. The developers who are there don't know enough and are usually new enough that they're not going to rock the boat...and if they do know enough they're not making any noise because they've long since given up trying to push through any change that would make things better because they know the only thing anyone cares about is time to market and new features.

It's like one of the first rules of IT: beware of bandaids. If you don't do it right the first time you most likely will not get a chance to fix it later. Design your bandaids to break in the short term. You get one chance to get it right.