Carl likes to talk about the worry gene culture at Atomic — our predisposition to turn worries into concrete, positive action. The converse of this behavior, inaction, can quickly lead to unresolved worries piling up. That’s where stress comes in. And despite our predisposition to positive action, we all sometimes need a kickstart in the right direction.
Fortunately, many of our practices at AO already serve to guide us toward the concrete, positive actions we need. And there are other simple things I’ve found that help effectively spur the worry gene into action. Read more on Worry; Don’t Stress…
Posted in Culture Tagged worry gene
Vim is a good friend of mine. When we met during my freshman year of college at MTU, we quickly hit it off. I never looked back with any regret at my tiny TI-85 screen, Notepad, or QBasic where I first tinkered with bending computing devices to my whims. Since then I have tried other editors, and even used a few for extended periods for a variety of reasons (e.g., Kate because of its SSHFS and KDE tie-ins, Visual Studio for its strength with all things Microsoft). Still, through it all, Vim has been my go-to editor for nearly 15 years.
I have been using Atom almost exclusively for the past month — without vim-mode. This was an intentional decision on my part. I didn’t have any complaints about how Vim had been working for me prior to picking up Atom. It, along with our built-to-Atomic-tastes configuration, did great navigating the mixed mobile & web project environment I was working in. I was just feeling ready to try something different when Atom came on the scene — something that wasn’t vim and didn’t work like vim. Plus, I dig the name and logo. ;) I figured, at the worst, I’d return to Vim after a while with a renewed appreciation for everything that makes it, well, Vim.
So, how has it gone? Read more on A Month with the Atom Editor…
Burn charts have been a staple of Atomic-run projects for quite a while. They’ve also been the subject of much discussion both internally at Atomic and at-large in the Agile development community. The basic concepts are simple, and we’ve found them useful — especially when they are allowed to evolve as we learn how to better engage our customers and teams. I’m going to tell a story of one such evolution.
First, if you’re unfamiliar with a basic burn chart, check out Mike Marsiglia’s previous post about Atomic burn charts. Got that down? Great!
I’m going to follow the story of a ficticious company, Acme, Inc., working on a custom order management system. Our burn chart experience started simply, as Mike’s example illustrates: one big scope bucket (represented by the blue line), and a team of three working to realize the features represented in our backlog (represented by the green line).
Read more on Evolution of a Burn Chart…
Carl Erickson wrote back in 2009 about his practice of distributing “nice words” from clients to the company at large. It is a practice that continues, and something that I personally love about working at Atomic. It lifts my spirits and makes me proud to be a part of such a highly-praised group. I know I’m not alone in my appreciation for this practice.
Nice words mean so much to all of us in part because they result from hard work. To us, these words are like a flag flying triumphantly atop a newly-constructed castle. Weeks or months of time has often gone into erecting the solid, stone walls. Thoughtful, sometimes difficult, decisions have shaped it for its intended purpose. Throughout the process we’ve sweated the details, pursued knowledge and empathy, and as a team brought a vision to life.
These are words worth working for. Read more on Words Worth Working For…
Jason on vacation
Here at Atomic, we work to maintain our sustainable pace on a number of levels. I typically think of my pace on a weekly granularity because of our team’s iterations, invoicing cycles, and the intervening weekend breaks. There’s a rhythm in which I can feel the ebb and flow of my energy level resulting from the week’s efforts and accomplishments.
Atomic encourages employees to take a consecutive week of vacation at some point during the year, and I recently took 10 days off to travel with my wife and disconnect. Having the opportunity to disrupt the rhythm, to disconnect and re-energize, is important. But it isn’t always easy, especially for people who are deeply engaged with and care about their work (as we do here at AO). Here are a few things that can help make it work. Read more on Ready to Disconnect on Vacation? 6 To-Dos Before Leaving the Office…
My current project involves an Ember.js web application and a JSON+HAL API, and we recently wanted to let administrative users upload an XML file, sourced from a different system, to make filling out a form easier. We didn’t want to upload the file to the API for processing on the server. Following is an example illustrating how we handled the file upload in our Ember.js app, and how we could make this work with a few other file formats.
1. The Upload
Let’s pretend we want to make it easy to upload a list of user information into the application. I’m going to illustrate a method using a file input element for the upload interface. There are other options, like drag & drop, but this met our users’ needs and was simple to implement.
Read more on Client-side File Processing in Ember.js…
Here are a few tools we’re using on my current project, a non-trivial Ember.js application, to do just that.
Read more on Practical Abstraction in Ember.js…
I recently had the opportunity to travel up to the fall career fair at my alma mater, Michigan Technological University, with fellow MTU alum and Atomic developer Jeanette Head. We had a great visit. It was exciting to be back on campus looking for engaged, smart software developers to join our team, and I left seriously impressed by the number of great connections we made.
If you’re wondering how to get my attention at a job fair, or when applying for a position at Atomic Object in general, here are a few hints. Read more on How to Get My Attention at a Job Fair…
The boundaries between our digital world and physical world blur a little more every day. Our houses and cars are becoming increasingly controlled by computers and connected to the internet at large.
As a software developer and driving enthusiast, I’m particularly interested in the intersection of cars and software. I’m excited by a large number of the improvements in vehicle control and utility these changes have enabled. The stability control system in the Nissan GT-R, for example, is astoundingly robust. Naturally, then, I’m curious about what modern control systems and vehicle communication channels might enable enterprising enthusiasts and makers to accomplish.
But there is a darker side to the connected world as well: people with malicious intent are increasingly able to take advantage of the same systems. Our cars are hackable. The potential impact depends on the vehicle and whether the hacker has physical access to it, but the possibilities range from merely inconvenient to downright dangerous. Read more on Hackable Cars, for Enthusiasts… and Others…
Karlin Fox and I have been using RubyMotion and ReactiveCocoa to build an iPad application for our current project. We’ve enjoyed the different paradigm and the way we’re able to stream data through our application. Adapting TouchDB live queries to ReactiveCocoa signals has been particularly rewarding.
But what about unit testing our iOS app? Unit testing in iOS has matured a lot in the past few years, and RubyMotion brings testing along from the start of a new project. However, development paradigms like FRP have a dramatic effect on how we test, what we test, and what tools we choose to build our tests.
Mocking vs. Real Objects
We’ve been alternating between mocking out signals and creating real signals we can instrument in our unit tests. Each method has its advantages.
Read more on Unit Testing with ReactiveCocoa and RubyMotion…