Here is a snip from DC's laws that describe what constitutes assaulting an officer:

"Whoever without justifiable and excusable cause, assaults, resists, opposes, impedes, intimidates, or interferes with a law enforcement officer on account of, or while that law enforcement officer is engaged in the performance of his or her official duties shall be guilty of a misdemeanor" it elevates to a felony if it "causes significant bodily injury to the law enforcement officer, or commits a violent act that creates a grave risk of causing significant bodily injury to the officer"

That's a pretty broad set of actions one can commit and still constitute "assault", which is why it's often referred to as "contempt of cop". Technically, if a cop punches you in the face and cuts his hand on your teeth, you can be charged with felony assault. Hopefully that won't hold up, but as you said, if you assault an officer, you're guilty. Period.

Your comment indicates that existing board members have informed you that your idea may not be welcomed by Bob. Listen to them. He has been personally invested in this for quite some time and may not welcome the new guy rocking the proverbial boat, I'd suggest the best way to pursue this would be to have the move to Google be Bob's idea. Have Bob show you his work, appreciate how much time and effort he's put into it and when you get to functionality that it doesn't do or doesn't do well steer the conversation towards filling those gaps. Ask Bob how he would do it on his site or ask him for his ideas. It's very likely that Bob isn't any happier with his solution than anyone else is, but he's personally invested in it. It's that investment you need to recognize in order for your migration suggestion to be successful - for everyone. If you can get Bob to be part of the solution, he may well invest just as much time in that as he did this.

I agree, but for a different reason. Unfortunately where I work, if you don't have written evidence that someone agreed to something then you cannot "prove" they ever said it. I can't count the number of times being able to forward an email where someone agreed to do X or be responsible for Y has saved my arse. Admittedly, this says less about the importance of email as a communication medium and more about corporate culture where I work, but this isn't the first time I've run into this and don't expect it to be the last. Email provides a clear written record of what's been said and more often than not, being able to refer back to that record - either for your own edification or as evidence - is extremely useful.

As someone who recently went from a ~50+ minute commute to a six minute commute (door to door) it’s worth it, that alone makes it worth it. That's the most valuable factor in the entire equation. I got ~+10 hours a week of my life back that I used to spend in a car. Ten. The amount of *life* I've regained, and its corresponding value, is incalculable. It's worth much more than an extra 7K/year - I'd consider the extra money as a nice bonus, the real value in this job offer is in the amount of your life you're going to get back.

The vast number of other /.’rs are right, we’re talking about companies, where there is no such thing as loyalty or friends *especially* between upper management and worker bees. It’s about money and greed. Period. Full stop. If they have two trained jr. developers who combined make less than you (in all forms of compensation: vacation time, medical/pension and other employer contributions, etc) then they will, in all likelihood, fire you as soon as they think those two can hold that ship afloat with the outsourced developers. I’d expect that to happen shortly after the product is launched. Unless you have shares in the company or will make beans should the product you’ve been working on takes off, then you have no stake in their game. If they really need you, they'll pay to keep you - but if they do, I think it will increase the likelihood that you're training your replacements - but are you absolutely sure you aren't already doing that?

UconnGuy is 100% right about how to tell if they truly are your friends or not when you tell them about the offer. If they really are “friends”, they’ll want you to get an extra $7k/year and +~10 hours a week of your life back, as friends want what's best for you not what's best for the company. XxtraLarGe also has a very good suggestion, you can offer to stay on as a consultant. It could be for a transitional period or as long as you/they want, and with the extra ~+10 hours a week, you’re going to have *plenty* of time to do that consulting work!

Take the new job as long as you have some level of confidence that it’s a stable move and your new employer isn’t at risk for downsizing anytime soon as you’ll be the first to go if they do. Bottom line is this: time is something they’re always making more of but something you’ll never have enough of & the amount of *life* you’ll get back that you used to spend commuting will be worth infinitely more than the $7k pay rise is.

I start by rating each coders “effective productivity” where for an hour worked, how much time/code actually gets generated. Some will be .5:1 if they have to stop frequently to answer questions, some will be at .75:1 if they code well, know what they need to do and are stationed in a broom closet so they aren’t interrupted, some will be .25:1 or even .1:1 because they are an intern or a new recruit. Then I consider how long it will take to produce each section of the product (just broken down into logical groups) in a “perfect world” where everyone is coding at 1:1. I then apply each members effective productivity to that time for each logical group. I then add 20%-40% to each individual module I broke it down into, depending on how complete the requirements, specifications, etc are going into that module where 20 is better, 40 is worse (usually). So if I had five modules, time of each would expand by at minimum 20%+ the expansion of the effective productivity of those working on it. Then add all the time up, add 30% for testing then 20% buffer and you’ll find, surprisingly, you’re stabbing at a number that is as realistic as you can make it this early in the game. You also have a number that can be presented to those outside of IT and, dressed up with the math, presents an estimate that is based on real numbers and is quite hard to argue with. Ultimately, it’s a more formalized SWAG, all programming estimates have Some Wild Ass Guess in them though, as quantifying the time involved in being creative is quite hard to do.

Kohath / Techno-vampire commented "IT people setup security that's needlessly inconvenient". A paper from HotSec '07 http://www.usenix.org/event/hotsec07/tech/full_papers/florencio/florencio.pdf titled "Do Strong Web Passwords Accomplish Anything?" addresses the principal of requiring users to use ridiculously strong passwords. In practice, this tends to have the adverse effect by making systems too cumbersome to log into and passwords that are so hard to remember they are often written down. How strong do passwords need to be in order to be effective? The paper argues (and the math confirms) that even relatively weak passwords (20 bits) when used with password rotation and "three strike" policies are enough to make brute-force attacks on a single account unrealistic. My employers previous user/pass policy was mixed case, 8 char min, #'s and punctuation requirement, with 90 day rotation and three-strikes - BUT the username was made public, so only 1/2 the credential pair was private. My approach was to make both the user and the pass non-public, keep the rotation & three-strike policy and reduce the complexity requirement of the password slightly. The result puts more of the security burden on the systems and less on the users (by not having to remember complex passwords). This results in higher overall security of credential pairs and made the userâ(TM)s daily experience easier and less cumbersome.

Keyboard -> motherboard -> jump to ground, no, but the system as a whole (not the u fluctuations of the individual components there in) was (this was early 90's) be detectable. Not detectable in the "1011011 = exact data sequence" sense of the word but in a active/inactive "is the keyboard in use" sense... sure.

While it is "bogus" in that there is no new information here, it isn't bogus in the sense that it can't be done. When I was getting my EE, I was able to do a POC with nothing more than a bread board and an oscilloscope. In conjunction with using a laser to pull sound off windows (used by the CIA also) the possibilities with serious funding are truly endless.

Ah - lol - got it.

Nope. Deployed, even got extra to give to the boom operators so they could see how the fuel moved around the aircraft using the fuel panel simulation.

While working for the USAF developing a PTT (Part Task Trainer) for the new "glass cockpit" on KC-135R Aerial Refueler, my coding partner and I worked at the largest non-commercial airport in the US. Our office was a 6x9 closet. We were located by the fuel station, so every afternoon when the news choppers and flight for life choppers would refuel, the ventilation system pumped AvGas directly into the "office". It would get so bad that we would have to stop working from 3-5. After attempting to work through it at first, we would get dizzy from the fumes.