Us software development types are rigid - we think in black and white, 1's and 0's. This serves us well when we're dealing with a machine...however, we should realize that our machines are only the canvas on which we paint our masterpiece.
We face a plethora of design and platform decisions that really boil down to nothing more than what we feel will be a good fit - and you know what - THERE'S NOTHING WRONG WITH THAT. Soak that in for a sec - it's actually really liberating: We are craftsmen - artists even - we spend our career developing an instinct for designing elegant, well organized systems that efficiently automate life for people. Repeat after me: It is ok to trust my instincts when it comes to design decisions.
Take programming languages as an example - many people feel strongly that C# and .NET are the way to go for enterprise applications - many people feel strongly about Java and JavaEE. Some people (who should be committed) are really excited about RoR. Can we solve pretty much any enterprise automation problem with any of these platforms? Yes. Is there an absolutely Right or Wrong answer as to which should be selected? Not really. A lot of it boils down to the style of the programmers that will be working the system ... there may actually be some benefits and drawbacks to different languages/platforms - but when push comes to shove any of them will work for whatever thing you're trying to build.
So then - knowing that we're computer geeks and we have to have things in 1's and 0's - how do we decide what to choose? Given a new App, what do I do? RoR or PHP? Java or C++ CGI?
I propose you do what the jazz improvisor does when he steps up to take a solo - make it up as you go... do what you feel will make the most organized, elegant work of art out there (elegant is really just a synonym for organized which just means your code is more easily maintained, in case you need to make a business case for this or something) - does RoR get your juices going, does it make you feel like you're putting out a better product? Then use it....
So let's try again.....repeat after me: It is ok to trust my instincts when it comes to design decisions.
So the corollary here, for those of you that don't see it yet - is that, while you are enjoying this profound freedom - let's not selfishly hog it up - pass it on to your co-workers, or any other programmers you come in contact with........in other words - let's practice some people skillz (I know - we're programmers, so we were probably born without that particular gene - but let's work at it) - if you are pumped about programming in Java - don't force it down the throat of your co-worker who is a big Cobol.NET fan - try for common ground as much as possible.......and try to avoid the self-serving urge to claim that your way is the only right way - cause really... it's not.
Subscribe to:
Post Comments (Atom)
1 comment:
This is slightly tangential to the point you were making, but I hear people make the argument for using the "best/right tool for the job" all the time. While on the surface it may sound like a good idea, if you keep forcing people to pick "the best tool for the job" then you end up with a huge toolkit that you can never carry around and is so cluttered you can never find what you're looking for. Instead, I'd rather just have a smaller set of tools that while perhaps not the best still more than adequately perform the job. People suggesting the "best tool for the job" approach are often fixating on the small picture at the expense of the big one.
Post a Comment