At an old job, we were given sudoer privileges, but there was a blacklist of dangerous commands that we couldn't sudo (such as bash, su, etc), so I wrote a one line script to get around that called hijack:
$@
Then I could type
$sudo hijack
and sudo any command I wanted.
Because of the monopolistic stranglehold that companies such as Comcast and Verizon hold over the last mile, American consumers won't see a dime of any cost savings from this.
Meanwhile consumers in Europe and Asia will continue to see faster cheaper broadband.
You might consider a Ph.D. program. If your grades are good and you have the basics, and you can tell the department a good story, you can get admitted and get funding in many STEM disciplines.
You'll have to spend a long time getting your Ph.D., but if it's what you want to do, it may be worth it. You should probably choose a program that grants a Master's along the way so that if you don't finish, you'll have something to show for your time.
Software development is usually done in an anti-social way. You chunk up a release or backlog or whatever into features, each dev takes a feature and goes off and writes some code. Later there is some collaboration in testing, code reviews, troubleshooting, etc.
But that is a TERRIBLE way to do it. The wrong code gets written way too often. Designs are bad because people aren't contributing along the way. Requirements get missed because the developer makes an assumption that s/he didn't know was an assumption. The more eyes on the code at all times the better. Devs should be constantly communicating with testers and people who understand the business case (product owners). One way to do that is pair programming. It sounds like a waste of time, but it is actually faster. Silly mistakes get caught right away. Debugging goes faster. Another way to do that is to chunk the work into very small pieces and constantly communicate to integrate your tiny piece with the other devs' tiny pieces. This leads to clean interfaces and modular code.
The Cowboy Superhero model of software development only makes sense if you are the only one developing a project. And remember in that case, your code dies when you get hit by a bus (or kill your wife and go to prison).
Network. Go to career fairs. Meet the hiring manager. He needs talented software engineers. Teach yourself more modern technologies and get certified. I'm not usually a big fan of certifications as they don't usually show that someone knows how to program in a general sense, but your degree shows that.
I have a pretty ridiculous professional network. (Not bragging really. When you have done in-demand technologies and looked for jobs, the network comes to you.) Message me me and I can add you and perhaps even give you some introductions to recruiters.
Agreed. There is probably plenty of prior art, but one would be crazy to challenge the patent because:
Congratulations, Facebook, you are a patent troll
Scrape them yourself in a semi-automated way, host them somewhere and provide a way to submit a DMCA take-down notice.
Done and done.
I have been pulled aside by a very high level manager, told to put all of my development on hold and implement entirely new functionality for a large enterprise product
This functionality required three months of team effort to develop properly + another two weeks of due diligence, pre-release testing, and deployment. And then he told me to get it deployed in three weeks.
That's how this can happen.
If A = B and B = C, then A = C, except where void or prohibited by law. -- Roy Santoro