Scott Radcliff

Talks

In The Case for Leaning Out, Nico Lang describes the American work ethic. No, ethic isn't the right word. Obsession. That's better. Nico Lang describes America's obsession with work. We work at work, after work, before work, when we are with our families, and even when we are on vacation.

This article hit me right between the eyes. As a developer, it's super easy to get caught up in dollar signs and the glorified startup life. It's important to remember the sacrifices required to even get a glimpse of any of that. To me, it's not worth it.

The problem, of course, isn’t just our jobs: We’re working even when we’re not working. We go to happy hour with our coworkers after we get off, share a beer in the office and loiter socially before we leave, take our laptops home when we just have to finish just one more spreadsheet for tomorrow’s meeting, check emails over brunch, and shuffle outside to take an “important call” while everybody else is ordering mimosas. If you’re a writer, your social life likely consists of going to parties with other writers, who will, inevitably, talk about writing; even when we leave work, we can’t shut up about it.

Ouch.

The Italians have a concept called “la dolce far niente,” which translates to “the sweetness of doing nothing.” In context, that phrase might recall Diane Lane tromping through the vineyards of Tuscany, stepping on grapes, and having PG-13 romances, but for the overworked cubicle dweller, the sweet life begins when we learn to lean out. Amy Poehler calls it “healthy detachment,” but the Zen spiritual leader Thich Nhat Hanh describes it as “letting go.” Hanh writes, “Letting go gives us freedom, and freedom is the only condition for happiness. If, in our heart, we still cling to anything—anger, anxiety, or possessions—we cannot be free.”

I'm the type of guy that likes control. I like to know how things are working so that when they break, and they will break, I know how to fix them. This can be a good thing and a bad thing. It's a good thing because I think it makes me a better developer. I've never regretted learning something about the systems I work with. It's bad because I generally don't like systems that do stuff for me. Even though they may be saving me work.

Take Heroku for example. It can save a ton of time. But what happens when it breaks? What happens when it doesn't support what I want to do? As far as I know, I still can't write to the file system on Heroku. So I don't use it for my projects. I manage my own VPS. It's not that hard. Seriously.

Even though managing a VPS is relatively simple, it can make deploying more work that it has to be. Capistrano and other tools are way too much.

I've done dinosaur deploys for a long time. Push to some repo. SSH into my server, pull, and run any asset or bundling tasks I need.

That is until I started looking at post-receive hooks in Git. These are awesome and exactly what I need. I haven't played with them yet, but I will be. I think I can squeeze in an hour or so to play tomorrow.

Here is one of the better articles on how post-receive hooks work when you host your own git repos.

As I continue my dive into JavaScript frameworks and currently working with Ember, I really struggle with knowing what Ember wants me to do.

With Rails, the server log usually gives me a clue. With Ember the server log, or output, is less helpful. Part of the reason for this is because Ember seems to silently handle errors. I think part of the reason is that Ember is doing things for me, and part of it is the fact that JavaScript loves to fail silently.

When working with a feature in an existing Ember app, I needed to now what controller Ember expects. I had a form using Dockyard’s super cool EasyForm, but every time I submitted the form, the console would yell at me saying that my controller didn’t handle the action.

After hours of reading docs and trying to understand how the controller was wired up for this form, a coworker had the perfect solution.

{{controller}}

Place that code in your template and it will print what controller that template is tied to.

I think of this as similar to Ruby’s debug method, where I can print out data in the view so I can try and diagnose errors I don’t understand.

It’s not a great solution. Some sort of proper debugging method would be way more helpful, but it works for now.

I’ve been playing with a new Sinatra app. While I am building it out, I am getting back to basics. I’m only adding what I need as I need it. I really have no preconceptions of what I am building. It’s a journaling app, and I am just starting with a big ‘ol textarea.

Keeping with simplicity, my database is super simple. I am just using sqlite and accessing it via the Sequel Rubygem.

