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.
On the goal and nature of the redesign.
If the goal is to improve usability, then the customers should. Of course their input should be focused through the UI/UX guys.
If the goal is to increase profitability, then for B2C software, marketers and for B2B sales.
If the goal is to improve the maintainability and stability, then software engineers.
If the goal is to improve operability, then the operators.
If the goal is to improve scalability, then capacity planners and enterprise architects through the lens of software engineers.
And job candidates who customize their user agents are smart asses who will probably hack all of your systems.
Apps may or may not stick around, but one trend will continue: the increase in service oriented computing.
I.e. computing functionality is being broken down into modular services (usually web services) that are simple enough and independent enough to be easily scaled horizontally but that can be composed in order to provide richer more complex functionality.
If you understand this architecture, it will help your marketability immensely whether you are writing end user interfaces (such as apps) or building the aforementioned services.
The convention in the United States for decades has been to places periods inside the quotation marks. All others are based on the actual quote. The Chicago Manual of Style, as one of many, recommends this, but most guides point out that the British style placing anything not part of the quote outside of the quotation marks is acceptable but may be seen as unusual to American readers--of all ages.
Although putting periods inside quotation marks is recommended by various manuals of style and others recommend putting them outside, I believe that both approaches are misguided
Clarity should be the primary concern in language. Quotation marks are used to indicate that the current passage is repeating something verbatim from another source. It is most accurate to include punctuation inside quotation marks if that punctuation is repeated verbatim. In that case, they are punctuating the original. If they are not from the original source, they should be used outside.
Old programmers never die, they just hit account block limit.
