Strong implies stubborn, and stubborn implies inflexibility. The last thing I want when trying to debug a legacy system is a new hire complaining up the wall about XML bloat. It wasn't my decision, we are stuck with it, and let's move on and ship.
I think every developer should have some (shred of) experience in every area, and have knowledge of various options and the tradeoffs between them, but don't go around becoming that die-hard religious guy on the NoSQL/SQL debate (or any other for that matter).
"Strong opinions, weakly held" http://www.codinghorror.com/blog/2008/05/strong-opinions-wea... http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinio...
"I aim to fight as if I am right, and listen as if I am wrong" http://blogs.hbr.org/sutton/2010/08/its_up_to_you_to_start_a...
I couldn't care less how confidently somebody holds an opinion.
I think the word "strength" here should signify a battle-hardened opinion that has won out over others in a practical or theoretical sense. Strongly-supported...?
That's not to say that that it's wrong to be confident in the opinions you hold, but if you want to have strongly-supported opinions you can't protect them from being tested against other opinions. Let them win on their own merit...
I've found that the skills of a maintenance programmer are sufficient to punch my meal ticket. Early in my first W-2 job after grad school I took pride in my ability to pick up any tools and solve any problem with any system. Since then I've never been unemployed more than 2 days.
Since then I've fixed linux kernel bugs and built Silverlight applications with Visual Studio. (Ok, I have taken "Cold Fusion" off my resume.)
From time to time I have gotten into conflicts with management that it takes too long to do things -- but between learning new environments and understanding new systems, maintenance work is slow.
One critical skill is understanding a system enough to make surgical changes. Many people look at an old system and they want to tear it up completely and rebuild it -- often they think they can do this quickly, but often they understand at most 10% of the functionality of the real system. Other people, pressured by their boss, make a quick patch (that's not so quick) that ends up breaking other things. The work of understanding the code so you can make a small change takes a while -- yet, I think it saves time in the long term because it's better to spend 3X the time to get a 95% chance of success than to plan something half baked in X time that has a 25% chance of success and blow the schedule by repeating that mistake repeatedly.
Greenfield development is risky, making it harder to get a good a job doing it.
To take an example I spent much of the last six months building a beautiful system from scratch on my own dime.
Within two days of hearing about it, one of the largest companies on the internet made a concious decision to put me out of business. Tough luck, but any entrepreneur faces the risk they'll "build it" and nobody comes.
Another issue is that many "productive" greenfield projects are done by a junior programmer who is really proud of what they pass over to somebody like me to send into deployment.
Frequently these systems are full of bugs and come nowhere near meeting requirements -- hopefully you find out that the app malfunctions when somebody puts a single quote into an HTML field before it goes into production. Less than 50% of the effort has been done, but somewhere some smug opinionated programmer thinks he's the man.
All over the world, however, there are companies that have an existing system which is (i) critical to business goals and/or (ii) a source of revenue that they are not in complete control of. They need a professional programmer who's going to deal with the code in front of them and they'll pay for him. Yes there's a certain kind of stress that comes with this work, but that's the way it is.
NO!!!
Strong Opinions, Weakly Held[1][2] is what you want.
[1] http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinio...
[2] http://www.codinghorror.com/blog/2008/05/strong-opinions-wea...
I don't think anyone should be die-hard anything, because there's always a lot of grey area, and, as you said, you can rarely work in such an ideal environment. But having an idea of the tradeoffs you're making is extremely useful.
I have the lists "Heard about it", "Read about it", "Learning it", "Done with it". Today, for example, I added: "Learn about using Git bisect to trace bugs" to the Read about it board. Will probably play with it next weekend.
This is a new workflow for me, but so far it's working well.
Heard about using dsh as a, more or less, a reverse SSH proxy.
Figure out and use South django migrations.
Implement a bloom filter. Implementing a bayesian filter made it so much more understandable to me, I figure this would work the same.
There's a few other, more specific ones. But this is a fairly new workflow for me. I like the idea somebody mentioned about keeping a rough idea of how many hours you've spent on it.
You... need to see your keyboard?
At my startup, Semantics3, we use Capistrano [1] for multi-machine deployments of our git repos. This has greatly helped our productivity as it just takes a couple of minutes to go from dev to production!
Through a single command (cap -f api deploy:start) our entire cluster get the latest git repo and all the services are (re)started - we use Upstart for daemonizing our processses and Monit for process monitoring. All of them seamlessly work together.
[1] https://github.com/capistrano/capistrano There is also nice gui frontend to it. You can do deployments through the web, with built in logging and user management! Its called Webistrano - https://github.com/peritor/webistrano/
Ha. Just recently computer science got a boost in those in it for the money? I guess I started CS in 98, right during the boom times. Though our silly 18 year old selves thought we'd have it made, the 50% of our class who didn't actually enjoy it dropped off each year.
From my weak searching I found this, apparently majoring in CS is back on the rise:
http://cra.org/govaffairs/blog/2012/04/undergrad-computer-sc...
And yet we made oomples and oomples of money.
For one project, deployment to production takes 3+ weeks, testing environments can take a week and is fraught with steps that take hours and literally can fail for any random reason and can only be mitigated by starting over.
And then I come home to my side projects that can be built with a single standard command that is more or less an industry standard. I can deploy it reliably every. single. time. I have a test framework that can be run from within my development environment or from the command line with the same tool as the build tool.
