3 ms·

> You should have a strong opinion on every major area of software development Strong implies stubborn, and stubborn implies inflexibility. The last thing I wa

> 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).

ryanbraganza 14y ago
I agree, and this reminds me of two other quotes. "Strong opinions, weakly held" http://www.codinghorror.com/blog/2008/05/strong-opinions-weakly-held.html http://www.codinghorror.com/blog/2008/05/strong-opinions-wea... http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinions.html 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_good.html http://blogs.hbr.org/sutton/2010/08/its_up_to_you_to_start_a...
- lhnz 14y ago
  "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...
ddt 14y ago
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.
tylermenezes 14y ago
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.
PaulHoule 14y ago
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.
nl 14y ago
Strong implies stubborn, and stubborn implies inflexibility. NO!!! Strong Opinions, Weakly Held[1][2] is what you want. [1] http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinions.html http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinio... [2] http://www.codinghorror.com/blog/2008/05/strong-opinions-weakly-held.html http://www.codinghorror.com/blog/2008/05/strong-opinions-wea...
waivej 14y ago
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.

ryanbraganza 14y ago

I agree, and this reminds me of two other quotes. "Strong opinions, weakly held" http://www.codinghorror.com/blog/2008/05/strong-opinions-weakly-held.html http://www.codinghorror.com/blog/2008/05/strong-opinions-wea... http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinions.html 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_good.html http://blogs.hbr.org/sutton/2010/08/its_up_to_you_to_start_a...

lhnz 14y ago
"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...

ddt 14y ago

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.

tylermenezes 14y ago

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.

PaulHoule 14y ago

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.

nl 14y ago

Strong implies stubborn, and stubborn implies inflexibility. NO!!! Strong Opinions, Weakly Held[1][2] is what you want. [1] http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinions.html http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinio... [2] http://www.codinghorror.com/blog/2008/05/strong-opinions-weakly-held.html http://www.codinghorror.com/blog/2008/05/strong-opinions-wea...

waivej 14y ago

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.