4 ms·
You're joking right? Most of these are actually counter-productive, and god help anyone who follows all of them. It's the most beautiful collection of group-thi
by radu_floricica 18y ago
You're joking right? Most of these are actually counter-productive, and god help anyone who follows all of them.
It's the most beautiful collection of group-think in programming I've seen in a long time.
I've been doing web apps programming for a few years now, and I do admit there are better technologies out there. That's why I've been dipping my feet in lisp for the past year, and lately spending my nights with Clojure. But what he's advocating isn't good programming, it's sheep mentality, and I'm disapointed to see it here.
But since it's not nice to just be a critic:
* You’re not building atop an open-source framework
* You’re writing your own framework upon which to build
I have open source above, open source below and open source in the database. But holding it all together is a thin layer written by me, simply because I want to be able to adjust it as much and as often as I feel like.
* You’re not using an ORM layer
* You’re writing your own ORM layer
I actually played with writing my own a few year back. In the meantime I thought a lot of times about its benefits and I ultimately decided against using one. Why? Because I only ever use one database engine, and if I change it it will definitely happen on a new app. Also I value too much development speed and flexibility. I saw code developed with ORM, and I still have see xml in my nightmares. Granted, it will probably work in many contexts, and if/when I switch to lisp I will probably use a persistance engine instead of a database, but now and for me it's definitely not an advantage.
* You believe you can write it faster or better or more efficiently than any available library
You can, always. It's only a matter of effort invested. In most cases, the years necessary are not worth it, but very ocasionaly it pays.
* You have more than one developer on your project and no written coding style guidelines
I usually poke them on the head when they forget spaces. I most certainly don't waste time with written specs.
* Your bug tracker serves as your functional scope or your development roadmap
Actually it does. Took it from google: the best project management tool is a queue. Put stuff at one end, solve at the other. And also, we don't believe in deadlines.
* You aren’t using source control
We are and like it.
* You comment the what but not the why
We never comment. Ever. We spend lunch breakes thinking up intelligent variable names.
* You tend to pass properties instead of instances to functions
No idea what this is, but we probably do it.
* Your “deployment procedure” involves any combination of FTP and/or drag n’ drop
More like scripting and ssh. This one's ok.
* You write code in a manner that cannot be unit tested
We don't unit test. True, it hurts ocasionaly, but at the amount of new (good) code we write, it's not really necessary. What we do (well, I at least and I'm evangelical about it) is read and re-read code, preferably before compiling.
* Your primary method of code reuse is copy/paste
No comment.
* You don’t read any development blogs focused on your primary and secondary languages or technologies
LOL
* You haven’t been to a conference or birds-of-a-feather meeting in the past year
Really lol'ed this time.
* The only code you read at work is your own
And my coworkers. True.
* You worry that some day someone else will read your code and know it was written by you
Don't. True.
- william42 18y agoI don't understand object-relational mapping. At all. If your data is not organized relationally, why are you using a relational database?