tagged with:

Quitting Eligo 

I was tempted to use the word sunsetting as a joke but then thought better of it. I tried to change to the world through easier appointment scheduling </joke>. Jokes aside, I ceased development on Eligo. Why? I had a mostly feature complete alpha working but I was never using it myself. When I asked why this was, I realized that what I was trying to do was a problem solved by better communication. Throwing technology at the simple task of finding a time to meet with someone is impersonal and perhaps even a little rude.

I really don’t feel bad about the time I spent on Eligo. It allowed me to learn to use Elixir and the Phoenix Framework which set me up well for my current gig at Spinlist. This was the first time I deployed an app on FreeBSD. I got to try some new programming techniques, which can be a challenge to do on client projects, and I even got to experiment with different business methodologies add learn that they certainly weren’t for me.

There were only a handful of people (all of whom I was close to) experimenting with the service so there really isn’t much more to say and far as the shutdown goes. The servers will be off and the domain inaccessible as soon as I hit “destroy” on the Digital Ocean instances.

The next side project that I do is going to be less focused on being a business and more focused on solving a problem that I have. I want it to be fun and useful and I want it to be built ethically and correctly. It will focus on the things that I’m good at: simple clear UI—as opposed to being trendy—and snappy interfaces and response times. Ideally I’d like to do something involving one of my big passions: travel.

Posted on the

tagged with:

Eligo Alpha Launched! 

At the end of last week I quietly launched an alpha version of Eligo. The saying goes something like this: if you’re not embarassed by your first version then you waited too long to launch. I’m certainly telling myself that now that it is out there for everyone to see. I’ve been letting a handful of people kick the tires but there is still so much that needs to be done. So much so that I’m tempted to call it a “pre-alpha”.

If you’re interested in seeing what a half-backed web service looks like, reach out to me directly or use the waiting list for on the Eligo homepage.

Posted on the

tagged with:

Last Week I Nearly Gave Up & I’m Glad That I Didn’t 

Posted on the

Exactly a week ago today I posted that I had been having a slow week while working on Eligo. But that wasn’t even the worst of it. By the end of that day I was starting to talk myself out of making Eligo altogether. If you’ve worked on any sort of large, personal, creative project before then you’ve likely done the same. Maybe you even gave in. I almost did. I was asking myself things like “is this even worth it?” and “will anyone use this?”. I was telling myself that the answer to these questions was a resounding “no”.

One thing missing from this discussion that I was having with myself inside of my head was my reasoning for working on Eligo in the first place. The real purpose of the project, which I talked about in my announcement post, wasn’t so people could use it. I was working on Eligo to get back into the habit of working towards something. Giving up in the middle didn’t seem like a great way to make a habit. So I decided to persist.

I’m not sure if these two things are related or not—it’s impossible to detach the two in my mind—but the moment after I decided to keep going I had a bit of an epiphany: the design was all wrong. Keep in mind that I had already redesigned once. “Surely I can’t rip everything out again”, I thought to myself. All of those start up guys talk about “good enough” constantly. Couldn’t this design be just that: good enough? Once I asked myself who I was doing this for, the answer to the question of it being good enough was obvious. It was not.

I talked to my wife about it. While she was encouraging about my decision to scrap the direction that wasn’t working, she urged me to sleep on it. And I did. But it was hard. I feared that I was going to loose all of the energy and positivity I had just acquired. I had vague ideas in my head of a direction to take the design and I had an even clearer picture of what was wrong with the current design. I wrote down everything that was floating around in my brain and went to bed. Against all odds, I was able to get a full night’s rest. And you know what happened? I woke up positive and with an even clearer picture of where I needed to take Eligo.

I got to work immediately and by the time my family had awoke, a few hours after I did, I had a clear direction for the design of the product. I was working quickly and efficiently. Things were coming together. By the end of the day I had a very solid style guide for the product committed to the project’s code repository. I had gotten more done that Friday by 5:00pm than I had the whole rest of the week.

I was encouraged by what had happened when I went to bed with unfinished ideas the night before. So I did something similar and contrary to what my brain was urging me to do: I put the project aside for the weekend. I spent time with friends and enjoyed the beautiful weather we were having here in Southwest Missouri on the porch with my family. I was thinking about the project constantly but was doing so away from the screen. I felt like I was doing honest-to-good problem solving in my head, rather than rummaging the internet for other people’s solutions to my problems.

Something magical happened again on Monday morning: I had the same productivity superpowers. In fact, they seemed even stronger than they were on Friday. Every decision I was making seemed to just be right. And if it wasn’t right, I was in a state of mind that I could see what was wrong and adjust easily. Things were simply coming together and the project was finally starting to feel like a product.

