With IBM's Santa Teresa study showing 40% more productivity from employees with quiet private spaces, those open offices are costing share holders a lot of money,
In a big, growing company 40% of a young engineer's $200K annual package is $120K 40% of a mature staff engineer's $600K annual package is $240K
Most HR departments now days demand a bachelor degree or better, just to be able to say hello
Most HR departments where software is a big part of their products (including Amazon, Apple, Facebook, and Google to use a few household names) ignore that written requirement when hiring experienced software engineers.
uh, what personal time do you have if you're putting in 60-80 hours a week? idiot
60-80 hours a week allows plenty of personal time. 168 hours in a week leave 112-119 waking hours with 7-8 hours of sleep each night. Subtracting just 60-80 hours leaves 32-59 hours for other things. That's a lot when you don't waste it on low-value activities like watching TV or commuting far because you chose to spend your housing budget on a larger home farther from work.
Working 60-80 hours a week for my second startup I learned to fly, made 168 skydives and 30 BASE jumps the year I counted, snowboarded some, and built a pair of stereo speakers.
OTOH, 105 hours a week for a few months at my fourth one I didn't even have time to dine with my wife. That's too much.
Moving somewhere outside fly-over country where software is core to businesses not a cost center does more for salaries than studying COBOL.
New grads at the big Silicon Valley tech companies are getting $170-$190K packages - like $115K salary, $100K signing bonus, and $200K restricted stock package vested over 4 years.
$2500 apartment rents and a 9.3% state marginal tax rate take a big cut out of that although it's still a net win.
>Honestly, the best thing to do in IT once you hit a certain level is ask yourself "Do I want to be a manager". If the answer is no, you essentially have to quit and go be a consultant.
Hardly, you just have to work someplace you're appreciated. Such organizations have engineering roles up to the VP level.
Principal Engineer is usually equivalent to a director, Distinguished Engineer VP, and Fellow somewhat higher.
Consider Microsoft - Principal Engineer is level 65-67 position like a director. Distinguished Engineer is a level 70 position like VP. Technical Fellow is level 80.
Such positions involve leadership but not people management and handle bigger technical problems than the ones companies delegate to consultants.
The problems are noise and interrupts. For simple problems less communication is better because minutes lost by an engineer using Google instead of his friend make a smaller impact than the fifteen minutes of context switch overhead which can result for the person interrupted. When more communication is needed people can always grab a conference room.
IIRC IBM's Santa Tersa Laboratory - Architectural design for program development lists a 40% throughput delta for engineers in quiet spaces provided by enclosed offices or with partitions at least six feet high.
With fully burdened per-engineer costs that can break $200K per annum open offices can waste at least $58K (I don't recall if the comparison was stated as 140% for the good performers implying you get $142.9K of work for $200K from slow ones or slow movers loose 40% of their throughput and don't do $80K worth of work) per engineer per year and cost more than closed offices.
_Peopleware Productive Projects and Teams_ by Demarco and Lister provides some anecdotes and hard numbers in chapters 8 "You never get anything done around here between 9 and 5" and 9 "Saving money on space."
Comparing coding wargames participants who performed in the first and fourth quartiles
57% versus 29% have "acceptably quiet" space 62% versus 19% have "acceptably private" space 38% versus 76% do not have "people often interrupt them needlessly"
Median time to complete the programming tasks was 2.1 times the best and bottom half as a whole 1.9 times the top half.
Participants with acceptably quiet spaces were also one third more likely to produce zero defect work.
UPSes do nothing about emergency thermal shutdown which isn't uncommon in laptops when you use them for real work.
They do nothing about the hard power cycle needed to clear certain software failures. As shipped my laptop running Windows 7 often hung with a spinning cursor and wouldn't bring up a task manager. Occasionally it hangs solid under Linux, usually when resuming from sleep.
Depends on the situation. My current employer is in the process of outsourcing engineering to India, and keeping the US engineers on for varying periods of time (3-9 months) to facilitate the transition. There are incentives to stay through the end, but many have decided it's better to get out now. There is no bridge to burn, and people that are leaving already have new positions elsewhere when they resign. What is the possible incentive to give more than one or two day's notice?
1. You may care to work for and/or recruit people from that company and not want to make their lives worse. 2. The company may be wrong.
A year after a big company acquired a startup I worked for they decided to schedule the product's end-of-life, send it over seas for maintenance, and close the office.
1. I recruited a project manager and two engineers from that group to work for my next startup and joined the PM and one engineer at the one which followed that. 2. The company wasn't happy with the quality of the outsourced engineering and had to hire people back as high-paid consultants 3. While the competing group didn't care for the product the customers did, kept buying, and got the end-of-life pushed farther into the future (a few times IIRC)
With leadership aptitude you can multiply contributions from people around you.
Without leadership skills your contribution to the bottom line is limited to what you can do personally.
When hiring an expensive senior engineer I want one with leadership skills. If I can't get that I'd rather have a less senior engineer likely to do as well or better as an individual contributor (because the work is more novel to them and likely to have them operating at a more optimal psychological arousal level) who I'm more likely to mentor into a leader than some one in industry long enough without signs of showing aptitude or motivation to lead.
As others have noted, leadership and people management are different things. I don't expect engineers to be managers or vise-versa.
>Despite many accomplishments, published papers, and more, I cannot seem to get past the canned hiring process and actually get before a hiring manager.
With a history like that you shouldn't be going through a canned hiring process.
You're doing something wrong.
Talking to former co-workers and moving into positions at companies they've vetted as decent places to work is often a great deal for all parties involved - you get a good job, work with the same excellent people again, and their company gets a known well-performing quantity. That doesn't work as well when you've progressed to leadership roles too far beyond your peers or have other career goals that are too different like making enough to cease working for money at which point you start your own companies. I suspect new peers you'd like to work with again make that a temporary situation but have yet to verify.
Where that's not reasonable as a senior person you should be having casual encounters with technical directors (in big companies only; at small companies you want to go up the food chain to some one more able and willing to speak about the business), VPs of engineering, or CTOs in person (coffee is popular) or on the phone in which both parties get a feel for each other and determine whether a long term relationship is worth pursuing at this time or in the future. A decent linkedin presence should be enough to net this with inbound contacts directly from executives in young companies and from recruiters for larger organizations.
Those recruiters fall into two broad categories - keyword matchers taking a shotgun approach, and more targeted ones that have a better understanding of how things work and what your CV implies. The former usually don't have anything interesting to offer and I don't have much experience dealing with them. The later will make introductions. Some will try to funnel you directly into a hiring process which begins with a technical phone screen, but any place you want to work (executives recognize engineers' importance to the bottom line and consider you worth their time) you can get away with not doing technical interviews on the first date and push for a personal introduction.
When the hunger comes I can stick around for dinner after which it's more convenient to keep working at my desk until I'm at a convenient stopping point (however long it takes) or I can head home, make something or wait for my wife to do that, and by the time I've eaten switching back into work mode would be too inconvenient so it waits until necessary the next day..
By the time I got there in 2006 Microsoft was issuing restricted stock units - regular stock that you gain control of as it vests. When I went to Amazon I got RSUs there too. Valley companies seem fond of them as well.
Options today are mostly for startups where the current value is approximately zero which means there can't be a down side; although it's usually possible to convert those to restricted stock via early exercise, at which point you can make an 83(b) election to establish a low basis and start the clock ticking on the year after which any upside will be taxed as capital gains.
OTOH, employers spend less money when they're "giving away" $1 snacks and drinks than when engineers use 15 minutes of their time (70-$100 in fully burdened costs is not out of line) for a round trip to the corner convenience store which means less time left to work in a day.
>As an example: I work with a developer who is 10 years my senior, but still doesn't understand how to write concurrent code and cannot be trusted to use a revision control system without causing a mess that somebody else will have to clean up.
The developer in question just isn't competent. Concurrent programming dates to at least 1950 and SCCS came about in 1972.
>So, how do my fellow Slashdotters handle situations like this?
Avoid them where possible and work around the damage. For instance good test automation will limit how long their mistakes go undetected.
>How do you help somebody like this to improve their skill-sets?
You don't. Understanding concurrency is one of the programming aptitudes which can't be taught.
The fundamental problem is that this is a religious issue for both engineers and managers. People generally don't believe until they personally witness the miracle of rapid development with predictable schedules and low customer visible defect rate.
Working solutions in order of increasing time + difficulty:
1. Quit and either start a new team or join an existing one with decent development practices (I insist on a code and test process walk through of every company I consider joining to avoid unpleasant surprises. Obviously this fails for groups yet to build a product, and sometimes teams panic when pivoting and abandon reasonable practices).
2. Get promoted to a leadership role while you remain hands on. Tell every one else to do the right thing like you're doing - getting people to buy in is easiest when you're not making them do something you won't like the case would be with a non-coding manager. Most people fall into line with direction from above. Peer pressure works for most hold-outs. Any one not getting with the program can be replaced.
3. Do the right thing on your code. With your process producing a faster more predictable release cycle you'll have higher productivity and can take over an increasing fraction of the product so the bad people with bad process have less impact.
Applying test driven development variants to new features/subsystems/products helps a lot here because it makes shipping without good test coverage and short predictable cycle times impossible because no product code exists without the necessary infrastructure. While a "code complete" milestone may be farther into the future depending on how that's defined the total time to deliver the project will be lower and ultimately it's the ship date that matters.
Do the same for bug reports. Every reproducible bug gets an automated test case (if it broke the first time it's complicated enough to break again).
After a couple years you should be in good shape with enough infrastructure that the cost to add test cases is effectively zero before their benefits are considered (Perhaps most notable is that the requirement for incremental testing leads to cleaner interfaces which make complexity more linear with respect to project size. That in turn produces a lower defect rate, faster turn around time on repairs, and makes defect rate/time to repair more constant and predictable) and you don't have to worry about new people (or old people who haven't touched a piece of code in a while) breaking things accidentally.
Here are some things which don't work:
1. Talking to your co-workers about doing the right thing
2. Providing anecdotes (personal and otherwise) from other companies about the benefits
3. Buying everyone a copy of a book like
_The Clean Coder: A Code of Conduct for Professional Programmers_ by Robert C. Martin
Quote: The jury is in! Te controversy is over. GOTO is harmful And TDD works
in their choice of print or Kindle edition with the direction to read it on "company time."
4. Doing the right thing and providing metrics on things like defect rate, time to repair certain classes of bugs, number of release candidates for a feature, etc. This can be very striking - memory corruption bugs made reproducible by the test environment so you fix them in 30 minutes versus three weeks for co-workers' similar bugs, a major subsystem with no QA or customer visible bugs or just one of each, etc.
Logical people would get on board after seeing such evidence, but this is about religion not logic.
When a stock goes up and stays up following an IPO that means the company screwed up pricing their shares, raising less cash than they could have for a given dilution and/or unnecessarily devaluing investors' shares.
Employers are terrible at evaluating candidates. Can't tell a good programmer from a smooth talking bullshit artist. Nor, on the more subjective criteria, are they much good at telling the crazies apart from the merely desperate. The best they can do is hit prospects with a test on trivia about a particular language, the sort of stuff you shouldn't memorize but should look up in a reference. Quick, name all the reserved words in C++! If you can't do it, then you must not be an expert C++ programmer. If you try to explain why knowing that is not important, then you get that question "wrong", and are tagged as a BS artist to boot. I've had a so-called technical interview end after just 1 trivia question. They refuse to allow any time for training, demanding that new hires "hit the ground running". Candidates are expected to train themselves at their own expense beforehand.
Nope. I can accept that things happen differently in non-technical mega corporations and/or places without a critical mass of software people, although companies where software is core in viable startup hubs don't do that with "core" defined in Moore's core vs context categorization. Context activities are things that businesses must do like E-mail but doing them better than their competitors like sending messages in 10ms not 100 doesn't impact the bottom line. Core activities are those which do - better scalability and WAN optimization lets a cloud backup company serve bigger customers which pay more.
All but one out of a dozen places I've worked over 19 years in Boulder, Seattle (plus the East Side), and Silicon Valley did not do things the way you describe. Every competent software engineer who's worked in industry for a while knows that programming aptitude can be sanity checked in an interview, that knowing trivia is orthogonal to being able to do the job, and that other competent engineers will quickly pickup a language or library they're not familiar with (which is the easy part) while not so good engineers who know a language will never gain aptitudes they lack. Decent managers leave technical hiring decisions to a potential employees' peers.
Microsoft hired me to write C# professionally although I'd never seen the language before. I worked on Amazon products written in Java although I'd seen it once professionally.
There seem to be several aptitudes
1. Thinking through problems logically, identifying their edge conditions, and expressing a solution
2. Indirection
3. Applying knowledge to engineering problems
4. Parallelism
5. Recursion
which people have or don't.
In theory all should be pre-requisites for a computer science degree although in practice that is is not the case. My favorite professor taught data structures, graded students based on how their code did compiled and linked against teaching assistant defined automated test suites, and allegedly failed 1/3 of the class. The department wasn't happy with the failure rate (presumably due to their share of tuition dollars when people were forced out of a CS major) and replaced her. Graduates I interviewed for positions in industry before the faculty change were usually worth hiring. After they had a 50% reject rate.
I ask all candidates simple questions out of the first four categories, two with code. No trick questions. Engineers which do well as employees tend to make it through the current first question in under 10 minutes and the rest under 5 after which we can talk about projects and process. When I was young and naive I caved to management and overlooked a few problems but have since learned my lesson. People you don't want to hire can spend 45 minutes on one and not get to an answer. Probably 99/100 contingency recruiter submitted candidates don't do well there (I like to think that's because the vast majority of people you want to work with already have jobs, as opposed to there being that few competent people).
Compensation packages for senior staff / principal level engineering positions for guys 15+ years into their career with meaty projects under their belt (fifteen years of entry level work won't do it) and no management detour at profitable companies are over $200K
Not true since Vista. Slashdot is full of folks who've last used Windows more than 10 years ago and thus complain of things like bluescreens, bloat etc. which makes them look like idiots.
Get with the times and at least update your hate machine.
Right!
My Dell Studio 15 with Windows 7 doesn't blue screen
Instead it becomes extremely sluggish, unresponsive to mouse clicks, and I can't successfully start a task manager to see what's going on or get it to shut down normally so I need to use the power button instead.
I only use it for running Google Sketchup, Taxcut, Firefox, and the Mcafee anti-virus software which seemed like a good idea at the time.
As a web-dev... I work day in day out with CS grads. As an engineering major, what my observation is, they are pretty bad at seeing the "big picture", and more often, very bad team players.
Your CS grads don't do so well because they're inexperienced at such things and most of their post-pubescent life was spent where distraction by the big picture and being a team player had negative effects. Assuming you've done a reasonable job filtering out defective personalities in the interview process with a little mentoring they'll outgrow those problems and get back to sharing and being team players like they were in pre-school.
Exams and projects revolved around a relatively small set of facts and shallow generalizations (it doesn't take much to wax eloquent for an hour or so). Any attention to the "big picture" which isn't covered detracted from time spent on the things which get you grades, college credit in high school via AP exams, admission to good schools, and scholarships. This was especially true once they got to college where accrediting organizations credit hour allowance is way out of whack with the amount of work some professors expect.
The few joint projects through that time period generally involved two people doing about the same thing (like alternating cuts on a rat) at the same time for a day. Outside those projects collaboration would have negative effects on the grading curve.
My computer science program only required one group project (three people where expected to spend a year doing something real for a company in industry) and that was unusual.
I agree with your premise there are lots of "developers" who have worked on a project that used technology X... And realistically only a couple members of any team are producing 70-80% of the code, but the recruiting agencies and HR depts are a huge part of the problem. I am (no really) in that 5%, but I have the hardest time finding jobs, because I've worked all over the map... From designing huge networks, to automating deployment of tens of thousands of network devices, to DB design/DBA type work, to software design, development, etc both web and client based.
If you don't need to beat recruiters off with a stick it's because you're not using linkedin, live in the wrong place, or have big resume problems.
If you're at a career point where you're not satisfied with the jobs within your social network you need a linkedin presence (I'm trying for a start-up home run so I can retire and bootstrap my own companies without giving up my middle class lifestyle. Connections at big companies, small companies unlikely to see exponential growth, and startups with bad business plans don't get me there).
If you're really into writing software you should probably live someplace where there are lots of businesses where doing that well is essential to the bottom line. There's the SF bay area and every place else (41% of 2011 venture capital spending went to Silicon Valley and San Francisco ranks high too). Austin, Boston, Boulder, Raleigh, and Seattle/the East Side are most of the rest. Those places have higher costs of living where the salaries don't quite compensate although you probably spend more time working than anything else and are likely to be happier with the better job and a smaller home where you spend less of your time.
List all of the key words you've worked with. Eliminate those you don't want to do again (for instance, I don't like dealing with the Microsoft tool chain or library issues so I don't admit to having worked with C# even though I did so as a Microsoft employee.). Now you have your bases covered for recruiters, big company HR, and their key-word matching software.
Sort into categories somewhere along the expert / experienced / other continuum so you are not mis-representing your skills to the technical staff that interviews people and makes hiring recommendations.
If you are answering recruiter's emails and phone calls but not getting interviews it's because you have resume problems. The meat of your resume is written for engineers and managers. Engineers want to see what you personally accomplished technically. Managers want to see what you did in terms of leadership to deliver products sooner / more predictably / with lower cost and how your technical and non-technical contributions improved the bottom line.
If you're interviewing but not getting job offers there are problems with you.
I need to see that senior candidates have built bigger and more complicated things than junior candidates. I accept that in many situations candidates were limited by what was on the table, although after enough positions if they're not doing big things it's because they're either not interested or not capable in which case I'm better off hiring a less experienced candidate that I can grow.
I expect senior candidates to have practical experience with process and the things surrounding writing code and value doing them well because it makes delivering products faster, more predictable, and more pleasant for everyone. I've seen some real stupidity from executives "test code doesn't ship to customers" "we'll add quality later" and accept that many people spend time working in such environments, although after enough positions if they're not doing things it's because they're not interested enough in their craft do do a little side reading and experimenting or they have attitude problems ("I'm too good for unit testing!") in which case I'm better off hiring a less experienced candidate that's more likely to be trainable.
I know a handful of people who retired or could have in their 20s and 30s with their earnings as "employees" which is real enough for me.
Senior technical employees can retain 0.25 - 0.5% of a venture funded company at the time of a liquidity event which is taxed as long term capital gains (currently 15% Federally) which leaves them with about 85% of it in the Seattle area, 80% in Denver/Boulder, and 75% of it in Silicon Valley to enumerate a few hotbeds of tech startup activity.
2B * 0.0025 *.75 = 3.75M *.04 = $150K/year for life
OTOH, if you define "real money" as private jets and celebrity parties there are more opportunities to get there as a founder than working your way into a CEO position at a big enough company.
Slashdot Mirror
With IBM's Santa Teresa study showing 40% more productivity from employees with quiet private spaces, those open offices are costing share holders a lot of money,
In a big, growing company
40% of a young engineer's $200K annual package is $120K
40% of a mature staff engineer's $600K annual package is $240K
Walls cost much less.
Part of the issue is your HR department.
Most HR departments now days demand a bachelor degree or better, just to be able to say hello
Most HR departments where software is a big part of their products (including Amazon, Apple, Facebook, and Google to use a few household names) ignore that written requirement when hiring experienced software engineers.
uh, what personal time do you have if you're putting in 60-80 hours a week? idiot
60-80 hours a week allows plenty of personal time. 168 hours in a week leave 112-119 waking hours with 7-8 hours of sleep each night. Subtracting just 60-80 hours leaves 32-59 hours for other things. That's a lot when you don't waste it on low-value activities like watching TV or commuting far because you chose to spend your housing budget on a larger home farther from work.
Working 60-80 hours a week for my second startup I learned to fly, made 168 skydives and 30 BASE jumps the year I counted, snowboarded some, and built a pair of stereo speakers.
OTOH, 105 hours a week for a few months at my fourth one I didn't even have time to dine with my wife. That's too much.
AP meant 27 hours of college credit I didn't have to pay for.
It meant learning calculus 1 and 2 in a small classroom with under 30 people not a lecture hall with 300+.
Both things were entirely worthwhile.
Moving somewhere outside fly-over country where software is core to businesses not a cost center does more for salaries than studying COBOL.
New grads at the big Silicon Valley tech companies are getting $170-$190K packages - like $115K salary, $100K signing bonus, and $200K restricted stock package vested over 4 years.
$2500 apartment rents and a 9.3% state marginal tax rate take a big cut out of that although it's still a net win.
>Honestly, the best thing to do in IT once you hit a certain level is ask yourself "Do I want to be a manager". If the answer is no, you essentially have to quit and go be a consultant.
Hardly, you just have to work someplace you're appreciated. Such organizations have engineering roles up to the VP level.
Principal Engineer is usually equivalent to a director, Distinguished Engineer VP, and Fellow somewhat higher.
Consider Microsoft - Principal Engineer is level 65-67 position like a director. Distinguished Engineer is a level 70 position like VP. Technical Fellow is level 80.
Such positions involve leadership but not people management and handle bigger technical problems than the ones companies delegate to consultants.
The problems are noise and interrupts. For simple problems less communication is better because minutes lost by an engineer using Google instead of his friend make a smaller impact than the fifteen minutes of context switch overhead which can result for the person interrupted. When more communication is needed people can always grab a conference room.
IIRC IBM's Santa Tersa Laboratory - Architectural design for program development lists a 40% throughput delta for engineers in quiet spaces provided by enclosed offices or with partitions at least six feet high.
With fully burdened per-engineer costs that can break $200K per annum open offices can waste at least $58K (I don't recall if the comparison was stated as 140% for the good performers implying you get $142.9K of work for $200K from slow ones or slow movers loose 40% of their throughput and don't do $80K worth of work) per engineer per year and cost more than closed offices.
_Peopleware Productive Projects and Teams_ by Demarco and Lister provides some anecdotes and hard numbers in chapters 8 "You never get anything done around here between 9 and 5" and 9 "Saving money on space."
Comparing coding wargames participants who performed in the first and fourth quartiles
57% versus 29% have "acceptably quiet" space
62% versus 19% have "acceptably private" space
38% versus 76% do not have "people often interrupt them needlessly"
Median time to complete the programming tasks was 2.1 times the best and bottom half as a whole 1.9 times the top half.
Participants with acceptably quiet spaces were also one third more likely
to produce zero defect work.
Sales is often half commission. IOW, a sales person with a $60K base salary is expected to make $120K On Target Earnings.
UPSes do nothing about emergency thermal shutdown which isn't uncommon in laptops when you use them for real work.
They do nothing about the hard power cycle needed to clear certain software failures. As shipped my laptop running Windows 7 often hung with a spinning cursor and wouldn't bring up a task manager. Occasionally it hangs solid under Linux, usually when resuming from sleep.
There's no way to know when the drive is wearing out,
Sure there is.
Smart attribute ID 202 Percent Lifetime Remaining
This value is defined as:
VR = 100(MAX(EAVG)) / BL
Where:
EAVG = The average erase count for a super block (stripe of blocks)
BL = The erase count for which the part is rated (block life)
Depends on the situation. My current employer is in the process of outsourcing engineering to India, and keeping the US engineers on for varying periods of time (3-9 months) to facilitate the transition. There are incentives to stay through the end, but many have decided it's better to get out now. There is no bridge to burn, and people that are leaving already have new positions elsewhere when they resign. What is the possible incentive to give more than one or two day's notice?
1. You may care to work for and/or recruit people from that company and not want to make their lives worse.
2. The company may be wrong.
A year after a big company acquired a startup I worked for they decided to schedule the product's end-of-life, send it over seas for maintenance, and close the office.
1. I recruited a project manager and two engineers from that group to work for my next startup and joined the PM and one engineer at the one which followed that.
2. The company wasn't happy with the quality of the outsourced engineering and had to hire people back as high-paid consultants
3. While the competing group didn't care for the product the customers did, kept buying, and got the end-of-life pushed farther into the future (a few times IIRC)
With leadership aptitude you can multiply contributions from people around you.
Without leadership skills your contribution to the bottom line is limited to what you can do personally.
When hiring an expensive senior engineer I want one with leadership skills. If I can't get that I'd rather have a less senior engineer likely to do as well or better as an individual contributor (because the work is more novel to them and likely to have them operating at a more optimal psychological arousal level) who I'm more likely to mentor into a leader than some one in industry long enough without signs of showing aptitude or motivation to lead.
As others have noted, leadership and people management are different things. I don't expect engineers to be managers or vise-versa.
>Despite many accomplishments, published papers, and more, I cannot seem to get past the canned hiring process and actually get before a hiring manager.
With a history like that you shouldn't be going through a canned hiring process.
You're doing something wrong.
Talking to former co-workers and moving into positions at companies they've vetted as decent places to work is often a great deal for all parties involved - you get a good job, work with the same excellent people again, and their company gets a known well-performing quantity. That doesn't work as well when you've progressed to leadership roles too far beyond your peers or have other career goals that are too different like making enough to cease working for money at which point you start your own companies. I suspect new peers you'd like to work with again make that a temporary situation but have yet to verify.
Where that's not reasonable as a senior person you should be having casual encounters with technical directors (in big companies only; at small companies you want to go up the food chain to some one more able and willing to speak about the business), VPs of engineering, or CTOs in person (coffee is popular) or on the phone in which both parties get a feel for each other and determine whether a long term relationship is worth pursuing at this time or in the future. A decent linkedin presence should be enough to net this with inbound contacts directly from executives in young companies and from recruiters for larger organizations.
Those recruiters fall into two broad categories - keyword matchers taking a shotgun approach, and more targeted ones that have a better understanding of how things work and what your CV implies. The former usually don't have anything interesting to offer and I don't have much experience dealing with them. The later will make introductions. Some will try to funnel you directly into a hiring process which begins with a technical phone screen, but any place you want to work (executives recognize engineers' importance to the bottom line and consider you worth their time) you can get away with not doing technical interviews on the first date and push for a personal introduction.
When the hunger comes I can stick around for dinner after which it's more convenient to keep working at my desk until I'm at a convenient stopping point (however long it takes) or I can head home, make something or wait for my wife to do that, and by the time I've eaten switching back into work mode would be too inconvenient so it waits until necessary the next day..
Options are ancient history in big companies.
By the time I got there in 2006 Microsoft was issuing restricted stock units - regular stock that you gain control of as it vests. When I went to Amazon I got RSUs there too. Valley companies seem fond of them as well.
Options today are mostly for startups where the current value is approximately zero which means there can't be a down side; although it's usually possible to convert those to restricted stock via early exercise, at which point you can make an 83(b) election to establish a low basis and start the clock ticking on the year after which any upside will be taxed as capital gains.
Engineers don't need perks.
OTOH, employers spend less money when they're "giving away" $1 snacks and drinks than when engineers use 15 minutes of their time (70-$100 in fully burdened costs is not out of line) for a round trip to the corner convenience store which means less time left to work in a day.
>As an example: I work with a developer who is 10 years my senior, but still doesn't understand how to write concurrent code and cannot be trusted to use a revision control system without causing a mess that somebody else will have to clean up.
The developer in question just isn't competent. Concurrent programming dates to at least 1950 and SCCS came about in 1972.
>So, how do my fellow Slashdotters handle situations like this?
Avoid them where possible and work around the damage. For instance good test automation will limit how long their mistakes go undetected.
>How do you help somebody like this to improve their skill-sets?
You don't. Understanding concurrency is one of the programming aptitudes which can't be taught.
The fundamental problem is that this is a religious issue for both engineers and managers. People generally don't believe until they personally witness the miracle of rapid development with predictable schedules and low customer visible defect rate.
Working solutions in order of increasing time + difficulty:
1. Quit and either start a new team or join an existing one with decent development practices (I insist on a code and test process walk through of every company I consider joining to avoid unpleasant surprises. Obviously this fails for groups yet to build a product, and sometimes teams panic when pivoting and abandon reasonable practices).
2. Get promoted to a leadership role while you remain hands on. Tell every one else to do the right thing like you're doing - getting people to buy in is easiest when you're not making them do something you won't like the case would be with a non-coding manager. Most people fall into line with direction from above. Peer pressure works for most hold-outs. Any one not getting with the program can be replaced.
3. Do the right thing on your code. With your process producing a faster more predictable release cycle you'll have higher productivity and can take over an increasing fraction of the product so the bad people with bad process have less impact.
Applying test driven development variants to new features/subsystems/products helps a lot here because it makes shipping without good test coverage and short predictable cycle times impossible because no product code exists without the necessary infrastructure. While a "code complete" milestone may be farther into the future depending on how that's defined the total time to deliver the project will be lower and ultimately it's the ship date that matters.
Do the same for bug reports. Every reproducible bug gets an automated test case (if it broke the first time it's complicated enough to break again).
After a couple years you should be in good shape with enough infrastructure that the cost to add test cases is effectively zero before their benefits are considered (Perhaps most notable is that the requirement for incremental testing leads to cleaner interfaces which make complexity more linear with respect to project size. That in turn produces a lower defect rate, faster turn around time on repairs, and makes defect rate/time to repair more constant and predictable) and you don't have to worry about new people (or old people who haven't touched a piece of code in a while) breaking things accidentally.
Here are some things which don't work:
1. Talking to your co-workers about doing the right thing
2. Providing anecdotes (personal and otherwise) from other companies about the benefits
3. Buying everyone a copy of a book like
_The Clean Coder: A Code of Conduct for Professional Programmers_ by Robert C. Martin
http://www.amazon.com/The-Clean-Coder-Professional-Programmers/dp/0137081073/
Quote:
The jury is in!
Te controversy is over.
GOTO is harmful
And TDD works
in their choice of print or Kindle edition with the direction to read it on "company time."
4. Doing the right thing and providing metrics on things like defect rate, time to repair certain classes of bugs, number of release candidates for a feature, etc. This can be very striking - memory corruption bugs made reproducible by the test environment so you fix them in 30 minutes versus three weeks for co-workers' similar bugs, a major subsystem with no QA or customer visible bugs or just one of each, etc.
Logical people would get on board after seeing such evidence, but this is about religion not logic.
The Facebook IPO was a _huge_ success.
When a stock goes up and stays up following an IPO that means the company screwed up pricing their shares, raising less cash than they could have for a given dilution and/or unnecessarily devaluing investors' shares.
Facebook did it right.
Employers are terrible at evaluating candidates. Can't tell a good programmer from a smooth talking bullshit artist. Nor, on the more subjective criteria, are they much good at telling the crazies apart from the merely desperate. The best they can do is hit prospects with a test on trivia about a particular language, the sort of stuff you shouldn't memorize but should look up in a reference. Quick, name all the reserved words in C++! If you can't do it, then you must not be an expert C++ programmer. If you try to explain why knowing that is not important, then you get that question "wrong", and are tagged as a BS artist to boot. I've had a so-called technical interview end after just 1 trivia question. They refuse to allow any time for training, demanding that new hires "hit the ground running". Candidates are expected to train themselves at their own expense beforehand.
Nope. I can accept that things happen differently in non-technical mega corporations and/or places without a critical mass of software people, although companies where software is core in viable startup hubs don't do that with "core" defined in Moore's core vs context categorization. Context activities are things that businesses must do like E-mail but doing them better than their competitors like sending messages in 10ms not 100 doesn't impact the bottom line. Core activities are those which do - better scalability and WAN optimization lets a cloud backup company serve bigger customers which pay more.
All but one out of a dozen places I've worked over 19 years in Boulder, Seattle (plus the East Side), and Silicon Valley did not do things the way you describe. Every competent software engineer who's worked in industry for a while knows that programming aptitude can be sanity checked in an interview, that knowing trivia is orthogonal to being able to do the job, and that other competent engineers will quickly pickup a language or library they're not familiar with (which is the easy part) while not so good engineers who know a language will never gain aptitudes they lack. Decent managers leave technical hiring decisions to a potential employees' peers.
Microsoft hired me to write C# professionally although I'd never seen the language before. I worked on Amazon products written in Java although I'd seen it once professionally.
There seem to be several aptitudes
1. Thinking through problems logically, identifying their edge conditions, and expressing a solution
2. Indirection
3. Applying knowledge to engineering problems
4. Parallelism
5. Recursion
which people have or don't.
In theory all should be pre-requisites for a computer science degree although in practice that is is not the case. My favorite professor taught data structures, graded students based on how their code did compiled and linked against teaching assistant defined automated test suites, and allegedly failed 1/3 of the class. The department wasn't happy with the failure rate (presumably due to their share of tuition dollars when people were forced out of a CS major) and replaced her. Graduates I interviewed for positions in industry before the faculty change were usually worth hiring. After they had a 50% reject rate.
I ask all candidates simple questions out of the first four categories, two with code. No trick questions. Engineers which do well as employees tend to make it through the current first question in under 10 minutes and the rest under 5 after which we can talk about projects and process. When I was young and naive I caved to management and overlooked a few problems but have since learned my lesson. People you don't want to hire can spend 45 minutes on one and not get to an answer. Probably 99/100 contingency recruiter submitted candidates don't do well there (I like to think that's because the vast majority of people you want to work with already have jobs, as opposed to there being that few competent people).
When it comes to projects I don't ca
_Starting_ compensation packages for new BS graduates at the big SF bay tech employers are north of $100K.
http://www.netpaths.net/blog/starting-salaries-of-top-technology-companies-apple-google-microsoft-facebook/
Compensation packages for senior staff / principal level engineering positions for guys 15+ years into their career with meaty projects under their belt (fifteen years of entry level work won't do it) and no management detour at profitable companies are over $200K
In spite of that positions go unfilled.
Not true since Vista. Slashdot is full of folks who've last used Windows more than 10 years ago and thus complain of things like bluescreens, bloat etc. which makes them look like idiots.
Get with the times and at least update your hate machine.
Right!
My Dell Studio 15 with Windows 7 doesn't blue screen
Instead it becomes extremely sluggish, unresponsive to mouse clicks, and I can't successfully start a task manager to see what's going on or get it to shut down normally so I need to use the power button instead.
I only use it for running Google Sketchup, Taxcut, Firefox, and the Mcafee anti-virus software which seemed like a good idea at the time.
As a web-dev... I work day in day out with CS grads. As an engineering major, what my observation is, they are pretty bad at seeing the "big picture", and more often, very bad team players.
Your CS grads don't do so well because they're inexperienced at such things and most of their post-pubescent life was spent where distraction by the big picture and being a team player had negative effects. Assuming you've done a reasonable job filtering out defective personalities in the interview process with a little mentoring they'll outgrow those problems and get back to sharing and being team players like they were in pre-school.
Exams and projects revolved around a relatively small set of facts and shallow
generalizations (it doesn't take much to wax eloquent for an hour or so). Any attention to the "big picture" which isn't covered detracted from time spent on the things which get you grades, college credit in high school via AP exams, admission to good schools, and scholarships. This was especially true once they got to college where accrediting organizations credit hour allowance is way out of whack with the amount of work some professors expect.
The few joint projects through that time period generally involved two people doing about the same thing (like alternating cuts on a rat) at the same time for a day. Outside those projects collaboration would have negative effects on the grading curve.
My computer science program only required one group project (three people where expected to spend a year doing something real for a company in industry) and that was unusual.
I agree with your premise there are lots of "developers" who have worked on a project that used technology X... And realistically only a couple members of any team are producing 70-80% of the code, but the recruiting agencies and HR depts are a huge part of the problem. I am (no really) in that 5%, but I have the hardest time finding jobs, because I've worked all over the map... From designing huge networks, to automating deployment of tens of thousands of network devices, to DB design/DBA type work, to software design, development, etc both web and client based.
If you don't need to beat recruiters off with a stick it's because you're not using linkedin, live in the wrong place, or have big resume problems.
If you're at a career point where you're not satisfied with the jobs within your social network you need a linkedin presence (I'm trying for a start-up home run so I can retire and bootstrap my own companies without giving up my middle class lifestyle. Connections at big companies, small companies unlikely to see exponential growth, and startups with bad business plans don't get me there).
If you're really into writing software you should probably live someplace where there are lots of businesses where doing that well is essential to the bottom line. There's the SF bay area and every place else (41% of 2011 venture capital spending went to Silicon Valley and San Francisco ranks high too). Austin, Boston, Boulder, Raleigh, and Seattle/the East Side are most of the rest. Those places have higher costs of living where the salaries don't quite compensate although you probably spend more time working than anything else and are likely to be happier with the better job and a smaller home where you spend less of your time.
List all of the key words you've worked with. Eliminate those you don't want to do again (for instance, I don't like dealing with the Microsoft tool chain or library issues so I don't admit to having worked with C# even though I did so as a Microsoft employee.). Now you have your bases covered for recruiters, big company HR, and their key-word matching software.
Sort into categories somewhere along the expert / experienced / other continuum so you are not mis-representing your skills to the technical staff that interviews people and makes hiring recommendations.
If you are answering recruiter's emails and phone calls but not getting interviews it's because you have resume problems. The meat of your resume is written for engineers and managers. Engineers want to see what you personally accomplished technically. Managers want to see what you did in terms of leadership to deliver products sooner / more predictably / with lower cost and how your technical and non-technical contributions improved the bottom line.
If you're interviewing but not getting job offers there are problems with you.
I need to see that senior candidates have built bigger and more complicated things than junior candidates. I accept that in many situations candidates were limited by what was on the table, although after enough positions if they're not doing big things it's because they're either not interested or not capable in which case I'm better off hiring a less experienced candidate that I can grow.
I expect senior candidates to have practical experience with process and the things surrounding writing code and value doing them well because it makes delivering products faster, more predictable, and more pleasant for everyone. I've seen some real stupidity from executives "test code doesn't ship to customers" "we'll add quality later" and accept that many people spend time working in such environments, although after enough positions if they're not doing things it's because they're not interested enough in their craft do do a little side reading and experimenting or they have attitude problems ("I'm too good for unit testing!") in which case I'm better off hiring a less experienced candidate that's more likely to be trainable.
I look fo
It depends on how you define "real money".
I know a handful of people who retired or could have in their 20s and 30s with their earnings as "employees" which is real enough for me.
Senior technical employees can retain 0.25 - 0.5% of a venture funded company at the time of a liquidity event which is taxed as long term capital gains (currently 15% Federally) which leaves them with about 85% of it in the Seattle area, 80% in Denver/Boulder, and 75% of it in Silicon Valley to enumerate a few hotbeds of tech startup activity.
2B * 0.0025 * .75 = 3.75M * .04 = $150K/year for life
OTOH, if you define "real money" as private jets and celebrity parties there are more opportunities to get there as a founder than working your way into a CEO position at a big enough company.