FoWA: Happy programming with Ruby on Rails – David Heinemeier Hansson

Silver bullet for developers – motivation. We should be focusing on productive and motivation in our development, in the work we do. Not enough to be just working in an interesting domain, or customers who appreciate what you do, but you also need to enjoy the mundane things of what you do.

I’m most motivated when I’m happy. Motivation comes from happiness. Not far down to say that if happiness, is the key ingredient for motivation we should optimise for happiness to optimise for productivity.

Used to be a programmer who didn’t like programming, liked the end result but not the process of programming. Didn’t find that exciting. But found there was one key factor that me me happy about doing the actual work and for me that’s beautiful code.

Beautiful code is one of those things that’s hard to explain, it’s about feeling good about a single statement, expressing what you want to say in a way that’s aesthetically pleasing, that’s understandable, that’s right.

Your app is not a unique snowflake. It is not special. Hard for people to deal with the fact that they are not special. Most parts of most apps are just like everyone else’s. Most people do the same most of the time.

So Ruby on Rails optimises for the 80% of the workloads. Can’t optimise for special, can abstract special. So that’s not the work that we focus on with RoR, because it’s too hard.

To get people on board with this they have to believe that 80% of what they do is the same as everyone else, and the last 20% is special, is the snowflake.

One technique for making beautiful code is the notion of convention over configuration. Configuration is the annoying part of making software. First you do the work, then you tell the system how you did the work, then you tell another part of the system how you did the work. Programmers don’t like repetition. So beautiful code does not repeat itself. It express what it needs to express just once.

[Gives example of code.]

Look for patterns to abstract, conventions say in mapping. Look for relationships between things. Conventions are there for the 80% of the time. When you work inside those conventions, you don’t need to do work, because you can get the conventions to do it.

Configure once, the move on.

Flexibility is overrated. Assumption is that flexibility is good. Trading valuable parts of your system away to get flexibility, and usually not worth it. Should stop chasing flexibility.

Constrains are liberating. If you think about what most people are doing most of the time, you’ll get systems which are consistent.

Devil shows you the easy way, where something gets done today but tomorrow is tomorrow. On the other hand, the angel tells you to test things.

Not about whether something is possible or impossible, it’s about whether it should be encourage or discouraged. At this point I realised that PHP is the devil, because PHP was constantly giving me temptation to do the ugly thing. The whole language just encouraged me to be a slob. Yes, I could fight that, and that works until the pressure’s on, and then you listen to the devil.

Ruby on Rails is the angels, we’re trying to embed the angel on RoR. We’re making it easier to do the right thing, the clean thing, the pure thing, than the hack. You have to go out of your way to do something ugly.

Create invitations to do better, reminding you that you should be consistent, that you should be creating tests, and that you get benefits from doing things the right way.

We do this by allowing common patterns but showing you there is a better way to deal with these common patterns.

Conventions

Invitations

Opportunities

Expectation

Want to set up a community of expectation that people are interested in doing the right things, the clean things.

[Another code example. Hard to take notes on code without the examples.]

Extracting common usage. Reduce mental effort. Sometimes the beautiful thing is to get out of the way. Sometimes, the beautiful thing is not to try to abstract, but to be a snowflake, do the unique thing.

What do you need to use RoR

– Feel the hurt. If you don’t feel the hurt, don’t hear the devil whispering in your ear, you’re not ready for RoR yet.

– Appreciate agile. That a functional spec is evil. Appreciate tests.

– You can skip the vendor. ‘I’m not here for you’. Open source because you want to help yourself. Rails is solution to problems faced by the contributors.

Does it scale? Yes.

Comments are closed.