While I’m a software developer by trade, I’m also the mother of two school-aged kids, so one of my pastimes is volunteering in various capacities at our local public elementary school. At some point early this school year, in a moment of temporary insanity, I found myself nodding my head “Yes” when a wiser full-time-working parent would be saying “No”, and next thing you know, I had agreed to lead an after-school Computer Club for 4th and 5th graders.
Something I’ve observed that you may have also: by the time a kid is 9 or 10 years old, they are already incredibly capable of wasting copious amounts of time on a computer. This age group (ok, all age groups?) would happily spend all their time playing computer games — Minecraft being the game of choice these days.
My goal with Computer Club was to get the kids away from just playing games and into creating something with their computers — maybe even creating their own games. After a quick survey of developers with kids and the Internet, I settled on teaching basic programming concepts with a language/platform called Scratch. Read More
When you’re looking for a home for your career, one really important consideration is who you’ll be working with. What’s the culture like? What kind of people will you spend your time with?
I’ve worked at Atomic Object for a few years now — long enough to have observed and identified some characteristics that most, if not all, of the other Atoms have in common. In no particular order: Read More
As browsers and HTML have matured, our ability to create wonderful experiences has become easier and better, but our code has become more complex. To aid this complex development, we rely on packages such as JQuery, Bootstrap, etc.
But with the use of packages comes the need for package and dependency management. Ruby has RubyGems and Node.js has NPM, but we also need something for the browser. Here are a few of the more popular choices and how they approach dependency/package management. Read More
Atomic is looking to add two talented designers to our Grand Rapids team. We are interested in talented junior or senior designers who take a user-centered design approach to their craft and are excited to participate in the entire product lifecycle from concept through implementation. Read More
As engineers, we enjoy solving technical problems and enjoy the results of our hard work. But sometimes, our development suddenly and mysteriously stops working, and we get stuck trying to figure out what happened. Then, hours later, we realize it was a really dumb mistake or oversight. Those times are really unfulfilling and frustrating.
To help you avoid this frustration, here’s list of lessons that have been painfully burnt into my heart over the years.
1. Save the file.
Yeah, we still forget to do this sometimes. We were supposed to have permanently learned this lesson during our first ever
Hello, World program, but sometimes we still forget. Many IDEs have an autosave feature, but watch out when using that same IDE on another machine, since the feature might not be switched on. I’m more likely to neglect saving when I switch between buffers or tabs a lot. Read More
Google Docs (and the recently-improved Google Sheets) are powerful tools. In the last few years, there have been some awesome additions to these products, one of which is Google Apps Scripting. With the apps scripting tools, you can write your own menus and background tasks for Google Drive, plus general scripts for the Google Apps suite. The interfaces are there; the only limitation to what you can create is you.
In a recent series of posts, I described tools to help plan, build, and maintain a small app as a startup team. While looking at uptime monitors, I wasn’t really impressed with any of the free options. Only after publishing the post did I discover an uptime tracker in Google Sheets. I was aware of other cool uses of Google Sheets, such as an Amazon.com price monitor and Gmail NoResponse tracking, but using it as an uptime monitor had slipped my mind. Read More
Quiet: The Power of Introverts in a World That Can’t Stop Talking by Susan Cain is an interesting and well-researched book about introverts in an essentially extroverted world. By nature, I’m introverted (though consider myself a pretty well-adjusted ambivert) and found this book to be a breath of fresh air.
This book has been widely reviewed, and I want to share some of the range of perspectives on introversion’s value and challenges in our society.
When I started working on my first embedded project at Atomic, I was given just two pieces of advice regarding C programming:
- Read the K&R C book.
- Turn to the C technical standard for language questions.
The second one struck me as an odd proposition at the time, as I had never before cracked open a language spec.
My impression of language specifications and formal documents in general was that they were for a chosen few, and not generally useful day-to-day. This turns out to be almost completely untrue. Since the standards documents lay out the rules which the people implementing the standard must follow, they often provide one of the very best references for how things behave in the real world. They also must be clear enough to follow, and detail the corner cases that introductory blog posts always seem to leave out.
Surely enough, I quickly found myself skimming through the C99 specs for everything from finding out what the ‘register’ keyword actually does (hint: nothing to do with register allocation) to the exact behavior of designated initializers for structs. The spec isn’t always the clearest, and takes some time to read, but importantly it’s almost always right. Read More