Husband, father, software developer.
I was reading an interview of Frank Zapata on The Verge about the Flyboard Air. I really like this quote about why they created it:
Honestly? I don’t know. [Laughs] You know when you decide to have a child, you decide to have a child because you want it. You don’t decide to have a child because it will become a surgeon, or a lawyer. For us it was the same thing, when we decide to create something, we create it, and after we just follow what ways the project can go.
At Recurrency, we use Sidekiq for background processing. We have several cases where we need to create a model object, save it, and then have some method on that object execute in the background. Instead of creating individual worker classes for each of these use cases, our CTO – Jonathan George – came up with a simple reusable worker class to make this extremely easy. He came up with CallbackWorker, which I have iterated on, simplified, and ended up getting down to 9 lines with the use of splat arguments, Global ID, and general Ruby awesomeness.
To use this generic worker, just call perform_async with your model object’s Global ID, the method to call as a symbol, and any parameters that need to be passed to the method:
This obviously won’t work for every situation, but it makes some of the simpler background processing tasks quicker to implement and reduces the amount of code we have to write and maintain.
If you port this to another background processing library, please share it in the comments.
Today marks my first monthiversary with Recurrency. Prior to Recurrency, I was working at Cerner and leading a development team full of really great people. I was working with technologies that I enjoyed, working with friends, working for a really great manager, and was starting a management training program myself. Things were going well, I was happy, and I wasn’t looking for anything else.
In February, Recurrency – or Secret Project X as it was called at the time – was starting a final push to go live for the LAUNCH Festival. Jonathan George – the CTO – was given my information and got in contact with me. After a quick conversation, I was hired as a moonlighting contractor to finish the federated search functionality so Jonathan could focus on other things. After that, Jonathan informed me that they would like to bring me on full time… … Decision time.
It was a big decision to leave the confines of development at a large corporation for the wild west of startup life. I didn’t take it lightly, and I definitely didn’t make the decision overnight. I have always worked for large corporations, but I’ve always wanted to work in a fast paced startup. I wanted to work from home full time. I wanted to make connections with people in the “startup world.” The corporate development life was safe, and satisfying enough… but it wasn’t my true passion.
Now that I’m a month in, I’m glad I made the decision that I made. I’m starting to settle into working from home full time (it’s a little more of an adjustment than I expected) and loving it. It’s been a blast so far, and I can’t wait to see where Recurrency is in the coming years.
So far, I’ve really enjoyed working with Brian Alvey (CEO), Jonathan George (CTO), Craig Dennis (Designer), Barb Dybwad (Head of Creator Partnerships), and Mike Gray (Creator Evangelist). It’s a little strange, but kind of cool, having met only one person that I work with. I’m looking forward to getting to meet everyone in person, but it’s pretty neat that we’re able to work effectively as a company having never met in person.
I was reading State of Apple on ignorethecode.net yesterday which has this great quote:
But if I’m using an iPhone, how much money Samsung makes doesn’t really affect my experience at all — and actually, neither does how much money Apple makes, or how many bugs Android has. What affects my experience is how good the iPhone is. And if nobody talks about the iPhone’s problems, it’s not going to get any better.
We can spend so much time talking about things that don’t really matter to us. Talking about the problems with someone else’s product or service isn’t going to improve our experience. We should spend less time talking about the other guy, and more time examining and talking about our situation/product/service/etc.
I’m starting to read Start With Why by Simon Sinek. I haven’t gotten very far into it yet, but I just read a chapter with a couple of quotes I really like:
… great leaders understand the value in the things we cannot see.
… it is what we can’t see that makes long-term success more predictable.
These come after a story about American auto manufacturing business men who traveled to Japan to learn from Japanese auto manufacturers. While the American factories solved an issue with how car doors fit by employing a person to use a mallet to ensure a correct fit, the Japanese factory took a different approach. The Japanese factory went back to the design of their components to make sure the engineering was done in such a way that the doors fit correctly every time. It really didn’t make much difference in the bottom line, but it’s important in the sense that the Japenese factory was solving the right problem instead of just fixing the symptoms.
Another quote:
So many organizations function in a world of tangible goals and the mallets to achieve them.
I think this is very applicable to software development. There are so many things when writing software that are analogous to fixing doors with a mallet. When we have defects, do we send them to the person with a mallet to just “fix it” or do we go back to the design and see where we could improve at a more fundamental level? How can we improve our design, or our process, so that we don’t need somebody with a mallet at the end of the line just to get things functioning?
When working with non-developers, it is often difficult to convey the importance of tackling technical debt, or spending twice as long on a feature just to “do it right”. But these things are important. They may not show up to the end user, but they show up in long term success.
Just some food for thought…
My wife and I have over 16,000 digital photos going back to 2007. Over the years we’ve used different camera phones, digital cameras, storage devices, and backup plans. I’ve managed to consolidate them all into DropBox over the last year or two, but they’re still in random folders and not really organized very well. I’m sure we’re not the only people with this issue. I know there are applications out there to help you manage photo libraries, but none that I’ve tried work like I want.
I decided to solve this problem with code. I’m starting small, but I hope over time to build out several utilities to help me manage our digital media in a way that makes sense and is simple to do.
Introducing, MyMediaManager. Right now, it simply takes photos from a source directory and moves them into a target directory organized into folders by year and month. It does this using metadata in the image files.
This is built to work how I want it to work, but if it would be useful to you, feel free to use it and contribute if you would like.
This, ladies and gentlemen, is how you do a comedy tech talk…
