How do we spend our time? Well, there are a number of surveys that track this, among them the American Time Use Survey. A few years ago someone took that survey data and made it live.
Above is a screen shot, but the animation is much cooler.
If you have a relational database as the primary datastore for your application, and you want to easily allow non technical folks to build reports against data in that database, I highly recommend evaluating metabase. This open source query builder is dead simple to install (takes about one minute on a free heroku dyno). You can create individual users, and they all get access to an easy to use interface so they can look at data in your tables. All the nomenclature is non technical, nary a
group by or
from clause to be seen. It’s written in java, but you don’t have to know java to run it.
We haven’t used this for long, so I can’t talk much about the warts, but I was referred to this by someone else who had great success in using it in their organization. The only downside that I’ve seen so far is that joins are not supported, so you end up having to create views if your database is normalized. More on that decision.
I am on a mailing list of engineering leaders and someone mentioned that they have found Github to be a very good indicator of whether a candidate is a good choice for them.
Of course, every company will emphasize different aspects of software development–for some technical expertise is more important than communication, while others have that ranking flipped. Some may emphasize ability to work in large teams, while others may prefer folks who are self driven.
But I see a fair bit of emphasis on Github profiles, which makes sense–you can actually look at the code someone has written, and how they developed it.
But here are some reasons why someone might not have a stellar Github profile. They might:
If someone has a great GH profile, that’s probably an indicator they are a good developer. But if they don’t (full disclosure, mine is kinda weak), that’s no indicator of anything other than that they haven’t made it a priority.
This post from the folks at 18F does a great job of covering why you should default to a responsive web site rather than a native mobile app. While tools like cordova and react native decrease the effort required to build a native application, the ongoing maintenance costs shouldn’t be underestimated. It is easier to outline the reasons why you should build a mobile application, because there are far more reasons why you should not. From the post I mentioned above:
If your application doesn’t meet these criteria, I’d think long and hard about launching with a native mobile application, and think about what you could do for your business with the extra budget.
You can likely prototype your app with a responsive website and then build a native mobile app when you know more and/or have user feedback. This can be a great way to economize, because you can leverage outsourced mobile app teams and point them at the prototype as a living requirements document.
I was driving today and saw a bus driving in the snow. I’ve never driven a bus, but I imagine that snowy days are some of the most difficult. The roads are bad. People are crabbier. Accidents happen. You are still on the hook for making the schedule. I’m no bus driver, but I bet when the driving is easy, as in the summer during off peak times, the job is easier.
However, when things get hard, that’s when you earn your pay. Since software development is such a sprawling occupation, it’s hard to generalize about the most difficult moments, but I can mention some of mine:
You don’t earn your pay for the easy stuff. It’s when the going gets tough that you really earn your pay.
Have you ever been developing some kind of application that sends email? You need to test how the email looks, so you have to have access to an external SMTP server and you have to configure your application to use that. You can definitely set up sendgrid or another MTA to send email from your local computer and then use a real email address as your target. However, then to develop this portion of the application you need to be online.
Another option that I’ve found is the Mailcatcher gem. This is a small ruby program that you can easily configure as your SMTP endpoint. Then when your development environment sends mail, mailcatcher catches it. Then you can visit a URL on your local computer and view received emails. As soon as mailcatcher shuts down, the emails are lost, however.
Even though this is a ruby gem, you can use the app with different languages–as long as it you can configure the application to point to an SMTP server, you’re good (in the readme, there are examples for Django and PHP).
One note about it being a gem. Don’t put it in your Gemfile if you are building a rails app, because of possible conflicts. This means that if you manage your ruby environments via rvm you’ll need to re-install mailcatcher every time you change your ruby version.
Bonus: mailcatcher even has an API so you can use it in your integration test environment to verify that certain actions in your application caused certain emails to be sent.
We are using Trello for our product development planning at The Food Corridor. Previously we were using Pivotal Tracker, which I chose, but a new team came on to help us and they were more comfortable with Trello. I may do a compare and contrast of these tools in the future, but for now I wanted to celebrate the beauty of a well designed piece of software.
I don’t mean how Trello looks, though it certainly looks pretty. I mean how they handle UX edge cases. I ran into one the other day, and it blew my mind that Trello acted as I had hoped.
Here’s the situation. We use the Trello numeric card ID along with this git hook:
#!/bin/sh # from http://stackoverflow.com/a/16061192/203619 if story_id=`git branch |grep '*'|sed 's/.*-//'` then echo "[#$story_id]" >> "$1" fi
To help tie commits to stories. If someone is working on a story with the id 123, they work on a feature branch called
add-new-feature-123. When committing, they may write a message like: “Updated the message to the end user when they save”, and this hook will automatically add “[#123]” onto that commit message.
When someone is looking at the code six months or two years from now, they will be able to look up that story and get context about why the message was changed beyond what was in the commit log.
We were cleaning up old releases in Trello and had moved all the released stories to another board. However, I noticed that the cards were renumbered when they were moved to that board. Whoops! That meant that the commit messages wouldn’t be useful in looking up the cards. I had discussions with the product manager and we decided to keep all future releases on the same board to maintain the numbers–we’d just archive them (it’s worth noting that when you search for
123 and the card is archived, the search won’t return the card unless you add the
is:archived search operator to your query).
However, I was ready to write off the cards that had been moved to the other board. What were the chances that if I moved the cards back to the original board, the card numbers would be maintained? I gave it a try just to see.
Trello did the right thing! The cards, when moved back to the original board, assumed their original numeric ID.
I am very impressed, as I imagine there are a very small portion of Trello users who care about this behavior. As someone who doesn’t really care about design but does care about user experience, that is an example of attention to detail that I wanted to call out and praise.
This post from Fred Wilson echoes a lot of my thoughts. Whether you are posting to twitter, instagram, facebook, Medium, HuffPost, or anything else, it’s always worth remembering that you are leveraging someone else’s platform. That means you are renting it, not owning it. So, you are at the mercy of the platform. Whether in terms of content lifespan, deep linking or even just how your content is presented, you only have as much control as they allow.
That doesn’t mean there isn’t value in these platforms. There is tremendous value because they aggregate eyeballs, have excellent user interfaces and often host your content for free. Just be aware of the price you are paying (TANSTAAFL).
And always maintain a presence that you own if you care about your content. Repost all your content on your own site, so that even if the third party site goes away, you still have your work. (If that’s not possible, print a PDF and save it in Google Drive, at a minimum.)
It’s not hard to buy a domain and set up a free google site (I wrote up instructions). You can use WordPress.com with your own domain for only a few dollars a month. Even if it isn’t as trafficked or as beautiful as a Facebook note, you control it. Once you’ve seen a few platforms rise and fall and/or change their business plan, you’ll be happy you used them for their leverage, but maintained as much control of your content as you could.
Do you have an interest in foodtech? Are you in Colorado? Are you a senior engineer?
If the answer to all three is ‘yes’, you may be interested a position at The Food Corridor. Why? Small, tight knit team, a working product, revenue, customers that love the product.