It’s Thursday morning now and I feel like I’ve had three weeks of productivity crammed into these past three days. The best part is that I haven’t been exhausting myself. I’ve still had to keep myself focused—which hasn’t been too difficult this week—but I’ve been making serious progress on Eligo. To top it off, I’ve been able to stop working around 4:30pm which, as a result, has helped me make progress on some of my other goals, like cooking dinner for my family most nights. And Eligo is in a great place. In fact, I hope to get the alpha up by the beginning of next week!

I don’t have a clear path to this elevated state of productivity. I wish I did. However, if you’re struggling to work through something, here are a couple of things you can try that worked for me this week:

  1. Spend some time away from the problem. I’ve read the advice from creative people before to “take a walk” when you’re at a mental roadblock. This can be very hard to do but it is wonderful advice. Detach yourself from your work and your brain may solve some of the problems for you when you’re not deliberately thinking about them. Your subconscious is better at solving problems than you probably realize it is.
  2. Don’t be afraid to scrap work you’ve already done. Its important to not get too attached to the work itself and instead focus on the quality of the outcome. If something isn’t right don’t continue working at it for work’s sake.
  3. Don’t exhaust your energy. This is related to point #1 but I think it’s important to separate it out. When you do find yourself with some energy, fight the urge to work until it’s been drained. This is especially difficult if you’re coming off of a productivity “dry spell”, like I was, where you fear that the next time you sit down to work the energy won’t be there. Fight the urge. Leave some of your ideas for tomorrow.

On that last point, Ernest Hemingway had some great advice for people writing a novel that I think applies to all creative work. He answers the question “How much should you write in a day?” with:

The best way is always to stop when you are going good and when you know what will happen next. If you do that every day when you are writing a novel you will never be stuck. That is the most valuable thing I can tell you so try to remember it.

— Ernest Hemingway “Monologue to the Maestro: A High Seas Letter” in Esquire, October 1935

I’m thankful that I stumbled upon some productivity this week. Although, at second glance stumble upon isn’t the right way to put it. I worked hard to get to here and I don’t think I’d be where I am on the project if I hadn’t gone through all those dead ends at the beginning. So perhaps that leaves us with one more point that didn’t make in onto the list. This may be the most important point: don’t give up.

tagged with:

Eligo Update: A Slow Week 

Those who have built a product before probably saw the writing on the wall after reading my last post and in hindsight I should have known better too. I’m still confident that I made the right choice at the end of last week but I should have known what better about was that it wouldn’t be smooth sailing. The excitment of a new direction will not last long when you’re doing the tedious work of reimplementing something that you have already worked on.

Posted on the

tagged with:

Scrapping What You’ve Done to Move Forward 

Yesterday I woke up no longer happy with the direction I was taking the design on Eligo. It was derivative, corporate, and even a bit faux-playful (think Hawaiian shirt day at the cubicle farm). My first instinct was to “finesse” the design into something that I would be happy with but after an hour of beating my head against the wall I realized that it needed to be ripped out and scrapped.

Design has always been something that I am able to get away with but I’ve never considered myself that great of a designing things. Design inspriation does not come cheap for me and I have no process or much talent to fall back on when things aren’t coming together. The only thing that I can rely on is my taste telling when something is right, which means a lot of iterations. Because of this, I tend to get really attached to my design work once I’ve settled on something. Even in the case of Eligo’s design where, from the beginning it never felt quite right, I sunk in my heels when I realized the design wasn’t going well. But, with some nudging from Luke Beard and Kyle Bragger, I ripped out the old design and started again.

Redoing what you’ve already done does not tend make you feel like you are oozing with productivity and at the end of the day yesterday I was feeling that maybe I had made a mistake. Luckily a tweet came accross my stream from Bastian Allgeier that made me realize that scapping what you’ve done is sometimes part of the process and it is a way to move forward:

design & development require one important common skill: being able to throw away your own work in order to come up with something better.

— Bastian Allegeier (@bastianallgeier) 13 Feburary 2016

I never have an problem ripping out code that I’ve written—in fact I enjoy it. So I’m trying to channel that same part of my personality with my design work. And so far I feel like getting similar results as when I scrap code: a simpler more deliberate design and UI. And I’m confident it will be for the best in the long run.

Posted on the

tagged with:

Naming Things is Difficult 

Posted on the

