2010.09.30

There is no spoon

The main reason for writing this post is that developers usually have some kind of bias against other programming languages or workflows, specially against those that they don’t know/understand/use… it’s always the same debate: dynamic against strict, strong-typed against loosely-typed, compiled vs. processed, sexy, powerful, expressive, safe, fast, etc..

My point-of-view is based on these principles:

We always have something new to learn from other developers
specially from those who are building applications more complex than the ones we are building, but not exclusively.
There is no perfect language or perfect workflow
most of the things vary based upon your preferences and scope of the project.
We can’t have everything at once…
we always need to sacrifice something in exchange of something that we value more.

Background

When you have more than 30 developers working full-time in a single application writing hundreds of thousands lines of code you need to follow a work-flow completely different than someone that is building an application that has ~10.000 lines of code written by 1-3 developers and specially from someone that is building an application with less than 1.000 lines of code by himself, even the client and use of the application changes the methodologies/tools that you should use, it isn’t only about the size/complexity, but also about the goals… You can’t code a system for a large bank on the same way you code a blog for a small shop, it would be unpractical and conceptually wrong

The “bias” problem

I feel that there is a strong bias towards Java/C#/AS3 from the Ruby/JavaScript/Python comunities and vice-versa. I know that everyone has their own reasons and that some people even switched from one language to another after getting frustrated, but you can’t be pretentious enough to simply believe that a whole community of smart developers, that sometimes are way more experienced than yourself, been doing things completely wrong over the past 5, 10, 20+ years, it simply doesn’t make any sense… Some things may not fit your needs but that doesn’t mean that they are wrong.

Enterprise developers have their reasons to do things the way they do as well as developers that works on a small team and with simple projects, nobody is completely right or wrong when you talk about these things specially when the scope is different… People have different needs and problems that they need to solve, so it’s more than common that they disagree about the proper approach, you can’t compare the problems that an Assembly Language developer that works coding drivers is having with the ones that a PHP developer that is mostly doing CMS experienced so far, it’s like comparing bananas to oranges.

Learn why things were created so you can judge when to use them

Object Oriented Programming, Test-driven Development, Continuous Integration, Functional Programming, etc, where all created with the same purpose, solve specific problems that a specific group of people were encountering at a specific moment, yeah it’s really specific, that’s why I repeated it so much, it doesn’t solve all problems and it isn’t the best approach for every single occasion…

A smart person learn from other peoples’ mistakes

I really believe that the developers of static/strong-typed languages have a lot to learn from the dynamic languages community, specially how to be productive and to work on a fast-paced environment keeping things simple and caring less about the maintainace/organization of the code, however, the dynamic/loosely-typed developers, have a lot to learn about how to keep the code organized/better structured and how to build scalable/maintainable applications while working with a large team… – Everybody has something new to learn.

There is no “universal” approach

I used to believe that the more academical/technical approach was always the right choice for any kind of project/problem, but after sometime coding and looking at other people’s code I started to realize that it depends on a series of rules: the scope of the project, number of developers working together, client, expected lifetime of the application, etc. You shouldn’t use the same workflow if you are building a completely different kind of application…

The “a little bit more complex” rule

Another thing that I kind figured out after some time following blogs from many different developers of different languages/skill-levels is that the opinions that made more sense for me (at that specific time) usually came from people that where building things “just a little bit more complex” than the ones I was building.

People that are building applications 10x more complex are probably experiencing problems that I’m probably not going to encounter anytime soon, so their opinion was more a heads-up for the future than actually something useful/important for the present. If your website is far from being on the top 100 Alexa rank then you shouldn’t be caring about the same things those people are, your problems and goals are different…

Conclusion

We should always try to foresee problems and build things following as many best practices as we can, but it’s also important to fully understand our needs to avoid over-complicating a project without need and most important, find the balance between “speed” and “safety”, which I think it’s the hardest part of being a developer.

It’s a key factor to understand why people created those rules and which kind of problems they solve/create so you can decide when to bend them, always remember:

“There is no spoon”

I hope that at least a couple people stop being so biased against other languages/workflows just because they don’t fit their current needs… I’m sure things won’t change that easily, but at least I’ve said something…

Thanks!


Comments

[...] There is no spoon Tags: best practices, design patterns, javascript, random thoughts Comments (0) [...]

So, if you're an emerging or underdeveloped artist, head on over to CMC's website to find out how you can submit an application for D49.

You have to go through a lot of hassles, disruption of work schedule, interrupted routine chores and many such hurdles that have to be sorted in parallel to the shifting. We were moving from Carroll Gardens to Brooklyn Heights and needed to hire a moving company to help.

Check out my web blog you pack moving companies syracuse ([Lucy](http://www.youtube.com/watch?v=L4FuGSLEMyg "Lucy"))

Leave a Comment

Please post only comments that will add value to the content of this page. Please read the about page to understand the objective of this blog and the way I think about it. Thanks.

Comments are parsed as Markdown and you can use basic HTML tags (a, blockquote, cite, code, del, em, strong) but some code may be striped if not escaped (specially PHP and HTML tags that aren't on the list). Line and paragraph breaks automatic. Code blocks should be indented with 4 spaces.