Sharp Learning Curve

Crazy Pills

I get it; you have to find some way to market yourself, which means differentiation. If you’re well known in your field, the pressure to differentiate yourself increases. A little pot-stirring or boat-rocking can be a good thing. Upsetting the status quo and getting others to question their assumptions is a good thing.

Signal To Noise

But eventually too much of this sort of activity becomes very, very obnoxious noise that will not only get blocked out but can also get any associated ideas discredited. A valuable idea is probably good enough on it’s own; dressing it up in so much fan-fare and gimmicky communication is insulting to your audience and will eventually drive away those intelligent enough to appreciate the implications of any worth-while message. I want to hear new and challenging ideas, I spend a lot of time exposing myself to those who think differently and trying to learn everything I can from them. I don’t have a lot of patience trying to learn anything from anyone who puts a lot of effort in sensationalizing or “blinging” the message. Just get to the point, please?

Slave To Nothing

A slavish mindset to anything is unhealthy. Obsessions with process, development methodologies, toolsets, or specific languages are all dangerous when they blind to you. All these things are created with the sole intention of enabling effective software development. Not every item in every one of these categories was made to work for everyone. Evaluate what’s out their and use what makes you effective; I’ve yet to hear a customer complain about good results.

Maybe It’s Just Me…

I think testing software is good. I am awful at test-first development and I usually get somewhere between 60% to 80% coverage when I do write good tests. What I have managed to internalize are many of the lessons, patterns and disciplines that test driven design enforces. In some ways I feel like I have gotten a lot of benefit from reading about test-driven development and believe that even though I don’t stringently adhere to their prescriptive “Failing tests first: red-green-refactor!”, I’m a much developer than I was before I learned about TDD and BDD.

There are a lot of other examples along these lines in different areas; but I think ultimately all these ideas are tools in the belt. Use the right (process, conceptual, design, etc.) tool for the task at hand that will provide benefit. Software development is a creative endeavor, trying to turn it into a industrialized process is a mistake.

This Echo Chamber Gets Lonely

I really am interested in some other’s thoughts on this. Hopefully this post doesn’t come across as so close minded those who disagree or have thoughts to add wouldn’t do so.

Comments