With my wife and I expecting our second child in a mere month, we’ve been talking about names a lot in our house. My wife was a teacher in a previous life and, even though she only worked in schools for a few years, she has a stockpile of names that rub her the wrong the way because of a terrible student she had. Not only that but names for children tend to not even sound appropriate until you’re forced to use them. I remember not being a huge fan of my daughter’s name when my wife first came up with it but now I can’t imagine calling her anything else.

There is an old proverb in software development that I first heard when I was in college and it goes something like: “There are two hard problems in computer science: cache invalidation and naming things. Every programmer has had variables named i or j that they have come to regret six months later when they are struggling to remember the purpose of a variable. But what is harder than naming variables and more akin to naming a child is naming a project or product. Obviously, everyone struggles with it which is why we have so many products that simply affix “ly” to the end of a word or, in years past, would drop the “e” from a word that ends in “er” (e.g. Flickr, Twittr, Tumblr).

So as I have been working on my new project I have been toiling over what to name the damn thing. I’m usually drawn simple, real words. Things like Bloom or Basecamp or even somethin generic like Pages. The thing is, those sort of words are awful for standing out to search engines. Should I expect people to search for “Schedule SasS” to find me if they can’t remember my domain? Not only that, generic domains are very expensive and since the service will work by sending links around—via email and SMS—I’d like to avoid a long domain like getscheduleapp.com just for the sake of having a .com.

So I’m left with the task of trying to invent a name. I spent sometime trying to coerce the words schedule and choose into weird combinations (without much success) until I had the idea start putting terms into Google Translate. The translation robot would have its way with a word and then I would start referencing the words in other languages that it would give me with available domains. After following this process for a couple words related to the project, I found a suitable word after translating the word choose into Latin: eligo. Its not an awful sounding word and everyone I’ve spoken the word to and then asked to spell it has spelled it correctly. There also isn’t an endless number of results when you search for the word. So I snagged a decent, short domain and settled in on the name.

Eligo certainly isn’t the sexiest name but has grown on me the more I use it. And now my little project has something to go by. Its already been nice referring to it in conversations with my wife at home by a name and just as “that scheduling app that I have been working on”.

tagged with:

Project Delay 

I used to not get sick very often but that all changed once we had a toddler in the house. Last week she picked up something up and brought it home and it went through our household like a plauge. I ended up being in bed all day on Monday, Tuesday, and Wednesday of this week and thus wasn’t able to make a lick of progress on my new project. I think I’ve kept myself from being morally defeated by those wasted days in bed and I’m excited to make the most of the remain days of this week.

Posted on the

tagged with:

Elixir, Phoenix, and Progress 

I’ve made some great progress on the scheduling app this week and I feel like I’m getting some momemtum on the project. This has been absent from the personal projects I’ve worked on lately so it feels good. I expect to have a very rough prototype done on Friday which my wife and I will start using ourselves the next week. I’d love to get some close friends using an alpha version by mid-February.

I decide to make this project the first real project that I use Elixir and the Phoenix framework. Its been a bit challenging to have things take a little longer to accomplish, having to get used to a new programming language/paradigm and new framework, but I am certain it will be pay off in the long run. Phoenix has been a wonderful framework to work with, even with the learning curve, and is more in-line with how I’ve been wanting to build web apps lately.

Posted on the

tagged with:

The Start of a Small Product 

Its been quite a week for me, if you’re keeping up. The end of the week looked much different than the beginning of the week did. At the beginning I was about to start on a large project with a new client and now here at the end, having choosen not work on the large project, I’m looking existentially at my work situation.

Yesterday I wrote about wanting to get a small product off the ground to get the ball rolling, so to speak, on making money from my own products again. After dwelling on the options I laid out in that post, I decided that it made the most sense to try making a small, useful web service. This is where I’d consider my skillset to be at expert level. I can get things done quickly and I understand all of the challenges of running a web service very well. Not only that, it seems like people are still willing to pay for a service whereas it seems as if most are finished paying for the apps they use.

So, I’ve decided to work on a need that I’ve had. Its not original and its not life changing. But it would make my life easier and would be simple to build. It will not make me rich, even if it takes off, but that is not the point. The point is to have place to get used to working toward something again, to have place that I learn about how to get people to notice a product, and to have a place to experiment.

The idea is a very simple service that helps people decide on a time. A time to meet, a time for a call, a time for a party… you get the idea. Sure, similar things have been done—I told you it wasn’t revolutionary—and its a feature that could very well be Sherlocked by Google Calendar someday. But its a need I have currently and it is one that is not solved well or in a way that doesn’t make your reliant on an advertising company looking at your schedule and contacts. Here we go…