While putting things together, I had some crappy data I wanted to clear out, but didn’t want to write some method to reset the database or setup environments yet. Turns out it’s pretty simple with Sequel.

With a sqlite database called journal and a table called entries, in a terminal, I just run

I will be presenting at self.conference on May 29-30. Not sure about the time slot yet.

I’ve been working on 100% remote team for about six months, and it’s been unlike any remote team I have been on before. Some things have worked well for us, and many things have not.

I will be presenting on what we have learned about working remote. Some things you can try, what types of things you want to avoid, and some tips to help make your team a little tighter when you are all spread out.

It’s no secret that I have an issue with Startups. Not the idea of startups, but the community around startups. The whole thing is based on getting a hit. Building something you don’t care about to get rich. In it’s essence, the majority of the startup scene is equal to a giant get rich quick scheme. And if you’re a developer, it’s more like a pyramid scheme and you are at the bottom doing the work and getting the least reward. Unless of course, it’s a hit. Then you get climb up the pyramid and be a cherished success story.

Business, at it’s core is not that hard.

Here it is, in it’s simplest form.

Find a market

Discover what that market wants/needs

Build what that market wants/needs

Sell the product

You don’t need some stupid vocabulary. You don’t need follow some stupid community that is run by billionaires that want to capitalize on your skills. All you need is a problem to solve that is worth paying for and the skills to solve it.

I never really thought it would happen. I never thought I would be the guy that was having trouble learning new things. Learning new ways of progressing my craft.

But this has happened. I’m a beginner again and it’s proving to be difficult.

I’ve been using Ember on a project and on most days I’m drowning. Ember does a lot of stuff I don’t understand. Figuring out what that stuff is, is the hard part.

Ember really isn’t a DOM framework. JavaScript works differently inside of Ember. I have to change the way I think of JavaScript. It’s no longer elements and traversing through them. It’s now all objects and properties.

Objects and properties aren’t difficult to understand. That’s just basic programming stuff. It’s how they get wired up that doesn’t make sense most of the time.

I think this would be much easier for a beginner. If someone doesn’t have any prior knowledge of DHTML and jQuery, there are fewer hurdles to get over.

I’m starting to come around to Ember. It certainly hasn’t been easy. I have to swallow a lot of pride. I have to ask a lot of questions that seem simple. These are questions that I haven’t asked in years. Things like how to submit form data. Stop laughing. Or how to link pages together.

If you have been programming for a while and are thinking about trying out Ember. Forget what you currently know about JavaScript, forget the DOM, think in objects and properties, and know that there is a lot of magic.

Timebox the feature you are working on. If you can’t get to a working solution in that time, swallow your pride, and ask for help.

I'm setting here in a car repair place using their completely crappy wifi. Seriously. This may be the worst wifi I have ever experienced. It would be better to not offer any.

But that's not what I want to talk about. I want to talk about how incredibly terrible these places are. There are reasons why customers don't like coming here. They get taken advantage of. Every single time. Call it an upsell if you prefer, but that isn't what it is. It's taking advantage of your customer because you have the upper hand. It's cheap, unethical, and void of any morals. Just awful.

So if the way most mechanics try to cough upsell cough their customers is wrong, what could they do differently?

Simple.

Provide the customer the service they need. Or the service they asked for. And then take your upsells and compile them into a list. Provide that list under the current charges with a valid reason why the customer might want to purchase them.

Provide them what they asked for, and what you suggest. Allow them to just buy what they want. Without hassle.

Present the additional services as problems being solved. There is not a customer in the world that cares about something, let alone paying for something, that isn't a problem.

Here are your charges today Mr. Radcliff. I've taken the liberty to add some suggestions below. Ohio winters are really hard on vehicles and these services will help keep you running with piece of mind that a family member won't be stranded somewhere with a broken vehicle.

You got me! You just told me that this will help make sure my wife doesn't get stuck somewhere. That is super important to me. And I'm reaching for my wallet.