May 16

It Takes All Kinds

After reading a blog post provocatively called “Today I accept that Rails is yesterday’s software” I felt the need to reply. I’m not sure why, I’m not going to convince anyone of anything, definitely not the author of that post. I want to reply because Rails is my current platform of choice, and let’s be honest, seeing a blog post with a title like that getting passed around makes you squirm a little. I think it made me squirm in a good way, because it caused me to step back and evaluate what I’m doing, and why. Enough with the back story, on with the show…

It always comes back to the tools. Everyone blames the tools. And there is good reason for that. Tools empower us. Tools hold us back. Tools excite us. Sharp tools allow us to stab ourselves. Dull tools don’t allow us to get much done. Some tools are optimized for safety. Some are optimized for speed. Some tools are optimized for flexibility, others push you down a happy path. But at the end of the day, they are tools. The only value they have is in what you can create with them. Your tool can be safe, efficient, shiny, but if no one uses it, it is just a dead lump of code.

These tools we have allow us to create amazing things. Many of these tools are quite complex. They try to hide a lot of that from us, but at the end of the day, modern web applications are complex beasts. Anyone involved in the creation of a web application knows that there are so many moving parts and pieces involved that it is mind boggling. There is no way you could fit everything you need to build a website into a single framework, even a framework as large as Rails or Django.

And you would never want it that way, everyone needs to do something different. You need a framework that is optimized for what you’re trying to do. The framework is there to provide us with a doctrine and the ecosystem that builds up around it is what makes it powerful.

What are you optimizing for?

Everyone is optimizing for something different. Is Rails a good choice for every shop? No way. Is it a good choice for your shop? I don’t know. What are you optimizing for? Are you a big team that is looking for safe tools which allow you to reliably refactor and give you a lot of compile time safety? Then Rails would be a terrible choice. Are you a small/medium development shop who needs to be able to stand up and maintain an application easily while leveraging a huge amount of community code/knowledge to get that done? Then a framework like Rails/Django/Laravel might be just the thing you need.

Alternatively maybe all of your developers know Python, then go with Django! The whole point is that you should pick tools/techniques that fit your team, don’t just grab the newest hippest tool off the shelf unless it solves some very concrete problems you currently have, or you are going to feel some pain. Maybe a lot of pain. And I don’t mean the kind of hand-wavey “we can do better” type problems, I’m talking about solid technical problems that you can put your finger on.

Looking for something better, or just different?

In the post I mentioned above it sounds like the author has a lot of frustration with his tooling. I’m sure that is something that everyone has experienced. I can’t speak to his exact issues, we don’t seem to have many of the same issues, but that doesn’t mean they don’t exist. Just as an anecdote though, I have often found that developers working in a framework for years get a ‘boiling the frog’ moment where they just accept poor ergonomics in their environment for years until someone new comes along and points them out, or they just lose their mind and flip out. Once you look for a solution, you’ll often find that it was a problem in your workflow all along, because more often than not, broken tools don’t stick around in the open source world. Can’t say the same thing for other ecosystems though.

The whole point is, don’t throw out the baby with the bathwater. These frameworks are complex. Software is complex. Sometimes they don’t play well together, but if you’re running into silly problems with your tools then you should be looking for solutions, not to throw everything out and reboot. If you’re a consultant, then those types of reboots can more easily occur, and are often very lucrative, but they are rarely good for your clients.

My problems aren’t your problems.

I constantly find myself waxing to other developers about how we, as a group, seem to be stuck in the mindset that all developers have the same problems. The tools and frameworks that Facebook, Twitter, Google, etc… use must be the best, and because I want to be the best, I must use them. Well guess what, you don’t have the same problems they do. They have a virtually unlimited amount of developer time, you probably don’t.

Would I ever tell you to not use Elixir/Phoenix, Node.js, Revel, Iron, etc…? No, of course not, I don’t know what your problems are. But what I would tell you to do is to thoroughly evaluate each one based on your needs. What libraries do you need? What are you willing to write yourself? What is the longevity of the tools? What tools are available to you for deployment/hosting/management/troubleshooting? What is the skill-set of your team? These are all critical questions to ask when evaluating a platform, and if you’re not asking them then you probably don’t know what you’re getting yourself into.

Yesterday? Today? Tomorrow?

Is Rails yesterday’s software? Sure. So is PHP. So is C#. So is Python. So is every web framework that has come before. It is mature. It doesn’t mean that it isn’t today’s software, or even tomorrow’s. It just means that it has been around for a while. Are there better platforms out there? Depends on what you’re doing. Are there better frameworks for what we do? Probably not. But I don’t know you and your problems, you have to make these decisions on your own. Taking ownership of that is always scarier than listening to a bunch of loud consultants and bloggers proclaiming that they have the future in their pocket.

