> You should have a strong opinion on every major area of software development
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" sounds right to me.
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...
At least from my point of view in writing the article, strong -> power to move; stubborn -> refusing to move.
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.
You reminded me of a developer complaining about the XML bloat in our product. He said "Do you know how much overhead XML adds to your page loads?". I responded "Yes, roughly 60ms on uncached page loads.". Later he proudly explained that he didn't know how to write html tables because he only uses CSS.
This post deals more with setting up the best possible environment at the beginning of a project, rather than joining a team. You obviously have less say in that. This section's not about being sycophantic about a particular option, it's about knowing what works, what doesn't, and why. Starting any project with a lackadaisical approach to how you're going to execute can come back to bite you in the end.
You certainly can feel superproductive working on greenfield projects and, once in a while, actually be superproductive.
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.
I've begun using a Trello board to keep track of the skills I want to pick-up and things I want to learn.
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.
Thanks for this. I may well augment what I already do with this. What I have which you don't do is on the "learning it" stage (although I don't categorise explicitly in this way) I have a square bracket with a number inside which I use to keep track of how many hours I'm working on each thing. You can see if you're spending too much time on something, or whether you've only done an hour (pretty useless, etc)
Learn and create my own Chef cookbooks vs just using Vagrant now.
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.
I know "me too" is bad form but since upvotes to pestaa's reply can't be seen this is the only way I can show encoderer that more people would be interested in more examples. (Blog it up if it would be too big for a reply.)
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.
> Developers love developing. (Perhaps recently computer science has gotten a boost in the number of those in it for the money, but for the most part those who I interact with on a professional level are in it for the fun.)
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:
Thanks! I didn't write the article, but I'm on the team. We tried to make sure that people who care what we do can find it, but it doesn't dominate the page.
I think its good practice to spend a little bit of time each day or week trying to learn something new that will help you work[/play], a new vim command or feature, etc.
Absolutely. And then force yourself to adopt it. For instance, if you want to remap your control key to caps lock, physically remove your control key from the keyboard.
My passwords for important things (Google account, bank, etc) are 128+ pseudo-random characters, so it's a pain to get right without checking. Also I was surprised at how often I looked at my keyboard for typing numbers to orient once I started paying attention.
Ah, typing random characters can be a pain, for sure. That said, what was your calculus that leads to picking >600 bit keys? You'll likely be losing most of that to hash collisions.
Good SCM, easy testing APIs/harnesses and easy deployment are so wildly important, it infuriates me to work at one of the the biggest names in tech and waste HOURS a day on bullshit deployment issues or copy/pasting things in six different places before I can execute my tests or do manual verification.
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.
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).