41–50 of 75 posts
I'm primarily a Ruby developer. Literally every single time I've started a web-oriented project using something like Sinatra or Padrino etc., I've ended up regretting it. I end up building a shitty, half-featured, buggy version of Rails. My experience is that most other projects end up the same.
I suppose mileage may vary; perhaps it's easier to write bloated apps in Rails. I'm not convinced that's a good reason to avoid it, though.
I think the article makes a good point. Counter-point: at least in the open source world, popularity can translate into lots of eyeballs on the code, lots of bug fixes, better ability to hunt down solutions on Google, hire people, etc. Counter-counter-point: lots of people depending on a project may slow its progress and prevent its maintainers from correcting fundamental design mistakes, all for fear of breaking exi…
Even in a non-open-source tool, lots of users means lots of reference on Stack Overflow, and an exponentially better chance of not encountering bugs for your particular use-case.
Any framework of moderate size has bugs in it. The only question is, has the bug that would slow you down been fixed yet?
That's why the size of the alternative is so important. If the alternative is just 300 lines of code (as in this case), then even if you do run into bugs, fixing them is gonna be trivial. But what about 3,000 lines? 30,000? ...
I wouldn't say everybody should automatically go with the popular option, because this kind of herd mentality can really be destructive. If another, less popular tool seems better for your use, give it a fair consideration. I've actually personally chosen that route several times, and I would again. But by doing so you accept the strong possibility of dealing with bugs which your competition doesn't need to worry about.
Earlier quoted context omitted.
One of the problems with popularity is you will get a lot of mediocre developers who don't know what they are doing. You know, the people who pick up tools only because they think it will land them a job more easily. The same people who picked up VB. I understand that you're saying it's a bad practice to adopt a tool for reasons other than its utility in addressing a specific problem. But is it really so terrible for…
Yes. However, software companies that hire for a specific popular tool/framework need to be punished with mediocrity.
It's not mediocrity, it's called playing to your advantages.
Earlier quoted context omitted.
Yes. However, software companies that hire for a specific popular tool/framework need to be punished with mediocrity.
Why? If I'm running a business and I intersect closely between the business side and software side of the company, but need help on the side. I'm hiring for the stack that I use and already understand. It's not mediocrity, it's called playing to your advantages.
On the flipside, "Is this task so special that we need to break from the pack?"
Really I think the developers just chose Cuba more than anything so that they could scratch the itch of getting to try something new,
Earlier quoted context omitted.
Why? If I'm running a business and I intersect closely between the business side and software side of the company, but need help on the side. I'm hiring for the stack that I use and already understand. It's not mediocrity, it's called playing to your advantages.
Why not hire smart people who can learn your stack?
He talks about the virtue of using new and untested languages and frameworks. The example he uses is Twitter's use of the relatively new Ruby on Rails framework. Unfortunately for him, this is a bad example. Twitter was notorious in its early days for being down all the time. So Twitter decided to migrate to Java - a dull, over-verbose, yet reliable language.
1. Small team, small budget, smaller set of technical skills.
2. The need to do a lot with less.
For these needs, I would argue that Rails was the perfect tool for Twitter early on. It likely gave them a competitive advantage in their development.
However as with all fast growing prodcts, nearly every app experiences a new set of challenges every time its traffic scales up by an order of magnitude. Twitter being an extreme example of among the most difficult-to-scale apps you can imagine (data is rapidly being created and read -- by its nature its inherently hard to cache).
Their original app was built by relatively inexperienced developers hacking together an MVP. By the time they reached scale the had a roster of senior developers capable of rebuilding the system way more professionally than they ever could have in the early days. Rebuilding the core functionality was trivial, and this time, they could build it from the ground up to support 5000+ tweets a second.
One of the problems with popularity is you will get a lot of mediocre developers who don't know what they are doing. You know, the people who pick up tools only because they think it will land them a job more easily. The same people who picked up VB. You can't build a product with a mediocre team, no matter what tools you have. If you have a decent team, I think they will be able to manage to build great products eve…
One of the problems with popularity is you will get a lot of mediocre developers who don't know what they are doing. You know, the people who pick up tools only because they think it will land them a job more easily. The same people who picked up VB. I understand that you're saying it's a bad practice to adopt a tool for reasons other than its utility in addressing a specific problem. But is it really so terrible for…
There are types of developers who are very limited in what they can do. They learn some basic "tricks" in the form of "If write this magic spell, I get this magic result".
These are the mediocre developers.
They tend to pick some popular tool and try to market themselves as "an X developer" where X is something that's popular right now.
Then there are developers who can create magic. They can build something almost from scratch without having to have a library that already does it for them. These developers can pick up X or Y or Z in a week or two and then they will become 20x more productive with it than the mediocre developers are.
I'm not saying it's a bad thing to pick up a tool to market yourself as an "X developer". I'm just saying there's a lot more mediocre people in the pool of "X developer", and if that's what you go looking for, you'll get mostly mediocre people.
That Knuth quote by itself is interesting. Perhaps he is not suggesting that popular ideas likely to be are wrong. Instead maybe he is saying that to think and develop ideas like Knuth's one needs a certain amount of irreverance for what is popular. (Undue?) reverance is rampant in the software industry, in my opinion. Would Knuth agree?
An extended version of the quote would be "Don't just believe that because something is trendy, that it's good. I would go the other extreme where if I find too many people adopting a certain idea I'd probably think it's wrong. Or if my work had become too popular I probably would think I have to change." I took it from this video: https://www.youtube.com/watch?v=75Ju0eM5T2c
The "elite" developers (who often don't actually maintain real production apps, or need to live with the consequences of their design choices) begin to fad over a new language. O'Reilly publishes a book and sure enough... Influential senior developers who obsess over these elites start fangirling, leading them to convince their bosses/teams/companies to also adopt this new "cool" technology. As the popular tide of generic bandwagoners rises, the "elite" developer begin to feel the pressures of wanting to redefine their identity again, and soon jump ship to switch to the next hot thing.
Then the process repeats...
Earlier quoted context omitted.
Why not hire smart people who can learn your stack?
A bright person can pick up a new language or framework in a few days or less, but it will take some time working in that ecosystem before they're really writing natural and idiomatic code. All other things being equal, I would prefer to hire someone who has experience in the same stack.
If you don't move to a new stack, how's your retention?