It takes all kinds.

I tend to be harsh sometimes on developers who always jump on the new shiny tool, but the reality is that we need those people (even if I don’t want to have to maintain their projects). We need the trailblazers, because if we didn’t, there wouldn’t be a trail for the rest of us to follow. If Rails didn’t have those people 10 years ago then it wouldn’t be anywhere near where it is now. It never would have been able to push through those tough early years where running, deploying, hosting, and maintaining a Rails app was a really painful process. This is where a lot of these frameworks are now, and that is exciting. I really hope to see many of them mature into stable/reliable platforms and ecosystems. And one day, for what I do, another framework will pop up that will be a better choice than Rails. And I’ll probably move on to build amazing things with that framework.

But guess what, when that time comes, there will be somebody writing a blog post telling me my new platform is old news and I’ll quietly close my browser, fight the urge to write a blog post, and get back to work. Just like I should have done today.

Jul 12

Preparing Yourself for Modern JavaScript Development

There is a lot going on in the JavaScript world these days, both in and out of the browser. Talk about script loaders, client side MVC frameworks, minifiers, AMD, Common.js, Coffeescript, can quickly get your head spinning. And for those people who are completely immersed in that world, it can be easy to forget that the vast majority of JavaScript developers today haven’t heard of any of these tools, and in fact, they likely aren’t even equipped to try these tools.

This post is going to be an attempt to simply address some of the low hanging fruit out there, and try to bring together a few different concepts that a developer should understand before they go out and try to tackle something like Backbone.js or Ember.js. Once you understand most of the concepts in this post, then you can go out and approach more advanced JavaScript topics with a bit of confidence. This post does assume that you have developed with JavaScript before, so if you haven’t, then you might be better off starting with something a bit more basic. With that out of the way, here we go!
Continue reading →

May 12

Big Changes Are Afoot!

The last 6 months have been quite the whirlwind for me! My wife and I had our first child just over 6 months ago, and I’m starting to realize how much free time I had before that! He is wonderful, but it has forced me to push a lot of things aside in order to focus my time on him. I’ve been attending less conferences, writing less, and reading less. I still do way too much work after hours, but hey, I can’t just quit cold turkey!

Besides having my first child, the other big change that I am finally ready to announce is that Al Tenhundfeld has agreed to partner with me at Ecstatic Labs! I’m truly excited about working with one of my best friends, and at the same time I am also excited about what we are going to be able to accomplish. I am going to be rebranding CodeThinked to be the “official” blog of Ecstatic Labs, and both Al and I will be blogging on here. Hopefully that will bring the number of posts back to an acceptable level.

We can’t wait to see what the future holds! Thank you for all of your support!

Apr 12

Developers, Go Forth And Cross Pollinate!

If there is one thing that I have learned in my life, it is that you never learn anything by surrounding yourself with people who agree with you. Putting yourself in a giant echo chamber only serves to amplify and reinforce all the the ideas and beliefs that you hold. And at the same time, it amplifies and reinforces all of your prejudices, stereotypes, and superstitions that you hold.

The same holds true for your career as a developer, you’ll never learn anything new if all you do is surround yourself with other developers who are using the exact same tools and patterns as you. Unfortunately, it is really hard to not do that. How do you surround yourself with developers that don’t use the same tools and patterns as you? I don’t know about you, but most of the teams that I have worked on mostly use all of the same tools and patterns. They solve problems in the same way, and they rarely stray from the tools and patterns that they are most familiar with. And there is a reason for that! A high performing team will leverage the tools and patterns that they know work well, while bringing in additional tools as patterns only as they need them. This allows them to reliably and predictably deliver quality software. This is often an ideal case though, many teams rarely, if ever, bring in new tools and patterns for fear that they will introduce too many unknowns.
Continue reading →

Dec 11

A Case For Using CoffeeScript

If you’re interested in CoffeeScript, then I’m sure by now you have read Ryan Florence’s blog post titled “A Case Against Using CoffeeScript”. In this post, Ryan explains that he uses CoffeeScript at work, and he likes the language, but in his opinion it is too difficult to comprehend and too difficult to debug. My response to this, in the immortal words of Dwight Schrute, “false!”

Before we get started, let me just say that this article is more about disagreeing with some of the statements made in Ryan’s post, its purpose is not to “sell” you on CoffeeScript, but merely point out that CoffeeScript is not something to be scared of. If you want somewhere to show you how awesome CoffeeScript is, I would recommend checking out the official CoffeeScript site and CoffeeScript is for Closers by Brandon Satrom.

Continue reading →